Why Your PageSpeed Score Is 95 and Your Site Still Feels Slow

Your PageSpeed score is 95 and your site still feels slow because the score is not a measurement of your site. It is a measurement of one simulated page load, on an emulated mid-range phone, on a throttled connection, with nobody clicking anything. Real visitors arrive on different hardware, on different networks, with a warm or cold cache, and they click things. The number Google actually uses for ranking — and the number that matches what your visitors feel — is the field data further down the same report, not the big coloured circle at the top.

Two fixes follow from that. First, stop reading the score and start reading the Core Web Vitals Assessment panel above it. Second, check whether your optimisation plugin is configured in a way that improves the lab test specifically while leaving real-world responsiveness untouched — in WordPress this is the single most common cause of a green score on a slow-feeling site.

What the PageSpeed score actually measures

The performance score is a weighted average of five lab metrics collected during one simulated load. From Lighthouse 10 onward the weights are:

Notice what is missing: Interaction to Next Paint. INP is one of the three Core Web Vitals Google uses as a ranking signal, and it carries 0% of the performance score. Lighthouse cannot measure it, because Lighthouse never interacts with the page — there is no click, no tap, no form input. Google’s own documentation is explicit that TBT is “a reasonable proxy metric for INP for the lab” but “not a substitute for INP.”

So a 95 tells you the page paints quickly and doesn’t jump around while painting. It tells you nothing about whether the menu opens instantly, whether the variation selector on a product page responds, or whether the search box stalls for half a second per keystroke. Those are exactly the moments users describe as “slow.”

The test conditions are not your visitors’ conditions

The mobile Lighthouse run applies simulated throttling with fixed values: 150 ms round-trip latency, 1.6 Mbps download, 750 Kbps upload, and a 4× CPU slowdown multiplier. That is a deliberate, repeatable fiction. It is not the median of your audience, and the CPU multiplier in particular is applied to whatever machine ran the test, which is why the same URL scores differently from a laptop and from Google’s servers.

The result is a number that is excellent for comparing a page against itself before and after a change, and poor for predicting what any individual visitor experiences.

Lab data vs field data: which number to trust

PageSpeed Insights shows you two things that are easy to confuse. The top section — “Discover what your real users are experiencing” — is field data from the Chrome User Experience Report (CrUX). The bottom section, with the score, is lab data from a single Lighthouse run.

The field thresholds, measured at the 75th percentile of page loads, are fixed and public:

The 75th percentile matters more than it sounds. It means a quarter of your visits can be worse than the reported figure and you still “pass.” If your CrUX LCP reads 2.3 seconds, roughly one visit in four is slower than 2.3 seconds — and some of those are considerably slower. A green assessment is a floor, not a description of a typical visit. We covered how the three metrics are defined and weighted in Core Web Vitals in 2026: what Google measures and what it ignores.

Why your fix hasn’t shown up yet

CrUX reports a 28-day rolling average, refreshed daily. Deploy a fix today and tomorrow’s report contains 1 day of the new behaviour and 27 days of the old. The number moves immediately but slowly, and it takes a full 28 days before the window contains only post-fix data. If you shipped a change last week and the field data looks unchanged, that is the expected result, not a failed fix. Judge the fix on the lab metrics and your own RUM, then confirm in CrUX a month later.

The origin fallback trap

If the specific URL you tested doesn’t get enough Chrome traffic to form a statistically significant sample, PageSpeed Insights falls back to showing origin-level data — the aggregate across your whole site. People optimise a landing page, retest, see the field numbers barely move, and conclude the work did nothing. In fact they are looking at a site-wide average in which their one page is a rounding error. Check the label above the field section: it will say whether you are seeing data for the URL or for the origin.

If your field data says “poor” while your score says 95, the gap is diagnosable but not from the score. Send us the URL and we’ll run the field-versus-lab comparison and tell you which of the causes below is yours.

Why WordPress sites score well and feel slow

Several of the standard WordPress performance configurations are, by design or by accident, better at improving the test than improving the experience.

Delayed JavaScript inflates the score without helping users

“Delay JavaScript Execution” in WP Rocket, and the equivalent settings in LiteSpeed Cache, Perfmatters and FlyingPress, hold scripts back until the first user interaction — a scroll, a click, a tap. Lighthouse never interacts, so those scripts never execute during the test. Total Blocking Time, 30% of the score, collapses toward zero. LCP improves as well, because the main thread has less to do while painting.

For real visitors nothing was removed. The scripts still run; they all run at once, at the moment of the first interaction, which is precisely when the user is waiting for a response. The mechanism is well understood — Google’s Barry Pollard summarised it as “Great for Lighthouse scores! Often terrible for users” — and WP Rocket’s own 3.7 release notes reported a mobile score moving from 46 to 86 with the feature on, while their later INP write-up reported INP unchanged.

This is not an argument for switching it off blindly. Delaying a chat widget, a heatmap script or a social embed is legitimate and helps real users. Delaying everything, including the scripts that power the first thing a visitor clicks, converts a real problem into a hidden one. The test for whether your configuration is honest: after deploying, does your field INP improve, or only your score?

The test request isn’t the request your users make

LiteSpeed Cache’s Guest Mode serves a generic cached page on a visitor’s first request, then loads the correct personalised version over AJAX. Guest Optimization, which requires Guest Mode, goes further and applies maximum page and image optimisation to that default page — the documentation states it applies to “bots, certain user agents, and a user’s first visit to your site.”

That is a reasonable feature with a real trade-off, and it means the page a testing bot receives is not always the page a returning visitor, a logged-in customer, or a user with items in the cart receives. The same divergence appears in other forms:

• The tested URL is cached and warm; a visitor hitting an uncached variant (query string, logged-in state, non-cached WooCommerce page) gets the full PHP render.
• Third-party tags are injected via Google Tag Manager on consent, so they never load during a test run but load for every real visitor who accepts cookies.
• The home page scores 95 and is the only page anyone tests. Product, category, search and checkout pages are a different codepath entirely.

What the score cannot see at all

• Server response under load. A single test request hits an idle server. TTFB under concurrent traffic is a different number, and it is invisible in a one-off test.
• Logged-in and cart sessions. Cache is bypassed, admin-ajax.php and the Heartbeat API start firing, and WooCommerce fragments run on every page.
• Second and third page views. Lighthouse always tests a cold first load. Most of a real session is navigation between pages.
• Interaction cost. Filtering a product grid, opening a mega menu, typing in a search field. None of it happens during a test.

How to tell which problem you actually have

Work through this in order. It takes about twenty minutes and replaces guessing.

1. Read the field panel, not the score. Confirm whether it says “this URL” or “this origin.” Note which of LCP, INP and CLS are failing.
2. If INP is the failure: the problem is interaction, which the score does not measure. Look at delayed/deferred JavaScript settings, heavy event handlers, and third-party tags. TBT in the lab is a hint, not a diagnosis.
3. If LCP is the failure but lab LCP is fine: the tested page is not representative. Test a product page, a logged-in session, an uncached URL with a query string appended.
4. If CLS is the failure but lab CLS is fine: look for shifts caused by things that only happen with real users — consent banners, personalised blocks, lazily inserted ads, fonts swapping after a slow network fetch.
5. If field data is missing entirely: the page has too little Chrome traffic. Install real user monitoring and wait, or test with real devices rather than emulation.
6. Re-test with throttling disabled and on a real phone. The gap between simulated and real-device results tells you how much of your score is an artefact of the emulation.

If you want a single rule: the lab score is for comparing a page to itself, and the field data is for deciding whether anything is wrong. Use the first to verify a change and the second to choose what to change.

What to do with a green score and unhappy users

The pattern we see most often has the same shape. The score is 90+, field LCP passes, field INP sits in “needs improvement” or “poor,” and the site is running an optimisation plugin with aggressive JavaScript delay enabled. The fix is not more optimisation — it is narrowing the delay to the scripts that genuinely are not needed for the first interaction, and then accepting a lower score in exchange for a faster site.

That trade is uncomfortable to make if the score is the number being reported to a client or a manager. It is the right trade anyway: the score has no effect on ranking, and field Core Web Vitals do. If page builders are part of your stack, the baseline cost they add is worth understanding too — we measured it in the hidden cost of page builders. And if the field data shows LCP failing as well as INP, the underlying causes are usually the ones in why your WordPress site takes 8 seconds to load.

A speed audit that only reports the Lighthouse score is not an audit. If you have a green score, unhappy users and no idea which of the causes above applies to your site, book a speed audit — we test the pages your customers actually use, on real devices, with field data alongside the lab run, and tell you which number is lying to you.