LiteSpeed ​​and Google PageSpeed ​​Insights Cloaking: How to Trick Your Tests into Thinking Your Site Is Fast.

Take a WordPress site hosted on LiteSpeed ​​Web Server , install LiteSpeed ​​Cache (LSCache), and then run two seemingly equivalent tests on the Mobile version of Lighthouse, which is typically the most stringent.

The mobile profile in fact simulates a much less favorable environment than the classic office fiber: slow 4G connection, higher latency and an emulated Motorola Moto G Power (2022) , a medium-low range smartphone designed specifically to represent not particularly powerful hardware.

This makes sense because performance also depends on the device's ability to process HTML, CSS, and especially JavaScript. A site that appears instantaneous on a desktop can be significantly slower on a budget smartphone.

It is therefore a deliberately difficult test bench.

The first with Google PageSpeed ​​Insights.

Result:

• Performance: 100;
• First Contentful Paint: 1,1 seconds;
• Largest Contentful Paint: 1,1 seconds;
• Total Blocking Time: 0 milliseconds;
• Speed ​​Index: 1,1 seconds;
• CLS: 0.

A seemingly perfect site.

Then open the same page with Chrome, launch Lighthouse directly from the browser and get:

• Performance: 77;
• First Contentful Paint: 3 seconds;
• Largest Contentful Paint: 4,5 seconds;
• Total Blocking Time: 170 milliseconds;
• Speed ​​Index: 3 seconds;
• CLS: 0.

Of course, two Lighthouse runs may differ slightly. Hardware, CPU, Chrome version, throttling, and machine conditions can affect the results.

But when we go from 77 to 100, from an LCP of 4,5 seconds to 1,1 seconds and above all from 170 milliseconds of Total Blocking Time to zero, it is worth stopping looking at the green circle and starting looking at the code.

We did it.

We cloned the official repository litespeedtech/lscache_wp on GitHub and read the source of the current version at the time of writing, the 7.9.1All files, methods, and lines cited in this article refer to that version and anyone can verify them.

And in the LiteSpeed ​​Cache code the mechanism is much clearer than we expected.

LiteSpeed ​​Cache can recognize certain test requests and leave them on a variant of the page where JavaScript is aggressively delayed, while a real browser is switched to the normal version after the first visit.

If we want to use a simple word, this for us is a form of benchmark cloaking.

We are not talking about the normal JavaScript Delay

Let's make an important distinction right away.

Delaying JavaScript is not inherently bad.

WP Rocket, FlyingPress, Perfmatters, and many other performance tools do this.

Defer, delay, minification, Critical CSS, lazy loading, and reducing unused CSS are perfectly valid techniques and, when applied correctly to real users, can produce real improvements.

The problem here is different.

The problem arises when the software is able to understand who is measuring it and keep the tester in a different state than the one the user's browser would normally end up in.

It's the difference between:

“I optimize my website”

e:

“when the test bench arrives, I activate the configuration that gets the best rating.”

And the LiteSpeed ​​Cache code allows us to follow this path step by step.

Step One: LiteSpeed ​​keeps a list of testers

In the official LiteSpeed ​​Cache repository there is a file called data/gm_uas.txt.

This is the list of User-Agents used by the Guest Mode system.

In the file we explicitly find:

Lighthouse
GTmetrix
Google
Pingdom
bot
spider
PTST
HeadlessChrome

We are not inferring behavior from an obscure variable name.

Lighthouse is literally written in the list.

Like Google, GTmetrix, Pingdom, and HeadlessChrome. The match is a case-insensitive regular expression constructed by concatenating the entries with |: it is enough that one of these strings appears somewhere in the User-Agent. The entry Google, for example, intercepts both PageSpeed ​​Insights and Googlebot.

But next to that file there is a second one, which is almost always ignored in public discussion: data/gm_ips.txt.

This is the list of IP addresses to always treat as guests. The first lines are as follows:

66.102.0.0/20
66.249.64.0/19
74.125.0.0/16
142.250.0.0/15
172.255.48.128/27
172.255.61.32/28
208.70.247.157

followed by about forty individual IPs belonging to cloud datacenters.

The first four blocks are Google range: 66.249.64.0/19 This is the historical range of Googlebot, the others are generic Google infrastructure, which is also the one from which the PageSpeed ​​Insights tests start. The two blocks 172.255.x I'm GTmetrix.

This means one thing: even if a tester changes their user agent, they'll still be recognized by their originating address. The recognition is twofold.

Since 7.7 the testers list updates itself, and the administrator can no longer modify it.

Up to version 7.6, the two lists were configurable from the panel, in the General → Tuning tab , with the “Guest Mode User Agents” and “Guest Mode IPs” options.

With version 7.7 everything has changed, and the official changelog says it in one line:

* **Cloud** Guest Mode IP/UA lists now sync automatically from the QUIC.cloud API.

In the source the mechanism is in src/guest.cls.php: a daily cron (litespeed_task_guest_sync) download from https://wpapi.quic.cloud/gm_ips e https://wpapi.quic.cloud/gm_uas the updated lists and save them in wp-content/litespeed/cloud/gm_ips.txt e gm_uas.txt.

The method that loads the lists, _load_gm_list(), has an explicit priority:

// Try cloud synced file first, then fallback to plugin data file
$files = [
    LSCWP_CONTENT_FOLDER . '/litespeed/cloud/' . $filename,
    dirname( __DIR__ ) . '/data/' . $filename,
];

The cloud-synced file wins over the plugin file.

And the update routine in src/data.upgrade.func.php does the rest:

Debug2::debug( '[Data] v7.7 upgrade: dropping guest_ips/guest_uas options' );
Conf::delete_option( 'conf.guest_ips' );
Conf::delete_option( 'conf.guest_uas' );

The two options are deleted from the database upon upgrade and are marked as deprecated in the code , to be removed after version 9.

The practical result is that today the list of who is kept in Guest Mode is no longer decided by the site administrator: it's decided by QUIC.cloud, the company that develops the plugin, and can update it at any time on all installations without releasing a new version. If a new test service comes along tomorrow, just add a line on the server side.

Second step: The code compares User-Agent and IP

In the file lib/guest.cls.php we find the method always_guest().

The file is intentionally light and is loaded by guest.vary.php without starting WordPress: the comment at the top of the file itself says so.

The operation is simple.

Loads the list of User Agents, builds a regular expression, and compares it with:

$_SERVER['HTTP_USER_AGENT']

If it finds a match it returns true.

Immediately afterwards, the IP address is also checked, which since 7.7 also supports CIDR notation (which is why entire Google ranges appear in the list).

In simplified terms the code does this:

if (user_agent_presente_nella_lista()) {
    return true;
}

if (ip_presente_nella_lista()) {
    return true;
}

return false;

This is a simplified representation, but the logic of the original source is exactly this.

So LiteSpeed ​​explicitly has a feature that answers the question:

“Does this request belong to one of the clients I want to always keep in Guest Mode?”

Third step: who enters Guest Mode, and who doesn't exit it

And this is where things get much more interesting, because the mechanism has two distinct gates.

The first gate is in the plugin, inside WordPress, in the method _maybe_guest_mode() di src/vary.cls.php. And here's the surprise: this method It doesn't look at User-Agent or IP at all. Just look at one thing:

// If vary is set, then not a guest.
if ( self::has_vary() ) {
    return;
}

If the request does not bring the cookie _lscache_vary, is Guest. Period. Anyone arriving without that cookie, human or machine, receives the Guest variant, and if Guest Optimization is active, the constant is defined LITESPEED_GUEST_OPTM which we will see shortly.

The second gate is in guest.vary.php, and it is what decides who receives the cookie and therefore who exits Guest Mode.

LiteSpeed ​​actually inserts a small script at the bottom of the Guest page (assets/js/guest.js) which, if the cookie is not present, makes a POST request to guest.vary.php. In the method update_guest_vary() we find the decisive passage:

if ( $this->always_guest() ) {
    echo '[]';
    exit;
}

Translated into Italian:

If you are one of the clients that LiteSpeed ​​recognizes as “always guest,” I don't give you the cookie and I don't tell you to reload the normal page.

The process ends.

For other visitors, LiteSpeed ​​sets the vary cookie (valid for two days) and returns a response that orders the reload:

setcookie( self::$_vary_name, $vary, $expire, '/', false, $is_ssl, true );
echo json_encode( [ 'reload' => 'yes' ] );

And the browser-side script literally runs:

if (data.hasOwnProperty('reload') && data.reload == 'yes') {
    sessionStorage.setItem('litespeed_docref', document.referrer);
    sessionStorage.setItem('litespeed_reloaded', '1');
    window.location.reload(true);
}

The real browser then reloads the page and continues with the correct variant.

The tester recognized via User-Agent or IP, however, remains on the highly optimized Guest variant.

This difference is fundamental.

The hidden price for the real user: the page loads twice

Let's stop for a moment on that window.location.reload(true), because the official narrative of Guest Mode is “to make the first visit lightning fast.”

What actually happens to the first real visitor is this:

1. receives the Guest page from the cache;
2. renders it;
3. the script contacts guest.vary.php, which starts PHP (without WordPress) and sets the cookie;
4. the browser reload the entire page;
5. receives the normal variant, the one with the JavaScript configured by the administrator.

The "fastest first visit" is therefore a page that the user sees for a fraction of a second before being replaced by a second full load. The real cost of the first visit is the sum of the two.

That the reload is a known issue is demonstrated by a detail in the code: LiteSpeed ​​inserts in the<head> a second script, guest.docref.js, which after the reload overwrites document.referrer with the value saved before reloading:

Object.defineProperty(document, 'referrer', {
    get: function () {
        return litespeed_docref;
    },
});

This is necessary because otherwise Google Analytics and similar tools would see the site itself as the referrer for all visits, and organic traffic would disappear from their reports. They had to write a patch to fix a side effect of their own mechanism. The tester, who never reloads, sees none of this.

And this is where PageSpeed ​​Insights and Chrome go their separate ways.

Let's imagine PageSpeed ​​Insights.

The request comes from Google's infrastructure, therefore from an IP in the ranges of gm_ips.txt, with a User-Agent that contains Chrome-LighthouseIt doesn't have cookies, because each test starts from a clean profile.

First gate: no cookies, so Guest variant.

Second gate: the script calls guest.vary.php, always_guest() responds true, no cookies, no reloads.

The test is conducted entirely on the Guest variant.

Now let's get Chrome on our computer.

This is the browser with which we have already opened the site at least once. It therefore already has the cookie. _lscache_vary, or receives it on the first load and reload. From that moment, for the first gate, Chrome he is no longer a Guest, regardless of what the User-Agent declares: the cookie is the only thing the plugin checks on the WordPress side.

Lighthouse, launched by DevTools, therefore measures the normal variant, the one seen by anyone who has previously visited your site. That is, almost all of your users.

So we have two paths:

and the test done directly from Lighthouse on Chrome:

At this point, only the last piece is missing, and a question that arises spontaneously: what does Guest Optimization do to JavaScript?

Step Four: Guest Optimization forces JavaScript into Delay mode

Let's open src/optimize.cls.php.

The plugin first reads the normal JavaScript configuration set by the administrator.

Then you come across this control:

$this->cfg_js_defer = $this->conf(self::O_OPTM_JS_DEFER);
if (defined('LITESPEED_GUEST_OPTM')) {
    $this->cfg_js_defer = 2;
}

This line is particularly important.

When Guest Optimization is enabled, LiteSpeed ​​internally forces the JavaScript value to 2.

In the plugin code the value 2 represents the delayed mode.

So it's not just a normal defer.

This is the mode in which scripts are neutralized and loaded later.

And this override occurs even if the site's standard configuration provides for different behavior.

This isn't an academic hypothesis: this is exactly what the plugin's official presets do. In the files data/preset/advanced.data e data/preset/aggressive.data, the two “recommended” profiles for most sites, we find:

["guest",true]
["guest_optm",true]
["optm-js_defer",1]

Guest Mode enabled, Guest Optimization enabled, and JavaScript a 1, that is, simple defer, for everyone else.

The preset itself sets the divergence: the tester gets the delay (2), the real user gets the defer (1). An administrator who applies the “Advanced” preset with one click unknowingly has two different sites.

Only the “Extreme” preset sets 2 for everyone, and there, at least, the tester and the user see the same thing.

Beyond JavaScript: What Guest Optimization Really Forces

Looking for LITESPEED_GUEST_OPTM In the source, you'll find that JavaScript is just the most visible entry. When that constant is defined, the plugin forces regardless of administrator settings:

• minification and combination of CSS and JS (optimize.cls.php);
• asynchronous loading of CSS and UCSS, if the site is connected to QUIC.cloud;
• removal of Google Fonts (cfg_ggfonts_rm forced to true): the tester sees a page without external web fonts;
• HTML minification and DNS prefetch control;
• lazy loading of images and iframes, Viewport Images, WebP replacement, adding missing dimensions to images (media.cls.php);
• tag removal <noscript> (cfg_trim_noscript), that is, fallbacks that normally accompany lazy loading;
• responsive placeholder for images (placeholder.cls.php).

And especially skip security checks that the administrator would have at his disposal. In optimize.cls.php:

if (!defined('LITESPEED_GUEST_OPTM')) {
    if (!Control::is_cacheable()) {
        return $content;
    }
    // Check if hit URI excludes
    ...
}

The optimization “URI Excludes” are only applied when immense you are in Guest Optimization. The same applies to “Role Excludes” in core.cls.phpAnd for JavaScript, the normal “JS Deferred Excludes” list is ignored in favor of a separate list, “Guest Mode JS Excludes,” which defaults to empty.

In other words: everything the administrator has excluded because he knows it will break, is optimized for the tester anyway. The tester doesn't navigate, doesn't fill out forms, doesn't open menus: he'll never notice something is broken.

Step 5: The script tag stops being a script

Now let's see what actually happens to the markup.

A normal JavaScript file would be declared like this:

<script src="/wp-content/themes/theme/app.js"></script>

A browser that encounters this element recognizes src and may request the JavaScript file.

When LiteSpeed ​​uses delayed mode, the tag is transformed into this (the line is in optimize.cls.php):

<script data-optimized="1" type="litespeed/javascript" data-src="/wp-content/themes/theme/app.js"></script>

And here's the key point.

type="litespeed/javascript" It is not a normal JavaScript type recognized by the browser.

And most importantly the URL is no longer in the attribute src.

It has been moved to:

data-src="..."

For Chrome, that file is therefore not, at that moment, a JavaScript resource to download and execute.

The reference exists in the HTML, but the network request to that file does not start as it would with a normal script tag.

The same treatment is reserved for inline scripts, whose content remains in the tag with type="litespeed/javascript", and ai iframe: src becomes data-litespeed-src, so YouTube embeds, maps, and advertising aren't loaded until there's interaction.

There is also a lesser known detail. In optimize.cls.php, when the delay is active, the plugin modify the contents of JavaScript files themselves what is needed:

$con = str_replace('DOMContentLoaded', 'DOMContentLiteSpeedLoaded', $con);

Every script that waits DOMContentLoaded It's rewritten to wait for an event invented by LiteSpeed, which the loader will emit only after all the delayed scripts have loaded. It's no longer your JavaScript; it's your JavaScript with strings replaced.

This distinction is also important terminologically.

We are not saying that LiteSpeed ​​necessarily removes all references to JavaScript.

Let's say something technically more precise and even more significant: the JavaScript file is subtracted from the normal loading of the browser, or rather from its execution.

Step Six: When do those JavaScripts actually start?

Of course, you need a loader that can then turn those elements back into normal scripts.

The LiteSpeed ​​file is called js_delay.min.js, and the non-minified version assets/js/js_delay.js It can be read in a minute.

And here we find the final piece.

The loader logs user events:

window.litespeed_ui_events = window.litespeed_ui_events || ['mouseover', 'click', 'keydown', 'wheel', 'touchmove', 'touchstart', 'pointerup', 'pointerdown'];

When one of these interactions occurs, the delayed loading function is triggered.

The loader looks for the elements:

script[type="litespeed/javascript"]

and only then does it create normal elements <script>, transforming data-src back in src, loading them one at a time, in sequence.

The browser then downloads the JavaScript.

Before the interaction, no.

And then there's this line, which is commented out in the source:

// const litespeed_js_delay_timer = setTimeout( litespeed_load_delayed_js, 70 );

A temporal fallback existed, or at least was foreseen: after 70 milliseconds, the scripts would have started regardless, whether there was interaction or not. It has been disabled. Without interaction, the delayed JavaScript never starts. Not after 70 milliseconds, nor after 70 seconds. A user who opens the page and reads without touching anything has a page where the JavaScript has never been executed.

With a timer, a Lighthouse test lasting several seconds would have seen the scripts run and measured their cost. Without a timer, it doesn't see them.

And Lighthouse is not a user who moves the mouse

Now let's put all the pieces back together.

PageSpeed ​​Insights launches Lighthouse.

LiteSpeed ​​recognizes the request through its own UA/IP lists, which are now updated directly from QUIC.cloud.

It keeps her in the Guest variant, never delivering the cookie to her.

Guest Optimization forces JavaScript into Delay mode, even if the site preset says defer.

The normal ones src they become data-src.

Tags become type="litespeed/javascript".

Actual loading happens when a user interaction occurs, and only then.

But a Lighthouse test doesn’t use the page like a person moving the mouse, turning the wheel, touching the screen, or opening the menu.

The practical result is evident.

During the window in which performance is measured, JavaScript code is not executed.

And here's how you get there:

Total Blocking Time: 0 ms.

Not because the site's JavaScript has magically become free, but because that work isn't happening during testing.

How to verify it on your website in two minutes

You don't need to trust us. Just two requests are enough. curl from any server shell.

The first one simulates the tester: no cookies, User-Agent containing Lighthouse.

curl -s -A "Mozilla/5.0 (Linux; Android 11; moto g power (2022)) Chrome-Lighthouse" https://www.esempio.it/ \
  | grep -c 'type="litespeed/javascript"'

The second simulates a returning user: same URL, but with the vary cookie present (the value is not important, the plugin only checks that it exists).

curl -s -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/128.0.0.0" \
  -b "_lscache_vary=1" https://www.esempio.it/ \
  | grep -c 'type="litespeed/javascript"'

If the first command returns dozens of occurrences and the second zero, you've just observed the two variants with your own eyes. For comparison, the plugin itself exposes a documented parameter to force the non-Guest variant: ?litespeed_guest_off=1.

If you want an honest PageSpeed ​​number without touching your site, the only way is to disable Guest Optimization, or set everyone to the same level as the testers. In either case, your score will drop. That's the real number.

The test sees a page that the user will not use in the same way

This, for us, is the practical definition of the problem.

PageSpeed ​​Insights should answer the question:

“How does this page behave?”

But if the page is able to recognize PageSpeed ​​Insights and change its behavior, the test ends up answering a different question:

“How does this page behave when it knows it’s in PageSpeed ​​Insights?”

They are two completely different things.

And there is a corollary that concerns SEO in the strict sense. The voice Google in the UA list and the range 66.249.64.0/19 in the IP list they intercept Googlebot. Even the crawler that indexes the site, therefore, receives the Guest variant, with the JavaScript neutralized and the <noscript> removed. What exactly does Googlebot see rendering on a site whose JavaScript only runs at mouseover It's a question every client-side content site owner should ask themselves.

The Volkswagen parallel becomes almost embarrassing

Let's go back to Dieselgate for a moment. Do you remember it?

The Volkswagen control unit did not render the car non-existent during the test.

The engine was always there.

The components were always the same.

What changed was the behavior when the car recognized the test bench conditions.

During the homologation it activated a particularly favorable mode, clean engine, low emissions, an apparently non-polluting and environmentally friendly engine.

Off the test bench it behaved differently again and the test-rigging scandal broke out.

With LiteSpeed ​​Cache, the technological parallelism is obviously not literal, but the logical one is hard to ignore.

Here we have:

• a software that needs to be measured;
• a system that identifies meter characteristics, by User-Agent and by IP address;
• a list of meters updated centrally by the manufacturer;
• a special modality associated with qualified requests;
• different behavior in resource loading;
• a vastly better benchmark result.

The tester arrives and the engine changes mapping.

Only here the mapping is made of PHP, cookies, User-Agent, IP range, data-src and delayed JavaScript.

LiteSpeed ​​itself admits that the result can mask problems

What makes this story even more surprising is the official documentation.

LiteSpeed ​​explicitly states that Guest Optimization applies the highest level of optimization to the Guest page even when some features would normally be disabled.

It also says that qualifying requests include bots, certain user agents, and first-time visitors.

And he specifically mentions PageSpeed ​​Insights and GTmetrix , explaining that Guest Optimization can significantly improve page speed scores because these services receive a cached, highly optimized page.

Then comes the most significant part.

The documentation warns that Guest Optimization can mask real problems and suggests disabling it if you want to get accurate feedback from performance testing sites.

That's an extraordinary sentence.

Because it essentially amounts to saying: if you really want to know what problems the site has, turn off the feature that gives it the best rating.

The communications are obviously very calm and politically correct; they don't say "We're cheating on PageSpeed ​​tests to sell more," but that's actually what they do.

For the sake of completeness, it should be noted that Guest Mode and Guest Optimization are disabled in the fresh installation . They are activated by the "Advanced," "Aggressive," and "Extreme" presets—the exact profiles recommended for those who want "more speed" with a click—and by most configuration guides published by providers who sell LiteSpeed ​​hosting.

The real damage is psychological: the 100 interrupts the optimization and the bad luck!

And this is why we consider this choice particularly damaging.

The problem is not just technical.

It's cognitive.

A site that gets 77 generates questions.

Why does the Largest Contentful Paint take 4,5 seconds?

Why do we have 170 milliseconds of Total Blocking Time?

How much JavaScript are we loading?

Which plugin is blocking the main thread?

Can we delete some libraries?

Is the topic too heavy?

Do advertising scripts start too early?

Are the images sized correctly?

Is CSS too much?

A 77 pushes a serious developer to open DevTools and get to work.

A 100 instead means that the work is finished.

And this is where an overly favorable benchmark does the greatest damage.

The customer sees 100.

The agency sees 100.

The marketing manager sees 100.

Those who should authorize further hours of optimization ask themselves why they should spend money on a site that Google apparently deems perfect.

The real problem remains.

But nobody looks for it anymore.

And there's one fact that no preset can fix: the Core Web Vitals that Google uses for rankings don't come from Lighthouse, but from the Chrome User Experience Report , that is, from real users' browsers. The ones with the cookie. The ones on the normal variant. This is precisely why the 100 from PageSpeed ​​Insights and the red in the "Find out what your real users experience" section of the same page so often coexist on LiteSpeed ​​sites.

LiteSpeed ​​Web Server is not the problem

Another distinction must also be made.

LiteSpeed ​​Web Server is a different product from the LiteSpeed ​​Cache plugin.

LiteSpeed’s server-side caching can be extremely effective just like FastCGI Cache or Proxy Cache on NGINX or Varnish Cache if we are talking about pure Full Page Cache.

Serving ready-made HTML without having to fully launch WordPress, PHP, and the database is an excellent technique.

This is not what we are criticizing.

Likewise, we are not arguing that minification, UCSS, Critical CSS, lazy loading, defer, or delay JavaScript are bad techniques.

They are perfectly legitimate tools when the improvement is applied to the experience we actually want to provide to users.

What we contest is the use of a variant recognizable by the tester that allows the benchmark to observe significantly different conditions.

There is, however, a significant detail to take into consideration: when you want to take full advantage of the LiteSpeed ​​web server, you need to "communicate" with the web server to purge the server-side cache and at that point the LSCache plugin is no longer an optional feature, a discretionary choice of the user, but an obligation and the only possible choice. And here we are, even if we try to fulfill the intentions of LiteSpeed ​​(web server) by separating it from the LSCache plugin, let's always remember that the "combo" is wanted by the same commercial company that develops and SELLS both with systems capable of cheating the tests by making them appear to be better than other technologies, and unfortunately the inexperienced user believes it.

The proof is in the source, not in our opinions

What makes this analysis particularly difficult to dismiss as mere polemics is that all the key steps are visible in the official repository, version 7.9.1.

We have:

• a UA list with Lighthouse, Google, GTmetrix e HeadlessChrome (data/gm_uas.txt);
• an IP list with ranges from Google and GTmetrix (data/gm_ips.txt);
• since 7.7, a cron that downloads both lists from wpapi.quic.cloud with priority over the local file, and deletion of the corresponding options from the panel;
• a method always_guest() which compares User-Agent and IP addresses;
• a WordPress-side decision based solely on the absence of the cookie _lscache_vary;
• a branch in guest.vary.php which does not deliver the cookie to the testers and does not order the reload;
• a forced reload for everyone else, with a patch to document.referrer to avoid breaking Analytics;
• Guest Optimization that Strengthens cfg_js_defer = 2, removes Google Fonts and noscript, and ignores URI Excludes and Role Excludes;
• official presets that enable Guest Optimization while leaving JavaScript unattended 1 for users;
• rewritten scripts as type="litespeed/javascript", URLs moved from src a data-src, iframe in data-litespeed-src;
• the string DOMContentLoaded replaced inside JavaScript files;
• a loader that waits for events like click, mouseover, wheel, or touch before loading them, with the fallback timer commented out.

You don't need to imagine what the software does.

The software tells us.

Conclusions: PageSpeed ​​sees the test bench, the user sees the road

The problem with Guest Optimization isn't that LiteSpeed ​​knows how to optimize a page.

Actually.

The fact that it can minify, combine, defer JavaScript, produce Critical CSS, and reduce initial work shows that it has technically interesting tools.

The problem is another.

The system is designed to recognize certain test requests and keep them in a particularly favorable condition.

In that condition Guest Optimization forces the JavaScript delay.

Normal external scripts are transformed into elements that the browser does not load immediately.

Their URLs are parked in data-src.

Subsequent execution depends on an interaction-triggered loader, with no temporal fallback.

And during an automated audit that interaction simply doesn't happen.

The result is that PageSpeed ​​Insights judges a page on which the true cost of a significant portion of the JavaScript has not yet come into play.

The user's browser, however, must pay the price sooner or later. In fact, on the first visit, it pays twice.

That's why we can find ourselves with 100 on PageSpeed ​​Insights and 77 on Lighthouse running in Chrome.

And that's why that 100 shouldn't reassure us.

It should make us suspicious.

In Dieselgate the control unit recognized the test bench and changed the mapping.

Here, a plugin recognizes the tester's characteristics and changes the way a key part of the page is loaded.

The consequences are naturally not comparable on a legal, environmental or economic level.

But the principle of the benchmark being altered because the software knows it is being observed is surprisingly similar.

And the damage, in our sector, is insidious.

It's not just getting a questionable number.

It's convincing yourself that there's nothing left to optimize.

It's to stop searching for that heavy JavaScript.

It's leaving that LCP at four seconds.

It means not intervening on the theme, plugins and third parties.

It's showing the customer a 100 and calling it performance.

For us the rule should be much simpler.

A fast site shouldn't need to recognize who's testing it.

It should be fast according to Google PageSpeed ​​Insights.

It should be fast for Lighthouse.

But most importantly, it should be fast for a real person opening Chrome from their phone.

If the dyno and the road tell two different stories, we prefer to believe the road.

And all the hosting vendors who, despite knowing, remain silent, are complicit in behavior that in any other industry would have ended up on the front pages as fraud.