Falsely Fast Websites: How Lighthouse Scores Are Hacked

The web performance community is caught in a deceptive cycle. People often confuse the Lighthouse score with actual web speed. This misunderstanding is exploited by plugin developers who aim to enhance this metric without genuinely improving web speed.

There are numerous plugins on the market promising one-click website acceleration. Notable examples include WP-Optimize, WP Rocket, and Website Speedy. However, their impact often merely improves the Lighthouse score.

They typically achieve this by deferring the loading of all JavaScript. While this might enhance one metric, it can degrade others and even damage your analytics.

We scrutinized Website Speedy more thoroughly for this article and discovered through client experimentation that disabling the plugin restored the Lighthouse score to normal levels, but did nothing for the web speed.

Moreover, we observed some very suspicious test detection, suggesting that a website tested with Lighthouse might behave differently than it does for actual users.

Lighthouse Scores: A Flawed Metric That Everyone Cares About#

During client onboarding at PageSpeed.ONE, I often encounter individuals wanting to "improve the score in PageSpeed Insights". You know, that little colourful wheel at the bottom. Yes, the Lighthouse score.

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

Let’s reiterate:

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, after all, doesn’t originate in Lighthouse. It’s born in the phones of your visitors, on pub Wi-Fi, on an old Chinese smartphone with three bars of signal, ten open tabs, and while clicking on a cookie banner.

Lighthouse doesn’t see this. It’s not a user. Lighthouse doesn’t scroll, click, log in, open product filters, or proceed to the checkout.

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

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

Economist Charles Goodhart once wrote a line that is now taught at universities:

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

This fits perfectly here. This is exactly what has happened with the Lighthouse score.

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

Clients inquire about the Lighthouse score with agencies. Some agencies promise to improve it. Then come the plugins that promise the same, only faster and without effort.

Once a diagnostic figure becomes a commercial argument, a market emerges for its enhancement. And once the calculation is predictable, someone will start hacking the metric instead of optimising the website.

Deferring JavaScript Isn't Optimization, It's Problem Shifting#

A significant portion of today’s "speed-up" plugins has a single checkbox that can boost the Lighthouse score by tens of points with five seconds of effort. It defers the execution of all JavaScript until the user's first interaction—scrolling, clicking, touching the screen.

Why does this work so reliably to hack the Lighthouse score? Lighthouse loads and measures the page. It doesn’t scroll, click, or touch the screen. Deferred JavaScript, therefore, never runs during the test. As a result, metrics like Total Blocking Time (TBT)—which weighs heavily in the Lighthouse score—disappear from the measurement. Load speed (LCP) also improves.

The Lighthouse score shoots up, yet nothing has sped up on the site. For real users, nothing has changed. It’s merely postponed—and often to the worst possible moment.

Illustration of deferred JavaScript. Scripts load only after user interaction. It’s quite the evil.

At PageSpeed.ONE, we’ve optimised hundreds of websites, 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 the page, reads the headline, and clicks. At that moment, all deferred JavaScript, which had accumulated until then, begins to run. 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, personalisation, and more—run late when JavaScript is deferred. Therefore, no shift is measured during the Lighthouse test because the code never ran. You don’t see the real CLS value either.
3. Measurement functionality. Analytics, cookie consent, chat, A/B tests, and conversion tracking are deferred along with everything else. Your data might not align, and no one will know why.
4. Devaluation of the Lighthouse score. As we mentioned, while the Lighthouse score isn’t a web speed metric, it is useful for diagnosing changes or optimisations. Removing JavaScript from the Lighthouse score means you’re measuring something entirely different from your website.

Deferring all JavaScripts is a poor technique. Deciding what should load when and in what order is engineering work that requires knowledge of the specific website. One checkbox that defers all JavaScript does not replace this work.

And the most problematic issue in the end: Providers of these functions generally do not state what this does to the Lighthouse score or how it can threaten real user speed. If they did, customers would realise they are often buying not a faster website but just a better test score.

WP-Optimize: Caught Optimizing Lighthouse Scores#

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

The WP-Optimize example shows code trying to detect Lighthouse, Pingdom, or GTmetrix.

The manufacturer of this WordPress optimisation plugin publicly denied the allegations. Allegedly, it’s a specific "Defer using JavaScript" setting.

Alright, but why is this setting there in the first place? We’re back to the point that no genuine speed optimiser would do this. General speed tips for WordPress can be found in our WordPress optimisation.

WP Rocket: The Boundary Where Optimization Ends#

A similar issue exists with the well-known optimisation plugin WP Rocket. It also includes a feature with the innocuous name Delay JavaScript Execution. You enable a checkbox, and all scripts wait until the user scrolls, clicks, or touches the screen.

Details were already discussed in 2021 by Alexander Goller in a post, aptly comparing this issue to the Dieselgate emissions scandal, where Volkswagen cars altered engine settings during emissions tests to meet required values.

What’s the situation today? This setting in WP Rocket still exists. WP Rocket’s page for JavaScript delay settings merely states that it’s one of the most powerful optimisations.

An innocent single plugin setting? I think not. Nowhere on the feature page does WP Rocket mention what this does to the Lighthouse score. And that’s a problem.

WP Rocket only mentions the advantages of "Delay JS execution", omitting the risks.

So, WP-Optimize and WP Rocket still sell this feature without warning that it might artificially boost Lighthouse scores and the other risks I discussed above.

Website Speedy: Speed Improvement or Lighthouse Score Enhancement?#

Website Speedy is a tool for several different platforms that claims to be an "Automatic Website Speed Optimizer". One of our clients believed this and used this plugin for months, thinking it was improving their web speed.

However, our colleague Michal Matuška discovered that this plugin could also artificially boost the Lighthouse score. Judge for yourself.

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

Our Investigation into Website Speedy#

It starts with the website itself, where "impact on business metrics" and "Lighthouse score" are lumped together. Speed indeed affects business, but this cannot be linked with a synthetic metric.

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

The creators of Website Speedy themselves 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 Website Speedy Source Code, We Found Test Tool Detection#

Our colleague Michal couldn’t shake the feeling about Website Speedy’s behaviour and decided to dig into the source code. It’s heavily obfuscated, meaning intentionally obscured.

After decoding it through several AI agents, we found a condition in the code that decides whether JavaScript will even run on the site. And guess what? Yes, it doesn’t run if it detects speed testing.

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

"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 couldn’t reproduce our findings. He offered us a clean demo with his current production version to verify it ourselves.

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

A snippet from the demo code by Website Speedy. The hack was hidden from us.

The function is called isAuditBot, meaning "it’s an audit bot". The 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 the dead remainder of the code, strings resembling the names of the most common synthetic measuring tools—GTmetrix, Lighthouse, PageSpeed, WebPageTest, and Headless Chrome—are being tested.

As evidence of innocence, we received an installation where test tool detection was stripped away 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 therefore see precisely what happened to the speed when the plugin stopped functioning. Almost nothing.

The Lighthouse score did deteriorate dramatically…

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

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

Disabling the plugin had no effect on Core Web Vitals:

Core Web Vitals development after disabling the Website Speedy plugin.

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

• A slight deterioration in the site's speed (LCP) correlates with a fluctuation in TTFB (backend response).
• CLS improves through another site feature adjustment and is not time-related.
• It's worth mentioning that Google’s CrUX data shows a 28-day cumulative state, so changes manifest over a longer period.

After disabling Website Speedy, our client’s site saw a normalization of the Lighthouse score. But the web speed remained unchanged.

Our Methodology and What We Don't Claim#

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

• Website Speedy does not wish the source code of the plugin to be published, so we publish only 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 do not have quantitative data from multiple projects.
• Disabling the plugin and our code examination took place in July 2026.
• Apart from disabling the plugin, we optimised nothing else on the site.

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

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

Don’t Discard Lighthouse. Just Don’t Make It a Target#

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. Period.

Monitor real user data as the primary business metrics for web speed. Core Web Vitals from the Chrome UX Report or data from your own monitoring (RUM). Track the entire domain and the most important templates in monitoring, not a single URL once in a while.

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

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

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

How to Check for Suspicious Jumps in Lighthouse Scores#

Checklist for uncovering suspicious Lighthouse score hacking:

• Start by asking if the score jumped suspiciously quickly following a plugin installation or a single configuration change.
• Compare network requests and running JavaScript in Lighthouse with a regular browser load.
• Verify the first scroll, click, cookie banner, filter opening, form, and checkout. Lighthouse doesn’t scroll or click, but the user does.
• Check user data (CrUX or RUM) before and after the change. A greener lab score without improved user data isn’t a victory.
• And most importantly: stop buying plugins that promise miraculous acceleration with one click.

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

What impact will it have on real user speed, like Core Web Vitals? If they can’t answer that, you already know the answer.

Keep your websites fast. And measure speed correctly.

Tags:Web PerformanceLighthouse