Handle scripts loaded after window.onload better.

[pxwee5]

@connorjclark @patrickhulce

Following the discussion here #8698 (comment), I mentioned that the website I manage is penalised by Lighthouse for loading cookie consent script and third party scripts after window.onload.

What is the current behavior?

Here's the current loading sequence:

1. Preload initial scripts
2. Preload code split scripts
3. Load initial and code split scripts
4. Load images
5. Load other dynamically requested images/scripts
6. Page is rendered and window.onload is called
7. Load cookie consent and tracking scripts.
8. Cookie consent is rendered

I got 40 lighthouse points for doing this, which I think is probably the most efficient way to load third party scripts as pointed out by Addy Osmani's talk.

What is the expected behavior?

I did some test with the load event listener and without. Surprisingly, loading those stuff before load gave better results. But this is less efficient because third party scripts are blocking my codesplit js bundles.

I think Lighthouse should handle this better. Perhaps give less weight or ignore scripts loaded after the window.onload event. Happy to discuss this further.

[patrickhulce]

Thanks for filing @pxwee5!

tl;dr - we are working on a few new metrics that will improve things a little for this page, but we will not start ignoring the impact of late tasks. The real wins left here require reducing total execution time, not re-ordering anything.

IIUC, the root of your concern here is that you've followed the advice given to you but the score isn't very good. The remaining advice left to follow is to break up CPU work and reduce overall execution time. A few more specific thoughts on that:

• There's a difference between optimizing performance metrics given a fixed CPU impact and improving page performance. The ordering you've described sounds like you've followed all the advice and is the right blend for UX and perf, it is "efficient" given all the execution that needs to be done. Unfortunately with ~5-7 seconds of main-thread execution, the ceiling is pretty low. If it takes ~3 seconds to get a paint and we spend 5s more on the main thread, the best possible TTI you could hope for is 8s regardless of any artificial delay for the consent messaging. The real improvements now come from reducing the amount of time spent executing.
• Perfect performance does not mean perfect UX, and not every change that improves the UX will improve performance. When it comes to delayed modals and GDPR consent forms, we're intentionally making the experience delayed (worse performance) to improve the user experience of not being assaulted immediately with the dialog and presenting the important content first. There's a tradeoff made here and we're always trying to close the gaps in our metrics suite (new metrics in the works like largest contentful paint, total blocking time, and layout stability should help).
• Late tasks are important to capture because they do impact the user experience. Late tasks prevent user input from being handled and because they are after the page has rendered, the user is likely to be trying to give the page input!

Hope this helps!

[pxwee5]

Understood. My JS execution time isn't great due to the fact that I'm relying on Javascript to parse a PHP rendered HTML page, which is a limitation that I inherited. This creates the biggest JS parsing/execution chunk (800ms), which is unlikely to be broken up. However, this will be fixed later when we implement SSR.

Fact is code-splitting has allowed me to break up my entire bundle which allowed for better performance. I'm just super surprised that I am badly penalised in Lighthouse for loading some of those scripts after window.load (late tasks). But these are quick to parse/execute so I have no issues with them loading late. I understand that I'm loading some heavy JS here it could block user input and these definitely should impact Lighthouse score.

Hopefully the new metrics that you've mentioned can help with the score a little bit.