How to measure website speed, properly

The most common mistake with site speed is looking at a single score. This piece covers what each tool measures and which lines in the report you should actually read.

Lab data and field data

There are two kinds of measurement, and confusing them leads to wrong conclusions.

Lab data is the page measured in a simulated, controlled environment. It is repeatable, which makes it useful during development. The Lighthouse score is lab data.

Field data comes from the browsers of people who actually visit your site. This is the data Google takes into account for ranking.

The two can diverge: a lab score of 95 can coexist with poor field results. The usual reason is that real users are on slower devices and connections.

Field data is also a 28-day rolling average. The fix you made today will not show up in the report immediately; it takes weeks. Not knowing about that lag is the most common source of "we fixed it but nothing changed."

Which tool for what

PageSpeed Insights. The starting point. It shows field and lab data side by side. Free, no setup.

Lighthouse in Chrome DevTools. For use during development, to measure locally as you make changes.

The DevTools Performance panel. It gives no score, but this is where the real diagnosis happens. It shows exactly which script occupied the main thread and for how long.

The Core Web Vitals report in Search Console. Shows the field status of the whole site, grouped by page type rather than individual URL. This is the report to actually manage.

WebPageTest. Lets you measure from different countries, devices, and connection speeds. Valuable if you get visitors from abroad.

The lines that matter

Not the score itself, but the three metrics underneath it.

LCP. When the largest piece of content appears. The report also tells you which element the LCP is, usually the hero image or the main heading.

INP. How quickly the page responds to interaction. When it is bad, the cause is almost always JavaScript occupying the main thread.

CLS. Layout shift. When it is bad, the cause is almost always an image without dimensions, a late-loading font, or a banner that pushes itself in afterwards.

Alongside those three there is TTFB: how long the server takes to send the first byte. If it is high, the problem is not in the front end but in the server or hosting, and compressing images will not fix it.

Common measurement mistakes

Measuring one page and generalising. The home page may be fast while product pages are slow. Measure each page type separately.

Measuring only on desktop. Most visitors are on mobile. The mobile score is always lower, and it is the one that matters.

Trusting a single run. Lab measurements vary run to run. Measure three times and take the median.

Measuring a cached page. There is a large difference between a first visit and a repeat visit, and the first visit is what counts.

Measuring in a browser with extensions. Extensions distort the measurement. Run Lighthouse in an incognito window.

What to do once you have measured

The priority order is usually this:

1. Serve images at the right size and in a modern format.
2. Remove unused JavaScript.
3. Review third-party scripts and ask whether each is genuinely needed.
4. Self-host fonts and declare their metrics.
5. Consider pre-rendering the remaining content and serving it statically.

The first two account for most of the improvement on most sites.

The third deserves particular attention: chat widgets, heatmaps, multiple ad tags, and social embeds together can outweigh the page's own code. Turning each one off and measuring shows exactly what each costs you.

Build measurement into a routine

A one-off measurement gives you a snapshot; a routine gives you a curve. Without the curve it is hard to tell whether a change helped.

A practical, free routine looks like this:

• Weekly, check the Core Web Vitals report in Search Console. If a page group turns red, you see it early.
• After every release, measure your three most important page types with PageSpeed Insights: home, a listing page, and a detail page.
• Write the results down. Date, page, three metrics. A three-month table shows at a glance which change did what.

The routine takes about half an hour a month and catches speed problems before they turn into customer complaints.

When to stop

Past a certain point the returns diminish. If all three metrics are in the good band and the page opens quickly on a real phone, the work is done.

Time spent pushing a score from 98 to 100 returns less than a content page written in the same time. The measure is user experience, not the table.

---

We can identify exactly where your site is losing time and produce a prioritised fix list. Our approach is on the web design and development page, and the technical side is covered in the architecture behind a fast website.