Reminder: pre-mature optimization

[auniverseaway]

All of this was covered in Milo Academy, but I want to remind folks:

It's a matter of when not a matter of if Milo becomes a big complicated mess of code that no one wants to work in. In many areas, I could already argue this point. Our mission as a community is to have Milo live as long as possible

It is all of our responsibility to do the work up front that asks, "What benefits am I getting by making this code more complicated?" If you do not know, you should not ship. You could even distill it down more simply: "What benefits am I getting by writing this code?"

Part of what makes Milo performant is knowing at an extremely fine grained level what to load concurrently and what to load linearly. If we were to load everything at the exact same time (promise-based), our scores would drop. If we were to load everything concurrently (await-based) our scores would drop. Being able to truly understand when to use what pattern is what keeps Milo performant while also being as simple as possible. This is why we went through the exercises of forEach vs for loops in Milo Academy.

This is also not just about performance. I recently had an engineer propose adding something to our config object that was only ever going to be used in utils.js. There are specific parts of Milo I would call sacred, and config is one of them. When you add an object into config, that is another property we are blasting to nearly every module on Milo. Every downstream engineer has to say, "This is here, is it important to me?" Pile enough of these up over the years and our config object will balloon with irrelevant properties and it will become more and more brittle.

I will leave everyone with the following example:

loadStyle('/my-special/style.css');
const { default: doThing } = await import('/my-feature.js');
doThing(myVar);

vs

const stylePromise = new Promise((resolve) => {
  loadStyle(`/my-special/style.css`, resolve);
});
const loadModule = import('/my-feature.js')
  .then(({ doThing }) => doThing(myVar));
await Promise.all([stylePromise, loadModule]);

Which one is more readable?

Which one is less complicated?

Which one is more performant?

Before you say the second is more performant, can you categorically say this without research? What if the CSS file size is such that it doesn't need to be concurrently loaded? Same for the JS? Did the engineer proposing the second variation do the work to validate this?

[yesil]

Hi Chris, since you copied my code to make your point, let me explain: I changed the code as follows to prevent a CLS from happening.
Actually this is how Milo works, see: https://github.com/adobecom/milo/blob/main/libs/utils/utils.js#L430

If I don't await the style, it causes a CLS.
This is not an attempt to optimize for performance other than loading the css and processing the js in parallel as it is already done in Milo.

    const stylePromise = new Promise((resolve) => {
      loadStyle(`${base}/blocks/mnemonic-list/mnemonic-list.css`, resolve);
    });
    const loadModule = import('../mnemonic-list/mnemonic-list.js')
      .then(({ decorateMnemonicList }) => decorateMnemonicList(foreground));
    await Promise.all([stylePromise, loadModule]);

[auniverseaway]

FWIW: this example is all over in Milo, not just your code. And I think it's great, but it also shows that we should be asking these questions... which is the whole point of my post. For every time this pattern makes perf better, there's other examples where it doesn't really matter.

I don't await the style, it causes a CLS.
This is not an attempt to optimize for performance

Optimizing CLS is the very definition optimizing for performance. If you have CLS, your code is not performant as it will impact both CWV and LH.

[yesil]

However optimizing CLS is not pre-mature optimisation.
Considering CLS has impact on the user experience, even if Pagespeed stops taking CLS into account for the performance score, I believe we will still continue striving for 0 CLS.

If you have CLS, your code is not performant

I disagree, if there is CLS, One can say the code is not good, but often you can get a lower/better FCP/LCP and give the impression that code is more performant. I think it depends on how the performance is measured.