[Performance] Embedding consumer scripts+utils and styles into head.html

[mokimo]

Description

Given the ongoing performance efforts and another performance focussed discussion - I've experimented with moving a few files into the head.html for the milo-college and wanted to see what the community thinks about it.

The idea

Frictionless (view-source: of link) already has a similar mechanism using edgeworkers to inline LCP assets. Given the complexity of edgeworkers - we can achieve similar gains using the head.html we are given from an aem product perspective. To illustrate the changes this would introduce, here's the diff for a POC in the milo-college project

Let's talk numbers!

As basis of every healthy discussion for change, we need concrete benefits. Otherwise, why spend the time & effort? For the curious here the Before and After links.

=> 2 Extra requests can be saved by inlining the consumer scripts+utils into the initial HTML. Note: Some consumers have/or want to combine their scripts+utils, that'd reduce savings to 1 request.

How "expensive" is a request?
No Throttle: 50ms x 2 => 100 MS saved 4% of the LCP Budget (2500MS)
Fast 4G: 180ms x2 => 360MS => 14.4% of the LCP Budget
Slow 4G: 600ms => 1200MS => 48% of the LCP Budget

Basis for the numbers, are consumer utils.js behind akamai. Most of that time is spent on waiting for the server response. (Size of the file is NOT the bottleneck)

Talking about size, the cc utils.js are 180 lines of code and the scripts.js are 200 lines with the styles.css sitting at 15 lines.

With 3000 lines delivered within the initial HTML (frictionless) - the requests still take more time than downloading the content

The advantages

The advantages are clear, better LCP numbers achievable with smaller changes

The disadvantages

• Breaking the separation of concerns (we embed CSS and JS within html, ugh. But that tradeoff is IMO worth it)
• Caching? To my knowledge, AEM just wipes their cache when changes are made. CC for example sees ~1 change per month to the consumer scripts/utils/styles.

Closing words

It might seem miniscule to save 4% or 50ms on desktop. However, 5 of those changes combined and we suddenly get 20% of our LCP budget back and can ship mobile experiences seconds faster to users, which will be great for retention, bounce rates & SEO.
One of those "5" changes, might be moving @auniverseaway experimental PR on CC to the head.html to instantly start loading LCP assets that we need the moment we get the initial html file back. Small incremental improvements, combine quickly...

I'd love to hear what the community thinks about this.

[auniverseaway]

Taking https://milo-college-inlined-scripts--milo-college--adobecom.hlx.live/ as the definitive place to test this...

A couple thoughts:

1. This is in a non-production context. You have cross origin requests that will not be the case in the real-world.
2. Frictionless has a series of different use cases that are not representative of the majority of milo-based content. They inline their CSS and if we were to do the same (BACOM even tried) your pages will slow down. This is because you put downloading CSS as priority over downloading the LCP element (or parallelizing). Frictionless does not need to download a ~60KB image binary image like the majority of milo content.
3. I think moving the setLibs function into scripts is something that should happen. We can even simplify the function. I have a mock of that somewhere. This gets consumer utils.js out of the critical path and reduces one request while still not deviating too much from recommended practices.
4. I would highly recommend testing this in a more real world context: same domain, + commerce, + mep, etc.
5. This will negatively impact 2nd, 3rd, 4th, etc. requests. The stuff put into head will be considered brand new for every page visit. The overall benefits may outweigh the negatives, though.
6. Deep PSI shows promise, but I would still do some tests in an env that is more representative of real-world. milocollege.com (no cross origin), or better would be somewhere you can test commerce.

[mokimo]

Cool appreciate the feedback! I didn't consider that the initial html is not cached as opposed to the assets themselves.

Moving the setLibs function might already provide the benefit without doing too many changes - given that utils can then instantly proceed to queue loading its own assets.

That's a great idea and I'll trial that and try to get some more numbers on a CDN gated page

[vhargrave]

I think this is very exciting and am very curious to see where this leads. 🚀
@mokimo I think it's a good point that Chris made about getting some more real world data. You could probably run some experiments on a branch for the homepage, a pricing page, an express page, etc. , and see what the data gives.