Render blocking JS? Use Rocket Loader JS they said! But then Core Web Vitals came around, changing things 😕 However, Rocket Loader already came with a handful of pitfalls:
But any non-deferred script element with an src-attribute would block rendering. Back in the days and even today. This might be one of the most seen performance recommendations when using Lighthouse or PageSpeed Insights.
As using defer or async didn't exist back in the days, you could move the script-element to the bottom of the page. It would still block rendering, but there is no more (meaningful) HTML left to render anyway.
Meet Cloudflare's Rocket Loader JS
Switching back to real scripts
All pseudo-elements are then turned into real script elements. As a result, the order of the scripts will be maintained. The strategy is basically the same as using the defer-attribute on your script-elements, where the order of execution will be maintained as well, unlike using the async-attribute.
Deferring of those scripts is done on the fly. A developer doesn't have to worry about manually maintaining and deferring scripts. Easy peasy, right?
But should you use Rocket Loader to improve performance?
When we talk about performance, we are obviously also talking about technical UX. Consider perceived performance for example, where you could subtily change the user's perception of how a page loads, benefitting both early engagement, user happiness, bounce and conversion.
Rocket loader benefits
- First Paint (FP);
- First Contentful Paint (FCP);
- First Meaningful Paint (FMP);
- Document Load.
Then Core Web Vitals came around
Although Rocket Loader is likely to improve first contentful or even meaningful paint, our understanding of what really is important towards user experience changed over the years. I guess we always knew what is important when it comes to user experience (UX) and conversion rate optimization (CRO), we got better in tracking this.
Metrics such as First Meaningful Paint got replaced by Largest Contentful Paint. Elements jumping around and pushing other content down never is a good experience, hence the new Cumulative Layout Shift metric. These metrics got introduced within Lighthouse version 6, already being used by PageSpeed Insights as well. As a matter of fact, Google was already tracking these metrics for a while and is now available within their CrUX dataset.
As a few of these metrics appeared to play an important role within user satisfaction, three metrics were bundled into the Core Web Vitals. Google found that when a site meets certain thresholds, users are 24% less likely to abandon page loads. GTmetrix already adopted Core Web Vitals and thus changed their minds about the right performance metrics.
This is likely to result in metric degradation, causing your site not to pass the Core Web Vitals assessment and maybe negatively impacting your ranking. This is why Rocket Loader JS might not be a good idea:
- It prevents the browser from detecting JS files early on, basically pushing back JS execution. Resource hints could be used to solve this to a certain degree;
- TTI, TBT and SpeedIndex metrics are likely to drop;
- When it comes to Core Web Vitals, deferred client side rendering of contents is likely to affect important metrics such as CLS and LCP as new contents might result in layout shifts and for example product slideshows will be launched later on. Be sure to render visual elements above the fold as soon as possible, especially when they are covering large portions of the screen due to their dimensions (such as product images);
- So, while your webshop's FCP is likely improve, the overall Core Web Vitals could get worse, impacting bounce / UX and (as of 2021) organic ranking.
A shorter version of this blog post was also posted on LinkedIn.
Happy speeding, but reconsider Rocket Loader!