Measuring website speed: PageSpeed Insights, Lighthouse and real users

A client runs PageSpeed Insights at 10 am and gets 82. Their developer runs it at noon and gets 64. Nobody touched the site. Situations like this make owners distrust speed tools entirely, which is a shame, because the tools are useful once you know what each one actually measures. This guide shows how to measure website speed in a way you can trust: which data comes from a simulation, which comes from real visitors, how to run tests so results are comparable, and how to read the waterfall chart that explains where time goes.

Lab data and field data are different things

Every speed tool falls into one of two groups, and mixing them up causes most of the confusion.

Lab data: a controlled experiment

Lab tools load your page once, on a set device profile and network speed, and report what happened. Lighthouse is the best-known example; it runs inside Chrome DevTools and also powers the score in PageSpeed Insights. Lab data is repeatable enough for debugging, and it works on pages that have no traffic yet, such as a staging site.

Its weakness is that it represents one imaginary visitor. Your real customers use hundreds of different phones, networks and browser states.

Field data: what real visitors experienced

Field data, also called real-user monitoring, is collected from actual page views. PageSpeed Insights shows field data from the Chrome User Experience Report (CrUX), which aggregates anonymised measurements from opted-in Chrome users over the previous 28 days. It reports the 75th percentile, so the figure reflects a fairly slow visit rather than the best case.

Field data is what Google uses for Core Web Vitals assessments. The catch is that low-traffic pages may not have enough data to show, and changes take weeks to fully appear because of the rolling window.

How to read a PageSpeed Insights report

The report has two halves, and they answer different questions.

• Top section ("Discover what your real users are experiencing"): field data from CrUX. Check whether the Core Web Vitals assessment says passed or failed, and look at LCP, INP and CLS values. If this URL lacks data, it may fall back to data for the whole origin.
• Bottom section ("Diagnose performance issues"): a Lighthouse lab run with the 0–100 performance score, metric values and a list of opportunities and diagnostics.
• Mobile and Desktop tabs: always check mobile first; the lab test simulates a mid-range phone with a throttled connection.

When the two halves disagree, trust the field data for "how are we doing" and use the lab data for "what should we fix".

Running speed tests so the numbers mean something

A single test run tells you little. Follow a consistent routine instead.

1. Pick a fixed set of URLs. Home page, a key service or category page, a product or article page, and your contact or checkout page.
2. Run each test three to five times and use the median rather than the best or worst result.
3. Test in an incognito window when using Lighthouse in DevTools, so browser extensions do not add their own scripts and slow things down.
4. Keep settings identical: same device mode, same throttling, same tool. Do not compare a desktop score with a mobile one.
5. Record the date and what changed on the site, in a simple spreadsheet, so you can link improvements or regressions to specific edits.
6. Re-test after caches are warm. The first visit after clearing a server or CDN cache can be slower than normal.

Why speed scores vary between runs

Variation of several points is normal, and bigger swings usually have ordinary explanations:

• Server load differs from minute to minute, especially on shared hosting.
• Third-party scripts such as ads, chat widgets and tag managers load different content on each visit.
• A/B tests or rotating banners change what is on the page.
• Network routes between the testing machine and your server change.
• Your own computer is busy with other tabs when you run Lighthouse locally.

The performance score is weighted from several metrics, so a small change in one heavily weighted metric can move the score noticeably. Watch the underlying metric values, not just the coloured number.

Reading a waterfall chart

A score says that a page is slow. A waterfall shows why. Open Chrome DevTools, go to the Network tab, tick "Disable cache" and reload the page. Each row is one file, and the horizontal bar shows when it started and how long it took.

What to look for

• A long first bar for the HTML document: the server is slow to respond, pointing at hosting, database or missing page caching.
• A staircase of rows that start one after another: files are being discovered late, often because CSS or JavaScript loads other files in a chain.
• Very wide bars on images: images are too large in file size.
• Dozens of requests to other domains: third-party tools adding weight.
• A late start for the hero image: the browser only found it after running scripts or styles, which delays LCP.

Hovering over a bar shows its timing breakdown, including waiting time (the server’s share) and content download. The Performance panel in DevTools goes deeper still, showing main-thread work that causes slow interactions.

Setting up ongoing real-user measurement

Spot checks are fine for small sites, but anything that earns real revenue deserves continuous data. Google Search Console’s Core Web Vitals report groups your URLs by status using the same CrUX data. For more detail, developers can add Google’s open-source web-vitals JavaScript library to send LCP, INP and CLS values from every visit to GA4 or another analytics tool, letting you split results by page type, device or country.

Whatever you choose, check it on a schedule, such as monthly and after every major release, rather than only when someone complains.

Turning measurements into a fix list

Once you have a baseline, pick the slowest important page, open its waterfall and Lighthouse opportunities, and choose the two or three changes with the largest expected impact. Make those changes, wait for field data to catch up, and measure again using the same routine.

If the numbers point to hosting as the bottleneck, compare what a better plan offers on our VPS hosting page. For a second opinion on a confusing report, you can also ask one of our experts.

Frequently asked questions

Why does PageSpeed Insights say "no data" for real users?

The page does not have enough Chrome visits in the last 28 days to be included in CrUX. You can still use the lab results, and the origin-level summary may appear if the whole domain has enough traffic.

Is GTmetrix or WebPageTest better than PageSpeed Insights?

They are all lab tools with different settings and extra features, such as choosing test locations or recording filmstrips. None replaces field data. Pick one lab tool and stick with it so results stay comparable.

How long after a fix will field data improve?

Because CrUX uses a rolling 28-day window, improvements appear gradually and are fully reflected after about four weeks, assuming the page gets steady traffic.

Should I aim for a Lighthouse score of 100?

Not as a goal in itself. A score in the 90s is excellent, but passing Core Web Vitals for real users and keeping the site useful matter more than the last few points.