Make Use of Preload

[TsayAdobe]

While investigating the performance issue of this page, I noticed this page's marquee has a fragment, which has a video modal. All of the related blocks and features have to be initialized before LCP. The performance chart shows a scattered network calls on the timeline.

Milo uses a lot of dynamic imports and fetches. If there is a chain of imports, it becomes a series of back-to-back network calls. In this case it delays LCP.

We can use preload to pack network calls together. For example, icons.svg can be preloaded

async function decorateIcons(area, config) {
  ...
  loadLink(`${base}/img/icons/icons.svg`, {rel: 'preload', as: 'fetch', crossorigin: 'anonymous'})
  ...
}

What should be preloaded may depend on the content. As a simple solution, we can have a map of preloads for each block. Scripts that are highly likely to be loaded can be added to the map. e.g.

/libs/utils/utils.js

const MILO_BLOCKS_PRELOADS = { marquee: ['/utils/decorate.js', '/utils/helpers.js'] };

export async function loadBlock(block) {
  ...
  MILO_BLOCKS_PRELOADS[name]?.forEach(preload =>
    loadLink(`${base}${preload}`, {rel: 'preload', as: 'script', crossorigin: 'anonymous'})
  );
  ...
}

The preload map can alternatively be in the consumer app. We can also make a smart preload decider, which finds preloads based on the content. With a simple preload map, I saw a more compact timeline and LCP was improved.

[sharmrj]

This is a good idea. We could get even greater gains[0] by doing something similar on the edge (without necessarily modifying markup) using 103 Early Hints (MDN article, Cloudflare docs). Though we'd have to do some minimal parsing of the html if we were to send hints based on the markup.

[0] - Since we won't have to wait for js to be downloaded, parsed, JITed, and executed before we can add the preload. With 103 it can happen even as the html is downloaded.

[npeltier]

i'd be curious to see figures of a trial of it. This would be a huge "loss" in terms of flexibility and content driven code. This goes in the way of what we had back in the day of loading huge chunks of unused CSS / JS.
Having said that i still think it would be interesting to get figures that would help discussing it further :)

[mokimo]

Given the PR as further context, I'd guess this would only be used in cases of where we already know a certain code path will be loaded and trying to parallelize load times.

Given the findings in the image this gets the LCP in 3.4s rather than 5s due to waiting for other pieces to finish loading first.

[mokimo]

I'd wonder on how this compares if something else was the LCP or if there are cases where this would lead to a performance degradation

[mokimo]

Reviving the discussion, here's a PR of implementing the proposal from @TsayAdobe #2493 - to me it does seem to carry the exact risk you mention @npeltier - I'm not sure if that should live in milo core, or within consumers that are more knowledgeable about their specific LCP elements.

IMO Milo should be agnostic and not rely on any hardcoded behavior or preloads, if consumers want to do that - those discussions serve a great ground for experimentation and knowledge sharing of what works for certain consumers and might also work for others.

[auniverseaway]

I think this is great. It's overhead, but it makes a ton of sense. You cannot know marquee.js needs decorate.js until it's parsed... and that creates a chain.

I do think this masks some root problems we have that should be explored more in-depth:

1. Icons should be loaded post lcp
2. we should not load video.js if the breakpoint doesn't apply.
3. We should lazily load modal.js and not make it required for the LCP section to show.

But the above would also create different types of complexity. I see the initial proposal as really good.

The way I see this working would still be content dependent, so you are really only preloading when a particular block is called and we know the parallel dependencies are involved. We cannot do this with fragment content, but you still parallelize after the HTML is parsed and you know what blocks to load.

Very cool.