Loading speed

Page speed: the lab score, and what your visitors actually get

Two numbers describe how fast your website is, and they often disagree. One comes from a test we run in a controlled browser. The other is what Google recorded from people who really visited you.

Good Needs improvement Poor Google's published boundaries, measured at the 75th percentile of real visits.

What a slow site actually costs you

A slow website does not break. It loads, eventually, and nothing in your inbox tells you who gave up while it was loading. That is what makes it expensive: the loss is invisible from the inside, because your own browser has the site cached and your own connection is the one it was built on.

Two of the things the audit measures sit at opposite ends of that problem. Server response time is how long your host takes to send the first bytes of the page: anything over two seconds is flagged, and over five seconds is treated as critical. Page weight is how much has to arrive before the page is usable: over 1 MB is flagged, over 2 MB is critical, because a phone on a weak connection pays for every kilobyte in waiting.

A lab score is one run, on one machine

When you run PageSpeed Insights or Lighthouse you get a lab result: a single page load, in a headless Chrome, on a simulated network profile, on whatever machine happened to run it. Our audit runs Lighthouse too, across performance, SEO, best practices and accessibility, and reads the metrics behind the headline number rather than the number alone.

Lab data is good at one job: telling you which file is at fault. It names the script that blocked rendering and the stylesheet that could have been deferred. What it cannot tell you is what your customers experience, because it was never your customers who ran it. If the Lighthouse run fails or passes its 180-second limit, the report says so; a run that did not happen is never quietly scored as a pass.

Field data is what Google recorded from real visitors

The Chrome User Experience Report, usually shortened to CrUX, is Google's record of what real Chrome users measured on your site over the previous 28 days. It is the source of the Core Web Vitals figures Google itself uses for page experience. The audit reads the 75th percentile of that record, which means three-quarters of the visits Google logged were at least this fast, and a quarter were slower. We ask at origin level, so the figures describe the site as a whole rather than one page.

Google's thresholds, which the audit applies unchanged, are: Largest Contentful Paint good at 2,500 ms or under and poor above 4,000 ms; Interaction to Next Paint 200 ms and 500 ms; Cumulative Layout Shift 0.1 and 0.25; First Contentful Paint 1,800 ms and 3,000 ms; and Time to First Byte, which Google still marks experimental, 800 ms and 1,800 ms. Anything between the two figures is rated needs improvement. A metric rated poor for real visitors is recorded as a critical finding, and needs improvement as a warning.

No field data is not a failing grade

CrUX only holds data for sites with enough Chrome traffic to report anonymously. A single-location trade business or a small local firm often has none at all, and that is normal rather than damning.

When Google returns nothing, the report says exactly that: Google has no real-user data for this site, which usually means it does not yet get enough Chrome traffic to be measured. Not a zero, not a red mark, not padded out with an estimate. The same rule runs through the whole engine. A check that could not be completed is reported as unmeasured with the reason, and a category that could not be measured is dropped from the overall score rather than counted against you.

How a speed finding gets ranked

Severity carries a fixed price. A single critical finding, on its own, takes the performance score from 100 to 75; a warning costs less; and the deductions saturate, so a site with ten problems still ranks below a site with three instead of both bottoming out at zero. Performance is one of the most heavily weighted categories in the overall figure.

The fix list is then ordered by what each issue costs you rather than by its technical label, so the same fault on your booking page outranks it on your terms page. Lab findings and field findings are never merged: you can always see which came from our test run and which came from Google's record of your real visitors.

What the engine checks here

Each of these is a rule in the code, not a category heading.

• Real-user Core Web Vitals (CrUX)The 75th percentile of what Chrome users recorded over 28 days, checked against Google's own thresholds for LCP, INP, CLS, FCP and TTFB. Poor is raised as critical, needs improvement as a warning. If Google holds no data for your origin, that is reported as the reason, not as a failure.
• Server response timeHow long your host takes to answer. Over 0.5s is noted, over 2s is a warning, over 5s is critical, with the recommendation to get under two seconds through caching, a CDN or better hosting.
• Page weightThe size of the HTML your visitor has to download. Over 500 KB is noted, over 1 MB is flagged, over 2 MB is critical because slow loads on mobile drive visitors away before rendering finishes.
• Compression and caching headersWhether the server sends Gzip or Brotli (Content-Encoding), and whether Cache-Control, Expires, ETag or Last-Modified are set. Without a validator, returning visitors re-download the full page instead of getting a 304 Not Modified, so a repeat visit costs the same wait as the first.
• Render-blocking scripts and stylesheetsEvery script tag without async or defer is counted, along with stylesheets that block on all screens. These are the files that hold the first paint back, and they are named individually so a developer knows exactly which ones to change.
• Images: format, dimensions, lazy loadingJPEG, PNG and GIF images that could be WebP or AVIF; images with no width and height attributes, which is a direct cause of layout shift and therefore of a poor CLS score; and images below the fold with no loading="lazy".
• Lab metrics from LighthouseLargest Contentful Paint, First Contentful Paint, Total Blocking Time, Cumulative Layout Shift, Speed Index, time to interactive, server response time and render-blocking resources, captured from a real Lighthouse run in headless Chrome.
• Resource count, cookies and connectionsTotal requests on the page (over 100 is flagged), unminified CSS and JavaScript, whether static assets come from a CDN, cookie size over 4 KB, and whether the server closes the connection instead of keeping it alive.

Questions

My PageSpeed score is in the nineties. Why does your report say my visitors see it slow?

Because they are two different measurements. A PageSpeed or Lighthouse score is one load, in one browser, on one simulated connection. Google's field data is the 75th percentile of what real Chrome users experienced on your site over 28 days, on their phones and their networks. A good lab score and poor field data usually points at real-world conditions your test never reproduced, such as slow mobile connections, third-party scripts, or a server that is quick when idle and slow when busy.

Google has no real-user data for my site. Is that a problem?

No. It means your site does not yet get enough Chrome traffic for Google to report anonymised numbers, which is common for a small local business. The report states that plainly and shows the lab measurements instead. It is never converted into a low score, because we did not measure it.

If I fix all of this, will I rank higher on Google?

Nobody can honestly promise that, and we do not. Core Web Vitals are one of the signals Google describes under page experience, so poor field data is a known handicap and fixing it removes that handicap. What speed reliably changes is the visitor who would otherwise have gone back to the search results before your page appeared.

Sources

Public and checkable. Nothing here rests on a number we cannot point at.

• Google: defining the Core Web Vitals thresholds
• Chrome UX Report (CrUX): 28-day rolling field data
• Google Search Central: page experience and Core Web Vitals
• Lighthouse: how the lab performance score is calculated