Cloudflare Rocket Loader and Core Web Vitals

And when I say "they", I even mean myself. The goal of Cloudflare's Rocket Loader is to defer JavaScript execution without having to re-organize your codebase. And as JavaScript is one of the bigger bottlenecks when it comes to (mobile) performance, deferring it often is very welcome.

Why you want to address JavaScript

Cloudflare has written an article about Rocket Loader and the history of JavaScript. Back in the days, you would just use inline JavaScript. But when the src-attribute was introduced, we could serve a whole bunch of JavaScript to desktop computers (yes, we had an era without mobile devices, let alone mobile devices you could use to visit webpages).

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.

Pitfalls of deferring JavaScript

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.

However, as we are using more JavaScript libraries today, this is likely to break other JavaScript, leading to undefined functions or variables. Especially the way we build websites and webshops today, this could result in time-consuming changes of the codebase.

Meet Cloudflare Rocket Loader JS

That's where Cloudflare Rocket Loader JS comes in. Cloudflare is able to defer all scripts you allowed to be deferred in the first place. This is basically done by telling the browser those script-elements aren't real JavaScript elements. Let's call them pseudo-scripts from now on. The browser will just skip those pseudo-scripts and as a result those script won't be render and parse blocking anymore.

But those files still have to be executed at some point. That is the job of the rocket-loader JavaScript as provided by Cloudflare. The file URL could be as following when cloudflare CDN is being used:

https://ajax.cloudflare.com/cdn-cgi/scripts/7089c43e/cloudflare-static/rocket-loader.min.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 subtly change the user's perception of how a page loads, benefitting both early engagement, user happiness, bounce and conversion.

Cloudflare Rocket Loader benefits

On pages with JavaScript, Rocket Loader JS does come with performance gains for certain metrics:

• First Paint (FP);
• First Contentful Paint (FCP);
• First Meaningful Paint (FMP);
• Document Load.

Rocket Loader prioritises your website's content (text, images, fonts etc) by deferring the loading of all of your JavaScript until after rendering

support.cloudflare.com

Each automated optimizations has its place and time, but often also its price. And while Rocket Loader might seem to help for webpages with JavaScript, this Cloudflare invention is also causing the biggest UX bottleneck because of the way we build websites today.

Then Core Web Vitals came around

Although Rocket Loader is likely to improve First Contentful Paint or even First Meaningful Paint, our understanding of what really is important towards user experience changed over the years. I guess we already knew what was important when it comes to user experience (UX) and conversion rate optimization (CRO), we (Google via Lighthouse) just 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.

The Cloudflare Rocket Loader JavaScript para­dox

How does Core Web Vitals play a role? Maybe we're asking the question the wrong way round, and instead we should ask ourselves how JavaScript is impacting UX.

With Javascript, website elements are rendered on the client, within your device. And while deferring the loading of all of your JavaScript until after rendering sounds like a good idea, it obviously is also deferring rendering of those (potentially important) elements when no optimal performance or UX strategy is being applied.

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 Cloudflare Rocket Loader JS might not be a good idea:

• First of all, remember that when execution of first party JavaScript depends on an external file, this is a single point of failure construction when you aren't self-hosting the rocket-loader.min.js file. This could break your shop's cart, checkout et cetera (remember Cloudflare's latest outage?);
• 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 Cloudflare Rocket Loader!