The Illusion of Fast Websites: Gaming the Lighthouse Score

The web performance community is caught in a rather misleading cycle. People often mistake the Lighthouse score for actual web speed. This misconception is exploited by plugin developers who focus on improving this metric without enhancing the true speed of the website.

There is no shortage of plugins on the market promising one-click website acceleration. Let's mention WP-Optimize, WP Rocket, or Website Speedy. However, their impact often results in merely improving the Lighthouse score.

They primarily achieve this by deferring all JavaScript loading. This might improve one metric but degrade others, potentially harming your analytics.

For the sake of this article, we scrutinized Website Speedy more closely and, through client experimentation, discovered that disabling the plugin returns the Lighthouse score to normal values but does nothing for the website's speed.

Moreover, we observe some rather suspicious testing detection, suggesting that a website tested with Lighthouse might behave differently from when it's used by real users.

Lighthouse Score: A Flawed Metric Yet Everyone's Favourite#

Every month, during client onboarding at PageSpeed.ONE, I speak with someone eager to "improve their PageSpeed Insights score". You know, that colourful little circle. Yes, the Lighthouse score.

We understand this. It's a single, colourful number, easy to share with colleagues over Slack. However, the Lighthouse score is the result of a synthetic test of a single page, in a single environment, with a single configuration. The composition and weights can change between Lighthouse versions. Similarly, Lighthouse on your computer might show a different number than Lighthouse in PageSpeed Insights.

Let's reiterate:

The Lighthouse score is not a web speed metric. It is a technical diagnostic indicator.

Are you also looking at the wrong place in PageSpeed Insights?

Web speed emerges not in Lighthouse but in the phones of your visitors, on pub Wi-Fi, on an old Chinese smartphone with three signal bars, ten open tabs, and during cookie consent clicks.

Lighthouse doesn't see this. It isn't a user. Lighthouse doesn't scroll, click, log in, open product filters, or reach checkout.

True speed is measured by Core Web Vitals metrics from the Chrome UX Report database. (Differences between lab and real user data are summarized in synth vs. CrUX vs. RUM.)

An Economist Would Say: "Of Course, Goodhart's Law"#

Economist Charles Goodhart once penned a sentence now taught at universities:

"When a measure becomes a target, it ceases to be a good measure."

This fits perfectly here. The Lighthouse score has become exactly that.

People want a simple number. Google (somewhat misguidedly, in my opinion) displays it prominently and colourfully in PageSpeed Insights.

Clients inquire about the Lighthouse score with agencies. Some agencies then promise to improve it. Then come the plugins, promising the same, just faster and effortlessly.

When a diagnostic number becomes a commercial argument, a market for its improvement emerges. And once the calculation is predictable, someone starts hacking the metric instead of optimizing the site.

Deferring JavaScript is Not Optimization, but Problem Shifting#

A vast number of today’s "speed-up" plugins have a single checkbox that can boost the Lighthouse score by tens of points in five seconds. They defer all JavaScript execution to the first user interaction. Scroll, click, screen touch.

Why does this work so reliably to hack the Lighthouse score? Lighthouse loads the page and measures. It doesn’t scroll, click, or touch the screen. Deferred JavaScript, therefore, never runs during the test. Metrics like Total Blocking Time (TBT), which carry the most weight in the Lighthouse score, disappear from measurement. The loading speed (LCP) also improves.

The Lighthouse score shoots up, yet nothing speeds up on the site. For real users, nothing changes. It merely shifts to later – often the worst possible moment.

Illustration of JavaScript deferral. Scripts load only after user interaction. It's evil.

At PageSpeed.ONE, we've optimized hundreds of sites, but we've never recommended this technique to clients. What are the risks of deferring all JavaScripts?

1. Negative impact on interactions (INP). A user arrives on a page, reads the headline, and clicks. At that moment, all deferred JavaScript, accumulated till then, runs. The browser's main thread blocks, and the user's first click waits. This can worsen the INP metric, which Google includes in Core Web Vitals.
2. Negative impact on layout shifts (CLS). Scripts that render content, such as carousels, personalization, and more, run late if JavaScript is deferred. In a Lighthouse test, no shift is measured because the code never runs. Thus, you don't see the real CLS value.
3. Measurement functionality. Analytics, cookie consent, chat, A/B tests, and conversion tracking defer along with everything else. Your data might not align, and no one knows why.
4. Devaluing the Lighthouse score. As mentioned, the Lighthouse score isn't a web speed metric, but it's useful for diagnosing changes or optimizations. With no JavaScript in the Lighthouse score, you're measuring something entirely different from your website.

Deferring all JavaScripts is a poor technique. Deciding what to load when and in what order is engineering work that requires knowledge of the specific site. A single checkbox deferring all JavaScript doesn't replace this work.

And the most problematic issue in the end. Providers of these features usually do not state what this will do to the Lighthouse score and how it might jeopardize real user speed. If they did, customers would realize they're often buying not a faster website but merely a better test number.

WP-Optimize: Caught Optimizing the Lighthouse Score#

In 2022, developer Gijo Varghese published a screenshot of the WP-Optimize plugin, showing JavaScript loading only when the browser isn’t Lighthouse, GTmetrix, headless Chrome, or Pingdom.

The WP-Optimize code snippet shows an attempt to detect Lighthouse, Pingdom, or GTmetrix.

The maker of this WordPress optimization plugin publicly denied the allegations, claiming it was a specific "Defer using JavaScript" setting.

Fine, but why is this setting there at all? We're back to the point that no genuine speed optimizer would do this. General WordPress speed tips can be found in optimizing WordPress.

WP Rocket: Where Optimization Ends#

The well-known optimization plugin WP Rocket faces a similar issue. It also features a function with the innocuous-sounding name Delay JavaScript Execution. Activate the checkbox, and all scripts wait until the user scrolls, clicks, or touches the screen.

Details were written as early as 2021 by Alexander Goller in an article, which rightly compares this issue to the Dieselgate emissions scandal, where Volkswagen cars altered engine settings during emissions tests to meet required values.

What’s the current state? This setting still exists in WP Rocket. On the page for setting JavaScript deferral, WP Rocket simply claims it's one of the most powerful optimizations.

Just a harmless plugin setting? I don’t think so. Nowhere on the feature page does WP Rocket mention what this does to the Lighthouse score. And that’s a problem.

WP Rocket only highlights the benefits of "Delay JS execution", not the risks.

So both WP-Optimize and WP Rocket continue to sell this feature without warning that it may artificially boost the Lighthouse score and the other risks I’ve outlined above.

Website Speedy: Enhancing Speed or Lighthouse Score?#

Website Speedy is a tool for several platforms, claiming to be an "Automatic Website Speed Optimizer". One of our clients believed this and used the add-on for months, thinking it was helping the site’s speed.

However, our colleague Michal Matuška discovered that this add-on might merely artificially boost the Lighthouse score. Judge for yourself.

Website Speedy promises impacts on bounce rate and SEO rankings on its homepage.

Our Investigation Around Website Speedy#

It starts with the very website, where "business metric impact" and "Lighthouse score" are lumped together. Speed certainly affects business, but this cannot be linked to a synthetic metric.

The marketing of these extensions relies on users who believe the Lighthouse score is web speed. And there are many.

The authors of Website Speedy admit this in communication with us:

"Our dashboards and documentation currently lead with lab scores, and we do not spell out that lab results can differ from what real users experience."

In the Source Code of Website Speedy, We Found Testing Tool Detection#

Our colleague Michal couldn't resist examining Website Speedy's source code. It is heavily obfuscated, intentionally obscured.

After decoding through several AI agents, we found a condition in the code that decides whether JavaScript on the site runs at all. And what do you think? Yes, it doesn’t run if it detects speed testing.

Before publication, we asked Website Speedy for their stance. Founder Ishan Makkar responded swiftly:

"Our script does not detect or branch on Lighthouse, PageSpeed Insights, GTmetrix, headless browsers, or any synthetic testing environment."

He added that he personally reviewed the code on several live customer sites and could not replicate our findings. He offered us a clean demo with his current production version to verify ourselves.

The demo arrived on August 18. Our colleague Michal Matuška found this in its script:

A snippet from Website Speedy's demo code. The hack was hidden from us.

The function is called isAuditBot, meaning "is it an audit bot". The very first line returns false, so in the demo they provided, the entire detection never executes. In the script from our client’s site, it wasn’t disabled.

Incidentally, in that dead code section, strings are tested that suspiciously resemble the names of the most common synthetic measurement tools, such as GTmetrix, Lighthouse, PageSpeed, WebPageTest, and Headless Chrome.

As proof of innocence, we were given an installation where the detection of testing tools was stripped in the quickest way possible.

What Happened When We Disabled Website Speedy on the Client’s Site?#

We agreed with the client to temporarily disable Website Speedy. We can see quite clearly what happened to speed when the plugin stopped working. Almost nothing.

The Lighthouse score took a nosedive...

Change in Lighthouse score of the homepage after disabling Website Speedy.

After disabling Website Speedy, the Lighthouse score on the homepage changed from 95 points to about 60. Did it worsen? No, it normalized.

However, disabling the plugin had no impact on Core Web Vitals:

Development of Core Web Vitals after disabling the Website Speedy plugin.

We see no change except for other influences occurring on the site:

• A slight slowdown in site speed (LCP) correlates with a fluctuation in TTFB (backend response).
• CLS improves by modifying another site feature, unrelated in time.
• It’s worth remembering that Google’s CrUX data shows a cumulative 28-day state, so changes manifest over a longer period.

Disabling Website Speedy led to a normalization of the Lighthouse score on our client’s site. But the site’s speed remained unchanged.

Our Methodology and What We’re Not Claiming#

To be fair, we should clarify the methodology of our investigation around Website Speedy:

• Website Speedy does not wish to disclose the plugin’s source code, so we are only publishing the source code of the demo they provided, which differs from the plugin’s source.
• We experimented on one of our client’s sites.
• We lack quantitative data from more projects.
• Disabling the plugin and our code examination occurred in July 2026.
• Other than disabling the plugin, we did not further optimize the site.

The Website Speedy plugin kept the Lighthouse score high for our client, without delivering measurably faster web speed to real users.

One problem lies with the plugin authors. But the bigger issue is with the users who pay for these plugins.

Don’t Dismiss Lighthouse. Just Don’t Make It the Goal#

Use the Lighthouse tool as a diagnostic. It will find a slow image, an unnecessarily large JavaScript bundle, or blocking CSS. For these purposes, Lighthouse is excellent.

Web speed? Look at Core Web Vitals. Full stop.

As your main business metrics for web speed, monitor data from real users. Core Web Vitals from the Chrome UX Report or data from your own measurements (RUM). Monitor the entire domain and the most important templates in monitoring, not just a single URL occasionally.

We know the demand for a single score for everything is high, so at PageSpeed.ONE, we also use our own PageSpeed.ONE Score, built on user data metrics from Core Web Vitals.

In our one-time web speed test, we also de-emphasize the Lighthouse score as much as possible. Instead, we show Core Web Vitals trends and a verbal assessment of the speed status.

If you want to verify a similar case yourself, the following approach will help.

How to Investigate a Suspicious Jump in Lighthouse Score#

Checklist for detecting suspicious Lighthouse score hacking:

• Start by asking if the score jumped suspiciously quickly after installing a plugin or after a single configuration change.
• Compare network requests and executed JavaScript in Lighthouse with regular browser loading.
• Verify first scroll, click, cookie banner, filter opening, form, and checkout. Lighthouse doesn't scroll or click, but users do.
• Check user data (CrUX or RUM) before and after the change. Greener lab scores without improved user data is not a win.
• And most importantly: stop buying plugins that promise miraculous speed-ups with one click.

Next time someone offers you a plugin that magically boosts your score in five minutes, ask them one thing:

What impact will it have on real user speed, specifically Core Web Vitals? If they can't answer that question, you already have your answer.

Keep your websites fast. And measure speed correctly.

Tags:Web PerformanceLighthouse