DEV Community: Martin Michálek

Delaying all JavaScript doesn’t make your site faster

Martin Michálek — Tue, 22 Sep 2026 17:55:36 +0000

This one annoys me. A lot of today's "speed up your site" plugins ship a single checkbox that lifts a Lighthouse score in the blink of an eye.

What it does is delay the execution of all JavaScript until the first user interaction — a scroll, a click, a tap.

*This is wrong.*

For real users, though, nothing gets faster. It can make things slower, and it can quietly break your analytics.

It is a small con trick that our whole industry keeps tacitly accepting.

This is an expanded version of one section from Fake fast websites: how Lighthouse scores get hacked, which I published on the PageSpeed.ONE blog. Here I look at this one technique only, and mostly at the specific plugins that sell it.

Delaying all JavaScript sounds like a clever move — so why have we at PageSpeed.ONE optimised hundreds of sites and never once recommended this technique to a client?

Why it is wrong, yet works on Lighthouse so reliably {#why-it-works}

Lighthouse loads a page and measures it. It does not scroll, does not click, never touches the screen.

Delayed JavaScript therefore never runs during the test. Total Blocking Time disappears from the measurement — and that is the single heaviest metric in the Lighthouse score, a full thirty percent of it. LCP improves too, because the browser has nothing to execute.

The score jumps up while the site itself got no faster. The JavaScript merely moved to later, often to the worst possible moment.

*Delayed JavaScript: scripts only load after a user interaction. It is evil.*

I am not alone in this view. Barry Pollard, who works on web performance at Google, named the pattern a while back:

"A common pattern I see is to delay ALL JS until the user interacts with a page: Great for Lighthouse scores! Often terrible for users."

– Barry Pollard, Google Chrome

So what exactly is wrong with delaying everything?

Four risks of delaying all your JavaScript {#risks}

It hurts interactions (INP). A visitor lands on the page, reads the headline and clicks. That is the moment all the accumulated JavaScript fires at once. The main thread locks up and the user's first click waits.
It hurts layout stability (CLS). Scripts that render content late — carousels, personalisation — now run late. The Lighthouse test measures no shift at all, because that code never ran. So you cannot see your real CLS either.
Your measurement stops working. Analytics, cookie consent, chat, A/B tests and conversion tracking all get delayed along with everything else. Your data stops adding up and nobody knows why.
It devalues the Lighthouse score. The score is not a measure of real-world speed, but it is useful for diagnosing changes. Strip all JavaScript out of it and you are measuring something other than your site.

Let me be precise about the first point. There is no public field study measuring INP getting worse after this feature is switched on. What we have is a mechanism, described by people at Google, plus an admission from WP Rocket that INP did not improve in their own test. That is a strong indication, not a measured impact.

Let me stop being polite and name the offenders.

The offenders. Which plugins ship this {#plugins}

We went through the best-known WordPress optimisation plugins and the so-called one-click optimisers. For each one we looked for three things: what the setting is called, whether it is on by default, and whether the documentation mentions the risks.

Plugin	Setting	Default	Warns?
WP Rocket	Delay JavaScript Execution	off	no
LiteSpeed Cache	Load JS Deferred → Delayed	off	yes
WP-Optimize	Delay JS	off	partly
Perfmatters	Delay all scripts	off	no
NitroPack	Delay non-critical resources	on in Ludicrous	partly
WP Meteor	Infinite Delay	off	yes
Autoptimize Pro	Delay JavaScript (timeout 0)	off	yes
SpeedyCache	Delay All	off	yes

That last column needs explaining. "Partly" means the docs only warn that your site might break, while saying nothing about the effect on the Lighthouse score or on users.

Only one plugin, SpeedyCache, also warns you that your analytics will break.

Two rows deserve a comment.

LiteSpeed Cache has two paths to the same result. The direct one is Load JS Deferred set to Delayed: scripts wait for interaction, it is off by default, and the docs warn about the risks. The other is Guest Optimization — a bundle of maximum optimisations for first visits and bots. Guest Mode, without which Guest Optimization does nothing, starts off, so a fresh install does not ship this technique on its own. But once Guest Mode is on (or a hosting preset turns it on for you), Guest Optimization can silently force Delayed mode, even if Load JS Deferred is set to OFF. The bug report claims that is the default on Hostinger; Hostinger does not confirm it in its own docs, so treat that as a signal, not a fact.

WP Rocket changed the rules in version 3.9. Until then you had to list the scripts you wanted delayed. From 3.9 on, everything is delayed and you list the exceptions instead. For new users that exception list starts empty, so the moment you enable the feature, absolutely everything gets delayed. To be fair: WP Rocket does mention the INP risk, but on a different and far less visited help page. On the page for the feature itself, there is not a word about it.

A good honesty indicator is the timeout. Plugins that enforce a time limit will eventually run the script even without interaction, so Lighthouse sees it. Products with no timeout, or that let you set it to zero, wait for an interaction forever. That smells a bit like optimisation for the test alone.

The vendors know. Some even wrote it down {#vendors}

We do not have to speculate about whether vendors know what their feature does to speed tests. Some of them have it in black and white in their own documentation.

WP Rocket, on releasing version 3.9:

"This means the JavaScript files won't be detected by Lighthouse… Is that cheating? Not really if you consider the following points…"

– WP Rocket blog

LiteSpeed goes further in its docs and admits the feature also masks a site's real problems:

"This setting can greatly improve page speed scores… Additionally, Guest Optimization can 'mask' any real problems your site may have."

– LiteSpeed Cache documentation

And Frank Goossens, the author of Autoptimize, wrote this about the option to set the timeout to zero:

"Setting the delay to 0 is a bit shady because at that point you are hiding those assets for performance tests."

– Frank Goossens

The numbers WP Rocket published with the 3.7 release are worth a mention too. On their own site, this feature moved the mobile score from 46 to 86 points. Meanwhile their own INP write-up states that the INP value did not change.

*WP Rocket writes only about the benefits of "Delay JS execution" and leaves out the risks.*

Careful, not everyone who looks like an offender is one {#not-every-offender}

The word "delay" gets used pretty loosely in plugin land and it is easy to get burned. These features do not delay until interaction, even if the name suggests they might:

Breeze by Cloudways has a "Delay All JavaScript" setting, but it actually adds the defer attribute and loads scripts as modules.
Jetpack Boost and its "Defer Non-Essential JavaScript" moves <script> tags to the end of the document.
Speed Optimizer by SiteGround adds a plain defer under "Defer Render-blocking JavaScript".
Rocket Loader by Cloudflare uses the same type attribute trick, but it puts scripts back in play after the page renders, not after an interaction. So Lighthouse does run and measure them.

All four can cause other trouble, script execution order for instance. But they do not artificially inflate the Lighthouse score.

When delaying is the right call {#when-its-fine}

To be fair: delaying code until a user interacts is sometimes exactly the right solution. The difference is whether you delay one specific component or everything.

The textbook case is the facade pattern. Instead of an embedded YouTube video you show a preview image with a play button, and load the real player on click. The same approach works for chat widgets, maps and comments. I write more about this in my pieces on third-party scripts and lazy loading over on my Czech blog.

The clearest tell is how Lighthouse treats the two techniques. For the facade pattern it has a dedicated audit recommending it. For blanket delaying of all JavaScript it has nothing at all.

How to spot the bad kind on your site {#how-to-spot}

These plugins leave fairly obvious traces in your HTML. Most often they rewrite the type attribute on a <script> tag to a value the browser does not understand, and hide the original script URL in a custom attribute.

What to look for in the page source:

type="text/rocketlazyloadscript" and data-rocket-src – WP Rocket
type="litespeed/javascript" – LiteSpeed Cache
type="pmdelayedscript" – Perfmatters
type="javascript/blocked" – WP Meteor
type="text/plain" with a data-src attribute – WP-Optimize

If you would rather not read code, load the page with the Network panel open and do not move your mouse. Then move it. If a batch of JavaScript requests fires at that exact moment, you have your answer.

And always finish by looking at real-user data. A greener lab score with no improvement in user data is not a win.

One checkbox cannot replace engineering work {#conclusion}

Deciding what loads when, and in what order, is engineering work that requires knowing the specific site.

One checkbox that delays all JavaScript does not do that work.

What it looks like when a whole industry heads in this direction is what we describe in Fake fast websites: how Lighthouse scores get hacked.

You will also find our investigation of the Website Speedy plugin there. After switching it off we watched the score drop from 95 to 60 points, without a single measurable change in user-perceived speed.

Deferring all JavaScript until interaction is not an optimisation. It's a Lighthouse hack

Martin Michálek — Thu, 27 Aug 2026 15:14:51 +0000

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?

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