-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Description
Problem
Resource scheduling is one of the key things that AMP does to ensure a good page performance. All AMP elements fall into 3 priority buckets, from 0 to 2. amp-ad is the only P2 element so far in AMP. Due to the wildness of 3P ad iframes, it is throttled in the following ways:
- yields 2 seconds to other elements. (P1 elements yield 1 second).
- we further throttle the
amp-adrendering to one per second, to make sure no simultaneous ads loading to take too much resources.
It kinda makes sense for a user-first platform to treat ads as the least important thing. However, on the other side, we do hear publishers yelling about their revenue. Also, seeing many ad loading placeholders (used to be a blank spot) which isn’t a great AMP experience either.
The goal here is to propose a set of meaningful metrics representing user’s perceived content latency, and set up a baseline for any further optimization work we plan to do.
Proposed metrics
PerceivedLayoutDelay
PerceivedLayoutDelay = Max(LayoutCompleteTime - FirstInViewportTime, 0)We can measure the PerceivedLayoutDelay of every single AMP element, and report them back, and do a comparison between PerceivedLayoutDelay for amp-ad and others.
Problems of doing so:
- We might fail to capture some super slow elements, because user swiped away before layout completion. This will bring bias to the final reports.
- Too much data to send back for one page view.
GoodLayoutProbability
GoodLayoutProbability = #ElementsCompletedLayoutWhenFirstTimeInViewport / #ElementsEverInViewportThis is a single 0~1 probability value that solves the 2 problems of PerceivedLayoutDelay. However, it has its own problems:
- Elements above the fold are always considered as delayed (not taking Viewer pre-rendering into consideration).
- when #ElementsEverInViewport is too small, the metric can easily be 0 or 1, which might not really reflect user perceived latency (e.g.: the only 3 ever in viewport elements all get laid out right after entering viewport).
So this metric is highly affected by article length and how further user scrolls.
Hybrid of PerceivedLayoutDelay and GoodLayoutProbability
Here I propose a hybrid of the above 2 metrics.
For P2 elements (amp-ad), we use PerceivedLayoutDelay. It will be an integer of milli-seconds. And we send one ping per amp-ad. (for 3P amp-ad, we will use scheduled layout time instead layout completion time for the calculation, so that we exclude ad request latency).
For P0 elements below the fold, we use the DelayedLayoutProbability when #ElementsEverInViewport is 5. (5 is a rough estimate of average number of AMP elements on below the fold).
If the 2 metrics proved to be useful, our goal becomes:
Reduce PerceivedLayoutDelay of amp-ad when keep GoodLayoutProbability of content at the same level.
For #7500