Your speed score is not the number Google uses

Both get called “your site speed”, and they are produced in completely different ways.

• The score is a lab test. A single load of your page in a controlled setting: a simulated mid-range phone, its processor slowed to a quarter of normal speed, on a connection held to about 1.6 megabits a second. Google’s own documentation describes that connection as roughly the slowest quarter of 4G. The test does not even run on a slow phone. It loads your page at full speed and then calculates what the slow phone would have done.
• The vitals are field data. Measurements collected from real people visiting your site in Chrome over the previous 28 days: every phone, every laptop, good wifi and one bar of signal together. Google reports the 75th percentile, which is the figure three in four visits beat.
• Only one of them is an assessment. Google’s ranking systems use Core Web Vitals, and Core Web Vitals are the field measurements. The 0 to 100 score is not one of them. Its job is finding what is slow, and it is good at that job.

There are three vitals, each with a published line to stay under:

• Largest Contentful Paint: 2.5 seconds or less. How long until the main thing on the page is visible.
• Interaction to Next Paint: 200 milliseconds or less. How quickly the page reacts when someone taps it. A lab test cannot measure this one at all, because nobody taps anything during a lab test.
• Cumulative Layout Shift: 0.1 or less. How much the page jumps around while it loads.

Clear all three and the assessment passes. Miss one and it fails, whatever the circle says. Put your own report in below and move the score around.

The report is free and it is Google’s own: PageSpeed Insights. Our teardown runs the same audit and puts the two numbers in the right order for you. Either way, read it like this.

• Stay at the top. The first section reports what real users experienced. The circle is further down, under a heading about diagnosing issues, which is an accurate description of what it is for.
• Check which data you are looking at. When a single page has too few visits, the report falls back to figures for your whole site, and says so. A slow page can sit comfortably inside a fast site’s average.
• If it says there is no data, believe it. It means Google has too few real visits to say anything. That is the normal state of a small local site and it is not a fault. Field data also comes only from Chrome, and Chrome on an iPhone is not counted, so a customer base that leans towards Apple fills this in slowly. With no data there is no assessment to pass or fail, only the stress test.
• Look at phone and desktop separately. The report has a tab for each and they are assessed apart. For most local businesses the phone tab is where the visitors are, and its lab test is much the harsher of the two.

If your site is set up in Search Console, its Core Web Vitals report shows the same field data for every page at once, which is quicker than testing them one at a time.

In August we ran the standard lab test against one page of this site nine times from the same laptop. The page was byte-for-byte identical on every load. Its largest paint came back anywhere between 2.07 seconds and 5.24. An earlier batch of six had looked like a clean pattern. We built a confident diagnosis on it, shipped a fix, and were wrong. The spread was the laptop’s network connection. It had nothing to do with the site.

Google’s own servers are steadier, and still not steady. While writing this we put our homepage through Google’s test four times in under three minutes. On the phone it scored 71, 71, 84 and 76. On desktop, 96, 97, 85 and 97. Nothing changed between runs. And the two devices disagree by far more than the runs do: on the simulated phone the main element lands at about 4.4 seconds, and on desktop at about 1.1. Same page, same minute.

• Never act on one run. Take five and use the middle one. Lighthouse’s documentation puts the median of five at about twice as stable as a single run. A before-and-after claim resting on one test each side is two samples of noise.
• Test the exact address people land on. Many sites redirect from the bare address to the www version, and a test aimed at the wrong one pays for the redirect. We once lost an afternoon to three quarters of a second that turned out to be exactly that.
• Compare like with like. Phone to phone, desktop to desktop. A desktop score set against last month’s phone score is the easiest improvement anybody will ever sell you.

As for our own verdict: Google holds no field data on this site. Too few visits. By the logic of this article there is no assessment of us to pass or fail, only a stress test, and what the stress test says about our phone render time is true and ours to fix.

Suppose the vital that fails is the first one, Largest Contentful Paint. “The page is slow” is still not a diagnosis, because that figure is the sum of four phases that go wrong for unrelated reasons.

• Waiting on the server. The time before anything comes back at all. This is hosting, caching and redirects, and nothing done to the page itself recovers it.
• Finding the main image. A browser can only fetch what it knows about. An image that is lazy-loaded, set as a background in the stylesheet, or inserted by a script is discovered late, however small the file is.
• Downloading it. The file is heavier than the space it fills needs it to be.
• Getting it on screen. Everything has arrived and something is still in the way: code that blocks drawing, or content that JavaScript has to build before it exists. When the main element is text there is no image to find or download, so nearly all of the time lands here. That is the shape of every page we have measured on this site.

The reason to separate them is that every fix belongs to one phase. Image compression, the one everybody has heard of, reaches exactly one of the four. If your time is going to the server, or to getting the page drawn, you can compress every image you own and move nothing. Google’s rule of thumb for a healthy page is about 40% of the time on the server, about 40% on the download, and under 10% on each of the other two.

Speed work is real work and it is sometimes the right call. These are the cases where it is not.

• Your field data already passes. Then you are finished. The assessment has three bands and you are in the top one. There is no fourth band for a perfect score.
• Your problem is relevance. Google’s documentation is plain that it tries to show the most relevant result even when that page’s experience is poor. Speed can separate two pages that answer the question equally well. It cannot make a page the answer.
• Nobody is visiting yet. No field data means too few visits, and at that point the constraint is the visits. A faster page is still better for the people who do arrive, especially when you are paying for each one, but that is a question about what your page does with a click. It is not a question about ranking.
• The promise is a score. “We will get you to 90” is an undertaking about the stress test, and there are ways to raise that number which no visitor would ever notice. Ask instead which of the three vitals will move, measured on real visitors, and by when. Then add four weeks, because that is how long the window takes to turn over.

None of this says speed does not matter. A page that takes four seconds to show anything loses people before they have read a word, and that is worth fixing for its own sake. It says you should know which of the two numbers you are being sold.