Use of HTTP headers for pre-loading core scripts

[JasonHowellSlavin]

Hi All,

I wanted to bring this subject up for @meganthecoder because she is on PTO, and I am slated to discuss it in our next performance meeting.

@meganthecoder saw some pretty drastic results and performance increases by using HTTP Headers to preload "core" styles and scripts as seen in her work in this ticket: https://jira.corp.adobe.com/browse/MWPW-154060.

Essentially, Megan used the headers.xlsx file in the .helix folder to create headers setting certain files to preload, allowing both milo and consumer
styles.css, utils.js, scripts.js, and decorate.js to load in tandem. According to the results of her testing, she was able to save on average 800ms.

Though effective, Megan points out that this is not necessarily the best way to do it, since the urls had to be hardcoded. However, Megan does mention the possibility of using head.html in order to programmatically figure out the domain, or that this performance change could be made to account of production alone. There are also considerations of bandwidth contention and possible side effects of using the preload scanner to fetch these files, but in her testing the pages seemed to work correctly and gained a net savings for performance.

Considering some of the discussion around performance, flexibility, and consumer patterns versus milo core patterns, (see #2493 and https://github.com/orgs/adobecom/discussions/2390) we wanted to see what the greater community thought of this.

Thank you for your time!

[mokimo]

It's a great concept! We need the education around the gains and tradeoffs, so that each consumer can decide what's best for them.

Currently, milo has no way of interfering with the render pipeline until late into the fold. Which shifts the development and maintenance cost on the consumers. The potential pitfall I see are future changes, which could lead to a performance degradation as assets that aren't needed are loaded.

I have an idea with which we could shift the maintenance & compatibility aspects towards milo core, rather than each consumer and will trial that soon.

[JasonHowellSlavin]

I'd also love your thoughts on this @overmyheadandbody @Ruchika4 @chrischrischris @rgclayton @auniverseaway. In my own testing I could verify that Megan's results were accurate and reproducible. In my mind, we would enact this on our hlx.live locales first and have our QE test it, and then make the changes for production if no issue was found with LCP or load order.

Thank you in advance!

[overmyheadandbody]

Hey @JasonHowellSlavin! When you say "we would enact this on our hlx.live locales first", are you talking about the headers.xlsx approach or the head.html one?

• the former may be straightforward, but, as you've already called out, it's likely not the best option for maintainability and consistency; we'd be making assumptions for most pages, but not all pages. One approach would be to have the changes under a flag and then set up some monitors that track overall performance evolution between the current implementation and this suggested one. But I can't think of a straightforward way to adapt the content from headers.xlsx on the fly. Maybe a couple of folders containing pages with similar traffic can be chosen; half of those folders would remain untouched, the other half would get this update. A monitor could be set up to track those pages for a given time so we can get some overall insights into how it behaves in the real world;
• if you're thinking about implementing the latter, is there a PR/compare we can look at? I guess the same applies here regarding most, but not all. Maybe a Playwright script could crawl your pages and determine what percentage of them would benefit from this change vs those who would get additional resources loaded without ever using them.

All in all, I like the parallelization idea, but I think we need to look at the "recipe" to make sure we're not doing more damage than good.

[JasonHowellSlavin]

Was thinking of testing the headers.xlsx approach, but code in the head.html provides similar if not the same results and is dynamic, so I have included the compare for that in a branch below (like your second bullet suggests). I am going to point @Dli3 to this comment thread and see what kinds of ideas he also has for testing building off of the ones you provided.

[auniverseaway]

Given the limitations of headers & helix 4 measured against what milo needs to do, I would maybe solve this a different way. With the headers approach, there's a one-size fits all for where you pull milo from. What works for production doesn't work for hlx.page.

I would try to write a small function that can live in head.html that can properly detect the context of the origin and then load the correct file from the correct origin. Almost to the point of minifying our getLibs function and placing it in head.

Where it's not in the headers (boo), it gives us something maintainable that will work across the various places we load milo.

For decorate, I think we keep making this more complicated than it needs to be. From a purity perspective, it makes sense that decorate.js lives as a separate file, but we keep tripping over ourselves with the chaining problem. There's nothing wrong to share a function out of marquee.js that others can use. All problems related to decorate.js chaining go away.

[mokimo]

If authors have a way of telling what to preload, can't we write smarter code? It shouldn't be too hard to detect which features to preload.

If we find out what's necessary for the LCP, we can go a bit further and detect the common blocking required LCP features:

• {{}} -> Placeholders
• The first block // marquee
• fragment -> fragments
• MEP stuff. (Ims, entitlements, etc)
• Icons

Those features are used widely enough so that they can't see any breaking changes either - which makes me believe this could live within the consumers head.html

[yesil]

I think for the first attempt, we might indeed try to discover lcp stuff and preload them without authoring.

e.g: we could already use <meta name="target" content="on"> to preload

• libs/martech/martech.js
• libs/features/personalization/personalization.js
• marketingtech/main.standard.min.js
• libs/features/personalization/entitlements.js

On heavy pages like CC catalog, having an authorable preload section might be helpful though.

[mokimo]

An authorable preload section has been discussed within the scope of the performance initiative, but the conclusion was it's not a good way in terms of maintainability.
Personalization might get superseded by franklin native personalization feature, but pages would still load martech/personalization/entitlements despite potentially not having to do so.

[mokimo]

Trying to preload dependencies was attempted to go into the codebase twice, but abandoned due to concerns from engineers in terms of use-cases and long term health of the project:

• in milo core MWPW-152286 Optimize marquee loading #2493
• in CC as trial MWPW-154899 - Pilot preloading marquee dependencies cc#383

[JasonHowellSlavin]

I think consumers differ quite a bit more than expected. For instance, for b.a.com, we have informed our authors to not use fragments in the first section of the page, and for the most part we do not see things like placeholders.js or fragment.js load until well after the LCP.

Truthfully, in page by page cases, it might make sense to use the .helix/headers.xlsx. In my testing it does seem to add time to the initial request for the page, but the non-chaining gains may be worth it. We can only set a single url for the requests, but it is all within the same domain. Maybe worth testing?

[JasonHowellSlavin]

Thank you @auniverseaway and @overmyheadandbody for your feedback, it is much appreciated.

Here is a compare showing how I might modify the head.html to enact the changes Megan was making: adobecom/bacom@stage...head-prefetch-test

I think to your point Chris, it is probably time for us to create a ticket to refactor decorate.js so that it doesn't cause the chaining problem you mention. That to my mind is a better solution than preloading the entirety of decorate.js for the sake of the LCP.

I put a very similar version of our getLibs function in the head.html. I was unsure where to pare it down. It may be we don't need the additional checks for the search params, as those checks are more for development anyway, and we are really making these changes to improve LCP on our base environments.

If you have time, would love to see what you think, and then I might start having our team test this. Thank you again!

[mokimo]

Is there any advantage of preloading those vs. just directly loading them? We require the modules anyway

[JasonHowellSlavin]

@mokimo great point. So I did some testing.

My hunch was that preload utilizes the preload scanner and may grab those files so that they do not get blocked from loading while the main HTML parser finds the blocking resources of styles.css and scripts.js.

If I did things correctly, which I believe I did, we can actually see that difference between the two methods in the below screenshots. It appears that preloading saves ~200ms to LCP.

preloading assets:

loading as modules:

If I am understanding what is occurring correctly, with preloading, the preload scanner sees the resources in the head and makes the request for them, parallelizing their request with the two non-dynamic resources on the page.

When loading as normal on the page, the first two blocking resources that do not require dynamic addition block requests as they are being parsed, and then the parser moves on to the dynamically added resources as they are added to the head by the script tag.

You can see the compare here for loading normally: adobecom/bacom@stage...head-load-files

For ease too, here are two pages to compare:
https://head-load-files--bacom--adobecom.hlx.live/ - loading
https://head-prefetch-test--bacom--adobecom.hlx.live/ - preload

Let me know what you think!

[mokimo]

This is very interesting, thanks for following up and doing the investigation on this. Definitely seems like preloading is yielding the better results

[yesil]

If there is an eager code in module scope(which should not), loading the file would cause it being executed which is not desirable.
I think preloading should be preferred as it will never alter the normal waterfall of actions.