Introducing Decorate Area for Consumers

[auniverseaway]

We had a couple opportunities that came together to create a need for letting consumers decorate fragments with their own code.

1. Homepage needs to prefix their ./media_ requests to avoid collisions with other projects.
2. Blog transpiles blocks in scripts.js that may be used in fragments.
3. ./media_ urls in fragments would land as relative to the viewing page - causing duplicate requests to potentially the same image.
4. fragment was not respecting consumers decorateLCPImage function - delaying the loading of fragment images

You could always do page-level decorations (including LCP image load) in scripts, but this function would never run against fragments.

We have added the plumbing in Milo College to enable a BYO decorateArea that will now run against fragments.

To enable this feature, you just need to add a decorateArea function to your config and with @seanchoi-dev's open PR, Milo will decorate fragments on your behalf.

Please see this commit in Milo College for recommended formatting.

In order to solve item 3 above, there will be a separate PR that will find & replace ./media_ in the raw fragment html with the proper path relative to the fragment, not the viewed page.

[honstar]

I'm interested in the LCP part of this new feature. With a consumer-side decorateArea function and the one you already added to milo college, I see that a fragment's first img element gets eagerly loaded by removing its loading attribute. However, what if you have multiple fragments with images that are loaded/injected into a page? Every image coming from fragments would suddenly be loaded eagerly that would have a negative impact on overall performance.

I could imagine giving authors a certain level of control over which fragment would have an LCP relevant image to be loaded eagerly, e.g. by passing a hash value. Similar to what the adobetv block supports today. WDYT?

[auniverseaway]

However, what if you have multiple fragments with images that are loaded/injected into a page? Every image coming from fragments would suddenly be loaded eagerly that would have a negative impact on overall performance.

Yup. Exactly. Good observation.

The goal of college is to set a simple example and let consumers tweak to their needs. This should work for the most common use case where a fragment is used as the LCP block. If you have multiple fragments in your first section, you probably have other performance issues. Even for Milo, there are scenarios (though rare), where blindly setting the first image to be non-lazy is not desired. You can see how bacom tweaked there's here.

What I have seen in the wild (note I'm the last committer on the code above to fix a perf issue) is that consumers think they know what their LCP is, they get it wrong, and then they end up making their site slower.

Homepage is a good example where the college-style simple LCP image is correct because they are using a very vanilla marquee block.

[honstar]

Well, homepage is making use of masonry which essentially loads a set of fragments and adds it to the masonry layout. Applying the milo-college decorateArea function would completely load all these fragment images eagerly. But I get your point, milo-college provides a simple example which is not applicable for generic usage in Milo.

For the special-offers page on cc, the page is setup for maximum reuse where even the marquee is a fragment and while that is not enough, it's using a gradient instead of an actual image. So there goes the first usual suspect of an LCP image.

A subsequent fragment with an image above the fold is flagged as LCP, hence the idea of explicitly telling a fragment to eagerly load it.