Erwin Hofman

If you do use multiple third parties, be sure to use the most appropriate (Google) Tag Manager trigger type. For example: Analytics at Page View. Session tracking at Dom Ready. Chats and reviews at Window Loaded. etc. RUMvision data showed that 50% of responsiveness (aka INP) issues are happening after 10 seconds. So, delaying scripts isn't the holy grail. RUMvision will not only show your sites biggest performance offenders, but it will also show you alterative and more lightweight solutions. You can then make educated decisions while keeping the same (or similar) 3rd party features.

"Time to Interactive" has been removed from Lighthouse already. Nevertheless, it's still correct that 3rd parties could impact performance, UX and then conversion as well. While TBT could be a good lab data/Lighthouse metric to get an idea of potential impact, INP is a matching field data (and soon Core Web Vitals) metric to see the real UX impact. And to see the exact offender per JS file, the new LoAF API (in origin trial at time of writing) could be used. To easily track those offenders (and if a 3rd party is actually your main bottleneck), tools could be used that track this by default. An article by Google and RUMvision: https://www.linkedin.com/posts/rumvision_pagespeed-ux-webperformance-activity-7144661668348796928-KJOb

There are some errors here that could be misleading: "most browsers load scripts synchronously" All of them will load them synchronously, unless you specified otherwise. Which can be achieved with the async or defer (already around since IE6) attribute. "This can cause [..] flickering" They won't. That's the whole point of render blocking. However, adding async could introduce flickering, depending on the purpose of a script. A/B testing scripts are known for causing this. Which introduced tge need for anti-flicker scripts. That actually comes with delays becauae of a different mechanism: https://www.erwinhofman.com/blog/core-web-vitals-ab-testing-best-practices/ When using GTM, be sure to use a proper trigger to prioritize 1st party JS.

Optimizing performance likely involves more hours in the beginning, but for sure doesn't mean you can then sit back and relax. A few examples are mentioned already. But on top of user behaviour etc, user conditions (their devices) or audience group in general could change as well along the way. Marketing activities is another example. I often see third parties being embedded, or new ads/campaigns being started, causing different query strings for your URL's, bypassing server side cache and regressing TTFB. You will only know when you continue monitoring Core Web Vitals and UX. To both spot unexpected changes, as well as gains (or regressions) after each deploy. This actually is the reason we founded RUMvision, to do exactly that.

Some non-arguments can be found here: Browsers already support lazyloading without JS (via the native loading=lazy attribute). Code splitting is only needed when you actually started using JS in the first place. And having a PWA doesn't mean you need to throw in a whole JS library. Even prefetching of next navigations can be done without JS. JS is always bad for performance. On an otherwise optimized site, try disabling JS and see how much better your experience will be. But the exact impact depends on your audience conditions, how much and how JS is used. Because: - JS adds interactivity - and partial client side rendering can be a better alternative, for example to fetch API reviews or stock-info. Just use it wisely and efficiently.

Stream prioritization does come with interesting nuances for sure. As described in the previous section, multiple downloads at the same time is an advantage of HTTP/2 over HTTP/1. Nevertheless, I've seen WebPageTest waterfalls that came with a FCP + LCP regression when many files were downloaded at the same time. Also note that HTTP/2 Server Push was removed in Google Chrome 106. To achieve the same, look into 103 Early Hints. From a security and privacy perspective, HTTPS should be considered non-negotiable by the way, even if it comes with latency.