Website testing — how to check a site so the result means something

Website testing usually ends the same way: somebody pastes an address into a free tool, gets a number, and either celebrates or rings the supplier to complain.

The trouble is that the number usually means nothing. It is one measurement, on a simulated device, at one arbitrary moment — and it measures something different from what Google judges your site on.

This is about how to test so the result means something. It is for you if you are signing a site off from a supplier, preparing one for launch, or checking whether the one you have works the way you think it does.

Why one measurement means nothing

Start with the thing no listicle of tools mentions, and which overturns how you read every result: the same test on the same site returns a different number every time.

The spread is not cosmetic. Our own measurement procedure — the one we use to validate every performance change on this site — assumes outright that a single Lighthouse run has a spread of about ten points. So 78 and 88 can describe exactly the same site in exactly the same state.

Three rules follow, which we apply to ourselves and which are worth taking into a conversation with a supplier:

• Five runs minimum, and take the median — not the mean. A mean can be dragged by one outlier; a median cannot.
• Same address, same device, same moment. A pre-deployment result from a desktop against a post-deployment result from a phone is not a comparison.
• Without before-and-after figures it is not a performance fix. Here, a change described as a speed-up with no measurement either side is not accepted as one.

The consequence is immediate. If somebody shows you one screenshot with a green score as proof a site is fast — or a red one as proof it is broken — that is not proof — it is one random measurement. Ask for five.

Lab measurement and field data — two different things

This is the distinction most site owners miss, and it decides whether your result relates to Google's assessment at all.

The lab measurement is Lighthouse, and it is the score out of a hundred in PageSpeed Insights. The page loads on a simulated device, over a simulated connection, once. It is a diagnostic tool: it tells you what specifically is slowing the page down and where to start. It is excellent at that, and that is what to use it for.

Field data is the Chrome UX Report — a dataset which, as Chrome's documentation puts it, "reflects how real-world Chrome users experience popular destinations on the web". That is not a simulation: it is your visitors, on their own phones, on their own signal. And it is on that data that the thresholds below are assessed — according to Google, at the 75th percentile of loads, separately for phone and desktop.

The seventy-fifth percentile means this: what counts is not how the three fastest visitors see the site, but how the slower quarter sees it. Your test on a good connection in the office is by definition on the faster side of that distribution.

And now the caveat that applies to most small company sites and almost never gets said. Only addresses meeting the eligibility criteria enter CrUX — the site must be publicly available and must, quoting the documentation, have "a sufficient number of visitors to create a statistically significant dataset". Google does not say how many.

In practice: if your site has little traffic, there is simply no field data. PageSpeed Insights shows the lab score and nothing else. That is not a fault and does not mean the site is bad — it means the only measurement you have is the diagnostic one, to be read as a hint rather than a verdict.

The three numbers Google measures, and their thresholds

Core Web Vitals are three metrics. The thresholds are specific and published, so there is no reason to guess (web.dev, as of 9 September 2026):

Two things worth remembering. INP replaced the earlier FID metric and has been stable since 2024 — if you see FID in someone's proposal or report, that document is out of date. And CLS is not about speed. It measures whether content jumps under your finger — you tap a button just as a banner loads and hit something else. A metric about irritation, not time, and most often the one that ruins the score of sites that "load fast, surely".

Each of the three usually breaks for a different reason, worth knowing before you start guessing:

• LCP is usually wrecked by one large image at the top of the page — the one meant to impress, in the wrong format and at a resolution prepared for a monitor, loading on a phone.
• INP is wrecked by an excess of scripts: plugins, marketing tools, chat widgets, consent banners. Each small alone; together they occupy the processor at exactly the moment somebody tries to tap.
• CLS is wrecked by content with no reserved space — an image, banner or ad that loads late and pushes everything below it down.

Two of the three causes are not the fault of "the site" but of things added after launch. That is the commonest reason a site slows down over time although nobody touched it.

If you want to see those three numbers for your own address, we have a page speed test that fetches them. Optimisation itself — what to do when the results are bad — we handle separately.

Check website performance before launch — four things

Most expensive mistakes are visible half an hour before publication, if you know where to look. Four things, in order of how costly the mistake is:

1. Whether the site can be indexed at all. The most expensive deployment error here is leaving the staging indexing block on production. The site works, looks good and is invisible to the search engine. Checking takes a minute: Search Console, URL inspection tool.

2. Whether the addresses match. If the new site replaces an old one, every old address has to lead to its counterpart. The only item here whose neglect costs permanently — lost positions do not come back on their own.

3. Whether forms arrive. Its own section below, because it is the only test no tool will run.

4. Whether the site works on a phone in real conditions. Also its own section, because "works on a phone" means one thing in a preview and another on a tram.

The full tick-list is in our pre-launch checklist. If instead you are checking a site that has run for years and want to know what is wrong with it, that is a different job — an audit, described separately, including when not to commission one.

Website usability testing on a phone — a preview is not a test

Here lies the commonest mistake, and it is technical rather than organisational: device mode in a desktop browser is not a phone. It changes the window width and the declared device type, but still uses your processor, your connection and your cache. A site that runs smoothly in that preview can be something else on a four-year-old phone with a weak signal.

This matters more than it seems, because Google indexes with the mobile version — indexing and ranking use the version fetched by the smartphone agent. So the large-screen version can look superb and have no bearing on it.

The test that actually tells you something looks like this and takes fifteen minutes:

• Take a real phone, preferably not yours. Most problems show on hardware nobody on the team uses — older, with less memory.
• Turn off wi-fi. Test on mobile data, away from the office.
• Walk the customer's path, not the homepage. Arrival, offer, contact, sending an enquiry. The homepage is almost always the most polished and tells you the least.
• One-handed. If sending an enquiry takes two hands and pinch-zooming, the form needs work regardless of what any score says.

The form — the one test no tool will run for you

No tool will check whether an enquiry from a customer reaches you. You have to send a real one and check three points, because each can fail separately and silently.

1. Whether the message reaches an inbox rather than spam. The commonest silent failure: the form works, shows a thank-you, and the message lands in a folder nobody opens. Check the inbox and the spam folder, and if enquiries go to a shared address, check that anybody actually reads it.

2. Whether the customer gets a confirmation. From the sender's side, no confirmation is indistinguishable from a failure. Some send the enquiry twice, some give up and write to somebody else. An automatic confirmation is cheap and removes that whole class of loss.

3. Whether the anti-spam measure is blocking real people. The hardest failure to notice, because at your end everything works — you test from your own office, from your own address. Mechanisms like reCAPTCHA or Turnstile can reject enquiries from people on a VPN, an older browser, or mobile internet on a shared address. No report will show it, because a blocked enquiry leaves no trace on your side. The test: ask somebody outside the company, on a phone, over mobile data.

Repeat this on a cycle rather than once after launch — forms break by themselves, on a hosting change, an expired key or a plugin update. That is what monitoring is for.

Signing off a site from a supplier — what to check first

This is where testing has its highest value and shortest shelf life. After sign-off and the final invoice, every correction becomes a new conversation; before sign-off it is part of the contract.

Six things, in this order, all to be checked by you rather than by the supplier:

• A form enquiry arrives and you have proof. Sent from outside, from someone else's phone, over mobile data. The three points from the section above.
• The site is visible to the search engine. The staging indexing block lifted — verified in Search Console, not taken on trust.
• Old addresses lead to new ones. If this replaces a previous site, check a dozen of the most important addresses by hand. Not "are there redirects", but whether specific old addresses open the right new pages.
• Five measurements, not one, with the median written down. That is your reference point for the future — without it, in a year you will not be able to prove anything slowed down.
• The customer path walked on a real phone, away from the office.
• The accounts are in your name. Domain, hosting, administrator account, licences. Not a test, but checked at the same moment and for the same reason: later it becomes a conversation rather than a setting. We cover it further under the editor layer.

One thing worth asking for outright, which costs nothing: a list of what the supplier deliberately did not do. Every build has such items — postponed, agreed verbally, cut from scope. Written down they are information. Unwritten they return in six months as a dispute about what was included.

Which three of the fifty findings matter

Every diagnostic tool produces a long list, and that is its greatest weakness: it implies everything on it needs doing. It does not.

Three questions that trim it to what matters:

Does a visitor see it? A note about image formats on the homepage affects everyone who arrives. A note about a server header affects nobody you know. Start with the first category.

Does it concern the phone? Since indexing runs on the mobile version and the slower quarter of visitors decides the assessment, a problem visible only on desktop sits lower than one visible only on a phone.

Does it repeat, or did it happen once? The five-measurement rule returns: a finding that appears in one run out of five is noise. One that appears in all five is a fault.

After that trimming, fifty findings come down to three to five worth commissioning — and that is the list you take to a supplier. Not the report.

When to check it yourself and when to commission it

You will get further alone than you expect, and it is worth using that before anyone issues an invoice. The four things above plus five measurement runs is a real diagnosis in two hours, with no technical knowledge required.

Commissioning makes sense in three situations: when the site is meant to bring enquiries and does not, and you do not know why; when you are signing off a large build and need somebody on your side; and when the measurement is bad and you do not know which cause is the expensive one — the tool lists fifty findings and will not say which three matter.

What commissioning will not solve: if the problem is in the content or the offer, no technical test will show it. A green site with no enquiries is not a performance problem — it is a question about measuring what people do on it, and it starts somewhere else, with the data rather than the tools.