Skip to content

Introduce a way to measure content layout latency vs ad layout latency #7789

@lannka

Description

@lannka

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-ad rendering 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 / #ElementsEverInViewport

This 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

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions