Reduce cumulative layout shift (CLS) by attempting to determine heights of embeds beforehand

[westonruter]

Feature description

Cumulative Layout Shift (CLS) is a huge detriment to user experience on the web. It is also a huge challenge to solve in the case of 3rd-party embeds. For some AMP components, in particular amp-iframe and amp-list, elements that need to resize based on their contents need to provide an overflow button that needs to be clicked by the user to trigger the element to grow in height if the element is currently in or above the current viewport. The presence of this overflow button can be annoying for users and so it's important the initial height be set to be as close as possible to where the element will be once loaded so that, in the best case, no overflow button needs to be presented.

Nevertheless, for pragmatic reasons, other components do not have such overflow logic and they will resize to fit their contents regardless of being in the current viewport or above. For example, amp-gist:

<amp-gist data-gistid="0769f147e021e0ebfcb04a084987483a" layout="fixed-height" height="10"></amp-gist>
<p>Super interesting information!</p>

When the page loads at first, the user will see “Super interesting information!” momentarily until the Gist loads. This is a gross instance of CLS. The docs for the component call this out in the description for height:

Similar guidance is provided for amp-twitter:

This issue, however, is not unique to Gists and Tweets, but it's also an issue for other embeds. For example, embedding Facebook posts also have this issue and the amp-facebook component lacks that same guidance.

All this being said, we should automatically provide the best approximate height for these components as much as possible.

One way this could be done, specifically in the block editor, is to render the component and then scrape the resulting height and then inject that as the height of the embed. This couldn't be done currently with the PHP Optimizer since we need a browser context to load the page, but perhaps the Node Optimizer could add Puppeteer as a dependency to obtain initial heights.

This would essentially be an augmentation of SSR.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• After having added an Embed block to a post, saving and viewing the AMP page should should require any layout shifting for the block on the frontend.
• Bonus: Also set the height of embeds on non-AMP pages.

Implementation brief

1. Check the initial post content for any embeds that lack heights, and watch for insertions or updates to Embed blocks.
2. Once the Embed block clears its loading state, measure the height and add as a custom block attribute.
3. Add a render_block filter that passes along the height block attribute to be inserted as a data-amp-embed-height HTML attribute on the figure wrapper element.
4. Add toAMP_Embed_Sanitizer::sanitize() logic which finds all //figure[ @data-amp-embed-height ] and then copies the value to the ./div[ contains( @class, 'wp-block-embed__wrapper' ) ]/*[starts-with(name(), 'amp-')].

QA testing instructions

Demo

Changelog entry

[schlessera]

For some of these, we might still be able to calculate a close approximate height on the serverside based on the content from the embed, but it would mean supporting adding per-embed logic to do so.

For example, for a gist, you'll probably get very close by counting the number of lines and then calculating something like $top_chrome + ( $lines * $line_height ) + $horizontal_scrollbar? + $bottom_chrome. In most cases, this can yield a pixel perfect height estimate, so you'd be able to block the correct height right from the start.

To get the number of lines and the line height, you'd fetch the embed content from the server and parse the return HTML.

Given that there is direct support in AMP for something lie a gist via its specific component, I don't think it's necessarily bad to mirror that custom support in the Optimizer, and have a few lines of custom logic per component to calculate its height on the server-side.

[westonruter]

Obtaining the dimensions of embedded content is going to be increasingly important as part of the Bento effort because components like amp-twitter, amp-facebook, etc will no longer be resizing themselves without user interaction. In other words, they will require overflow buttons on AMP pages to expand if they are in the first viewport. See ampproject/amphtml#35027 and ampproject/amphtml#34948 (comment).

While it is possible to approximate the height of embeds server-side, this would indeed need to be done uniquely for each embed. And then it would have to be maintained for each embed. I actually had to do this for the Pinterest embed in Jetpack via Automattic/jetpack#17086, since at the time amp-interest did not autoresize after the first layout (see ampproject/amphtml#10318 (comment)).

The code involves a lot of magic numbers: https://github.com/Automattic/jetpack/blob/36151c453f478f613204768725e236be8bd7949a/projects/plugins/jetpack/extensions/blocks/pinterest/pinterest.php#L70-L210

I think it will be much more scalable to do this client-side in the editor. When an embed is rendered, we can store the height as a custom block attribute which we then utilize to supply the height when rendering (either in an embed handler or embed sanitizer).

[westonruter]

Added AC and IB.

[westonruter]

The downside to the client-side approach is that any existing embeds will not have sizes supplied. To supply the initial heights, a site owner would have to touch it: open the post in the editor and re-save once the embeds have loaded. In order to supply the heights for all previous embeds in an automated way, this would involve having some UI that programmatically opens each post one-by-one in an editor and saves if they enter a dirty state.

Something similar in concept is the Convert to Blocks plugin, but it doesn't do batch updating of all posts. It still requires opening posts one-by-one.

Batch supplying heights retroactively to older posts is out of scope for this issue, but it's something interesting to consider for the future.

[westonruter]

It seems we may need to check responsive breakpoints to determine the heights of the embeds. Adding a tweet I can see that on mobile it is ~500px high but on tablet/desktop it is 630px high:

responsive-embeds.mov

Mobile	Tablet/Desktop

That complicates things a bit. Do we capture just the mobile dimensions? Or do we capture mobile, tablet, and desktop and store them all with the embed's block attributes? But when we render the amp-twitter onto the page, what dimensions should we be rendering? Do we need to render separate components for each breakpoint via the media queries?

<amp-twitter class="mobile" width="auto" height="500" layout="fixed-height" data-tweetid="1405578489554743296" media="(max-width: 360px)"></amp-twitter>
<amp-twitter class="desktop" width="auto" height="630" layout="fixed-height" data-tweetid="1405578489554743296" media="(min-width: 361px)"></amp-twitter>

That doesn't seem ideal.

[schlessera]

Instead of using the media attribute and including multiple versions of a same element, we could use inline styles like we do with other parts of the SSR transformation, so that we can encode all breakpoints onto a single AMP element.