A perfect PageSpeed score versus real speed: how the metric is gamed and why the site still loses customers

A green circle with the number 100 in Google PageSpeed Insights is one of the most wanted numbers in web development. A business owner reads it as proof of technical quality: if Google is satisfied, the site is fast and conversions will follow.

Freelancers exploit this assumption. For a few hundred euros and a couple of days, they promise to move any heavy online store running on a heavy CMS such as WordPress or Magento into the green zone.

The client receives a report with a screenshot showing a score of 95–100, pays the invoice, and a month later discovers two facts:

1. Sales did not increase, and the mobile bounce rate in analytics remained at 40–50%.
2. Positions in Google Search did not improve and began to slowly decline.

Below: how the synthetic test is gamed, what Core Web Vitals actually measure, and why real speed is set by architecture rather than by patches.

Anatomy of deception: how 100 points in PageSpeed are faked

Google PageSpeed Insights runs the Lighthouse tool under the hood. It opens the page in a virtual Chromium browser, emulates a mobile device on an average processor, and measures key loading timings.

Because the check is automated, it can be fooled. Three methods are common.

Method 1. Cloaking by Googlebot User-Agent and IP addresses

A rule is added to the server configuration file. If the request comes from a browser with a Lighthouse User-Agent header or from Google IP ranges, the server returns a specially prepared lightweight HTML page.

This version has heavy scripts, video, third-party widgets, chats, and some images removed. The bot receives an almost empty page in 200 milliseconds and gives 100 points. A buyer visiting from a standard smartphone receives the unoptimized page with all original assets.

Method 2. Artificial freezing of scripts via timers

The main obstacle to synthetic scores is the TBT (Total Blocking Time) metric, which measures how long JavaScript blocks the browser’s main thread during startup.

To reduce TBT, the developer wraps heavy external resources, such as analytics, social media pixels, and live-chat widgets, in a delayed launch:

// The bot completes the measurement before scripts start
window.addEventListener('load', function() {
    setTimeout(function() {
        loadHeavyAnalyticsAndChat();
    }, 5000); // 5 seconds delay
});

The Lighthouse bot measures the page for the first 3–4 seconds. It sees an idle main thread, records ideal metrics, and closes the session.

A real visitor enters the site, sees the first screen, and tries to tap a menu on the fourth second. At exactly this moment, the timer triggers the initialization of multiple scripts. The browser freezes for 2–3 seconds, the interface stops responding, the user assumes the site is broken, and they close the tab.

Method 3. Loading critical resources on the first interaction

A more sophisticated timer variant prevents analytics and interface scripts from initializing until the user scrolls (scroll) or touches the screen (touchstart).

Since the PageSpeed robot performs no user actions during the test, it sees a clean site with no third-party code. When a real user touches the screen, the mobile processor is hit by parsing and compiling hundreds of kilobytes of JavaScript.

Lab data versus field data: what Google actually ranks on

Google evaluates site speed using two different data sources.

Data type	Source	What it measures	Can it be faked?
Lab Data	A single Lighthouse run in a sterile environment	Synthetic timings of a specific page under ideal conditions	Yes, easily faked by cloaking and script delays
Field Data (CrUX)	Real user sessions in the Google Chrome browser over the last 28 days	The actual experience on different smartphones and networks (3G/4G/Wi-Fi)	No

For organic search ranking, Google uses field data exclusively from the Chrome User Experience Report (CrUX). If a page has 100 points in the lab test, but 70% of real users in CrUX have poor metrics, the search algorithm considers the site slow and lowers its mobile ranking.

If search algorithms detect different content served to the bot and the user through cloaking, the site risks a direct penalty for search spam.

The physics of Core Web Vitals: three metrics that define conversion

Google standardizes user experience quality through Core Web Vitals. These are physically measurable perception delays.

                  TIMELINE OF LOADING AND INTERACTIVITY
0 ms           800 ms                  2 200 ms                   3 500 ms
  |--------------|------------------------|--------------------------|
  |     TTFB     |          FCP           |           LCP            |
Server        First pixel             Main content             Interface ready
response      on screen               rendered                 for input
                                      (target: < 2.5 s)        (INP: < 200 ms)

LCP (Largest Contentful Paint)

• Target: Under 2.5 seconds.
• What it measures: The moment the user sees the largest content element on the first screen, such as a main banner, H1 heading, or product image.
• Why it degrades: Slow server response (TTFB > 800 ms), unoptimized 3–5 MB images, blocking fonts and styles without asynchronous loading.

INP (Interaction to Next Paint)

• Target: Under 200 milliseconds.
• What it measures: The time from a physical click or tap on the screen to the visual update of the browser frame.
• Why it degrades: Overloaded JavaScript. If the main thread is processing third-party pixels or a heavy filtering script, a user’s tap on the checkout button is queued. The user taps again, the interface lags, and the session is abandoned.

CLS (Cumulative Layout Shift)

• Target: Index below 0.1.
• What it measures: Unintentional content shifts during reading or interaction.
• Why it degrades: Banners and images without exact width and height proportions, asynchronous cookie banners, or dynamically inserted ad blocks. A user attempts to tap a link, the page jumps down, and they tap an unrelated element instead.

Why classic monoliths hit an architectural ceiling

Commercial sites running on monolithic content management systems encounter structural limits when optimizing for speed.

1. The plugin layer cake effect: To add a slider, gallery, CRM integration, chat, and cart, administrators install independent plugins. Each plugin connects its own libraries, CSS styles, and JavaScript. This creates a cascade of 60–80 HTTP requests on a single page.

2. Heavy TTFB on the server side: At each visit, a monolithic CMS executes dozens of SQL queries, initializes the backend core, and assembles the page dynamically. Without advanced multi-level caching configured on the server, the time to first byte exceeds 1.5–2.5 seconds before the browser begins rendering.

3. Caching plugins only save static pages: Caching plugins create static HTML for unauthorized visitors. When a user logs in, adds an item to the cart, or places an order, the cache is bypassed. The system slows down exactly at the critical moment of completing the transaction.

How to check a site for fake scores in Chrome DevTools

Site owners can check the real performance directly in the Google Chrome browser.

[CHECKLIST FOR VERIFYING REAL SPEED]
1. Open the site in Incognito mode (Ctrl+Shift+N)
2. Press F12 (DevTools) -> go to the "Network" tab
3. Enable throttling: "Fast 4G" or "Slow 4G" instead of "No throttling"
4. Perform a hard reload (Ctrl+Shift+R)
5. Evaluate:
   - Total transferred data (Transferred): target < 1.5–2 MB
   - Number of requests: target < 50–60
   - Time to appearance of the first content without touching the screen

Signs of deceptive optimization

• The site comes alive only after mouse movement: if loading stops in the status bar, but the first scroll triggers a batch of 30 new requests to analytics and chat scripts, the site relies on a delayed loading trick.
• PageSpeed score is 98, but the Field Data section is missing or colored red.
• Buttons cannot be clicked in the first 2 seconds after appearance: the page is visually rendered, but clicking the menu triggers with a noticeable pause, indicating high INP.

The engineering approach: speed as an architectural property

Speed is a fundamental property of the system architecture, not an isolated optimization step.

Systems built on Next.js 15 (App Router, React Server Components), TypeScript, headless CMS architecture, and Edge infrastructure:

Parameter	Legacy approach (Monolith + Plugins)	Headless architecture (Next.js 15)
Page generation	Heavy backend compilation and SQL queries on every click	Static generation (SSG/ISR) and Server Components. HTML is served in 30–60 ms
Client JavaScript	2–5 MB of monolithic code blocking the browser	Zero client JS for content blocks; hydration only for interactive components
Image optimization	Manual compression or heavy server-side libraries	Native next/image component: automatic conversion to modern formats, precise sizing, zero layout shift (CLS = 0)
Third-party scripts	Dumped into <head> and block page loading	Isolated delayed loading with lazyOnload strategy without delaying interactivity
Stability under load	Crashes during traffic surges	Withstands thousands of concurrent users through Edge/CDN caching

With that architecture the Core Web Vitals pass without tricks: the page is as fast on a phone over 3G as it is in the Google test.