PageSpeed Insights, WP Rocket and the Volkswagen Emissions Scandal

Google PageSpeed and Google Lighthouse

Ever since the introduction of Google PageSpeed over a decade ago in 2010, website owners and developers have been striving to achieve the best scores. For a few years, I had a target score of 85 or better in my freelance contract whenever I built a new website for a client. If they wanted to have a score above 85, I charged them extra in different tiers depending on what their target score was. In 2016 Google released Lighthouse, a tool that generates more granular scores for different aspects of a website (Performance, PWA, Accessibility, SEO, and Best Practices).

In the past few years, there has been a big push to get these scores to 100—and subsequently sharing a non-conclusive screenshot of the score on social media to show how much one has optimized one’s homepage. Often when optimizing the Performance score, there are trade-offs involved in measurable vs perceived performance. The task of achieving a score of 100, preferably without understanding what the individual metrics mean, has reached the WordPress ecosystem. Consequently, more and more plugins try to provide one-click tools to allow users without the technical knowledge required to get perfect scores. Perfect is what we should all strive for, right? Right?!

WP Rocket’s Delay JavaScript Feature

Let me start off by saying that I don’t have an issue with WP Rocket in general. I think it’s a good caching plugin, and I’ve been a paying customer for many years. I do, however, object to their decision to delay all JavaScript on the site with the click of a single checkbox.

The feature is this: Delay loading and execution of JavaScript until user interaction (scroll, click, touch, etc.) is detected. This has been in WP Rocket since version 3.7 and hasn’t caused too much trouble as users needed to add the scripts they wanted to be delayed manually. With version 3.9 WP Rocket has made an unfortunate decision: By activating the feature, all JS on the page will get delayed by default and users can exclude certain files from this feature. Instead of block-listing scripts, users now have to allow-list them, which impacts all other plugins in the WordPress installation and shifts the responsibility from WP Rocket to all other plugin developers.

WP Rocket is not the only plugin that has a feature like this in their toolbox, but they are the first I know of that have shifted the responsibility to other plugins. For the user it looks like other plugins are not working because if there are JS errors on the page after activating the feature, these do not point to WP Rocket but other plugins. I have built a small plugin to demonstrate an issue: A ready handler that checks if the document has loaded and either executes the passed callback right away or defers it until the complete status of the document.readyState has been reached. The provider fires a custom event and the consumer attaches a listener to this event. Think of it like this: In a freemium WordPress plugin model, the provider is the JavaScript delivered by a main plugin and the consumer is an add-on to this plugin waiting for the main plugin to be “ready”.

If you install this plugin from GitHub, you’ll see that without activating the “Delay JavaScript” functionality of WP Rocket, the event dispatcher gets registered, the event listener gets added, when the document loading is complete, the event fires and the callback is executed.

Compare this to what happens, when you activate WP Rocket’s feature: The event dispatcher gets registered, the document has already reached the complete state, the event fires immediately before the event listener gets attached to the event and therefore the event is never handled, and therefore the callback never gets executed.

By delaying all scripts by default, WP Rocket breaks any JavaScript that relies on the document.readyState. When a user of my demo plugin now sees that my plugin does not work as intended, they will issue a support request with me. Depending on the technical expertise of the user, it might be really hard to convey to them that the issue is not in my plugin, but WP Rocket’s feature.

The Volkswagen Emissions Scandal

In 2015, the United Status Environment Protection Agency (EPA) issued a notice of violation of the Clean Air Act to Volkswagen. VW had programmed their TDI Diesel cars to identify when they were tested under laboratory conditions, and activate an emissions control system to meet the emissions standards set by the EPA for Diesel cars in the US. When these cars were out on the road, they emitted up to 40 times more NOx fumes than permitted by the EPA.

Maybe you can see where I’m going with this, the feature added by WP Rocket is like the “defeat device” in VW Diesel engines. It can detect if the webpage is being tested under laboratory conditions and not execute JS, which greatly improves the Google PageSpeed Insights and Lighthouse scores. When the website is “out on the road”, however, it not only “emits” the JavaScript but it also breaks JS added by other developers.

When I had PageSpeed target scores in my contract, my clients didn’t expect me to solely optimize for that score, but to improve overall performance of the website in doing so. If I had utilized the feature described above to optimize for this score, this could have been considered fraud; at the very least, it would have been a dishonest practice.