Measuring Speed the Way Google Does

Why your test result is not the number

Run a speed test and you get a score. It is a real measurement of a real load, performed once, from a particular place, on a simulated device.

It is not what Google is looking at.

The measurements that matter are collected from actual visitors using Chrome, aggregated over a rolling period, and reported as the experience of the slower quarter of them.

That difference explains most of the confusion in this area, including the common situation where a site scores well in a test and is reported as needing improvement.

The three measurements

• Loading: how long until the largest thing in the visible area has appeared.
• Interactivity: how long the page takes to respond the first time somebody taps or clicks.
• Stability: how much the layout moves around while loading.

Together these are Core Web Vitals, announced last May and now the framework Google uses to describe page experience.

Each has a threshold for good and a threshold for poor, and a page is assessed on where the slower quarter of its visitors fall.

What the thresholds are, roughly

Loading is considered good at two and a half seconds or less, and poor beyond four.

Interactivity is good at one hundred milliseconds or less, and poor beyond three hundred.

Stability is measured as a score rather than a time, with about a tenth considered good and a quarter considered poor.

Most small business sites pass the second comfortably, because they run little code, and fail the first, because of images. The third catches sites with adverts, banners, or embedded content.

Field data and lab data

The distinction that resolves most arguments about which tool is right.

Lab data is a test you run: repeatable, immediate, and useful for diagnosis, because it tells you exactly which file caused what.

Field data is gathered from real visitors: accurate about experience, and slow, because it reflects a rolling twenty-eight days and therefore lags any change you make by roughly a month.

Both are correct and they answer different questions. Use field data to decide whether you have a problem, and lab data to find out what is causing it.

The mistake is using lab data to conclude you are fine, since a test from a fast connection describes almost nobody.

Where to read the real numbers

The Core Web Vitals report in your search console is the primary source, and it is free.

It groups your pages by whether they are good, need improvement, or are poor, separately for mobile and desktop, and it groups similar pages together so you are not reading them one at a time.

Page-level tools will also show field data for an individual address where enough visitors have been recorded.

Sites with little traffic often have no field data at all, in which case lab testing is what you have, and it should be read as an indication rather than a verdict.

The seventy-fifth percentile

Worth understanding properly, because it changes what counts as success.

The figure reported is not the average and not the best. It is the point below which three quarters of visits fall, meaning your site is judged on the experience of the slower quarter.

This is deliberate and it is the right way round. An average lets a majority on fast connections conceal a substantial minority having a bad time.

Practically, it means improvements that help everybody slightly may not move the number, while fixing whatever ruins the experience for the slowest quarter will.

A worked example

A regional retailer scored well in one-off testing and was reported as needing improvement for most of their pages on mobile.

The apparent contradiction was straightforward. Their testing was being run from an office on a fast connection, and their customers were largely on phones across a wide area.

The report showed loading was the failing measurement, on product pages specifically.

Lab testing those pages found the cause in a few minutes: full-resolution product photographs, and a gallery loading every image before showing the first.

They resized the images and loaded the gallery on demand.

The lab score barely moved, because it had already been good. The field report crossed into good about five weeks later, which is the lag rather than a slow fix.

Expect the lag

The most common reason people conclude a fix did not work.

Because field data covers a rolling twenty-eight days, a change made today is diluted by four weeks of history and does not show fully for about a month.

The correct sequence is to make the change, confirm in lab testing that it did what you intended, and then wait rather than making further changes.

Businesses that keep adjusting weekly because the report has not moved end up with several simultaneous changes and no idea which helped.

What this is for

Google has said these measurements will become part of how pages are ranked, with the change announced for this year.

It is worth being calm about that. The stated position has consistently been that relevance and content quality remain the dominant factors, and that this acts as a differentiator between pages that are otherwise comparable.

Nobody outranks a better answer by being faster. A faster page beats a comparable page.

The stronger argument for doing this work is the one that applies regardless: the slower quarter of your visitors are the ones leaving, and they were leaving before any of this was measured.

The counter-case

Chasing the numbers themselves is a recognised failure mode.

It is possible to improve a score without improving anything a visitor experiences, and some techniques do exactly that.

A perfect score on a page nobody wants to read is worth nothing, and time spent moving from good to slightly better is time not spent on the content, the photographs, or the enquiries.

The sensible target is reaching good, on mobile, on the pages that matter, and then stopping. This is a threshold to clear rather than a score to maximise.

What to do this month

1. Open the Core Web Vitals report in your search console.
2. Look at mobile first, and at the poor group.
3. Identify which of the three is failing.
4. Lab test one affected page to find the cause.
5. Fix it, and confirm in lab testing.
6. Wait a month before judging the field report.
7. Stop at good rather than chasing perfect.

Step six is the discipline that makes the rest of it legible.

Why the tools disagree is covered in Google named the numbers it cares about.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.