How to measure page speed: Lighthouse, PageSpeed Insights and CrUX

The field data in PageSpeed Insights covers the previous 28 days (PageSpeed Insights documentation (external site)). The lab test is a snapshot. None of these tools gives you one single load time, because each measures several metrics. The metric closest to what people mean by load time is Largest Contentful Paint (LCP), which measures loading performance (web.dev on Web Vitals (external site)). The table shows which question each tool answers. For the thresholds and how to improve your scores, see our article on Core Web Vitals. Our guide to technical SEO covers the rest of a website’s technical foundation.

Done when you’ve picked the right tool for your question: field data for real visits, Lighthouse for the effect of a change.

Open PageSpeed Insights (external site), enter a URL and go through the report in this order:

1. Choose a device. Mobile and desktop results are separate. Start with the device type your customers use most, and if in doubt, with mobile.
2. Check the scope. If a URL has too little data, PageSpeed Insights shows the values for the whole website. The result then says little about your slowest page.
3. Read the assessment. A page passes if all three metrics are good at the 75th percentile. If INP data is missing, good values for LCP and Cumulative Layout Shift (CLS) are enough. If LCP or CLS data is missing, there’s no assessment.
4. Read the distribution. The value above the bars is the 75th percentile. If it says 2.4 s for LCP, three out of four page views came in at 2.4 s or less, and the last quarter took longer.
5. Note the time period. Field data covers 28 days and is updated daily, so an improvement you make today only shows up gradually. The CrUX API always lists the period as 28 days, even if a page has been online for less time (CrUX API documentation (external site)).
6. Put the lab test in context. Only now look at the score. A score of 90 or above counts as good. For mobile, Lighthouse in PageSpeed Insights emulates a mid-tier phone on a mobile network and runs on a Google server in North America, Europe or Asia. The report’s environment details name the location.

Common mistake: People read the score first, even though the measurements from real visits are right above it.

Done when you can tie every value to a device type, a scope and a time period. The details of the report and the test setup come from the PageSpeed Insights documentation (external site).

By default, Lighthouse on your computer uses the same simulated throttling as the lab test in PageSpeed Insights (Lighthouse docs on throttling (external site)). Differences come mainly from hardware, load on the machine and the network. Malware, browser extensions and antivirus software have a particularly strong effect on the measurement (Lighthouse docs on variability (external site)).

To keep numbers comparable, record three things:

• Tool and version: Lighthouse in the browser, in a test pipeline or in PageSpeed Insights, each with its version number.
• Environment: the same computer or testing service, a browser profile without extensions and no other load on the machine.
• Page and state: the same URL with the same content, with no A/B tests running and no rotating ads.

Common mistake: A value from PageSpeed Insights gets compared with a run on your own computer.

Done when every number comes with a note of the tool, version, environment and state of the page.

Lighthouse results vary even when nothing on the page has changed. Running several Lighthouse instances at the same time distorts the results further (Lighthouse docs on variability (external site)). The median works better than the average here because a single outlier barely moves it.

If you don’t write code, run Lighthouse in Chrome DevTools five times in a row and note the values. With Lighthouse CI, one command does the measuring:

npx -p @lhci/cli lhci collect --url https://example.com/ -n 5

Here’s how to go about it:

1. Choose the URLs you’ll always measure, such as your home page, your most important service page and your contact page.
2. Before a change, measure each URL five times and note the median for each metric.
3. After the change, measure five times again in the same environment.
4. Only evaluate the difference once it’s larger than the spread of the five runs.

Assess the difference in milliseconds for each metric. The score alone hides what changed.

Common mistake: You measure once before and once after a change and credit the change with the whole difference.

Done when you know the median before and after the change for each page, and the difference is larger than the spread of the five runs.

• Response to input. INP is harder to measure in the lab than with real visits. There, Lighthouse uses Total Blocking Time (TBT) as a stand-in (web.dev on TBT (external site)).
• Device and location. A lab test runs on one device, on one network and from one location (web.dev on lab and field data (external site)). Your visitors use many devices and networks.
• Cache. Lab tests usually start with an empty browser cache. Returning visitors often have files stored already.
• Server response. By default, Lighthouse loads the page without throttling and calculates from that how it would have loaded on a slow connection. The documentation gives 150 ms of latency and 1.6 Mbps of throughput and points out inaccuracies in edge cases.

For server time, the model takes the median of the observed response times of all requests to the same server. That’s true both of the version we use (Lighthouse 12.6.1 source code (external site)) and of the latest one (Lighthouse 13.6.0 source code (external site)). A single very slow response can disappear in that median. Our measurements on datafalke.de show how much that can matter.

Our article on Core Web Vitals explains the basic difference between lab and field data in its section What’s the difference between lab data and field data?

Done when you treat a good lab value as an indication and use field data for real visits.

If there’s too little data for a URL, PageSpeed Insights shows the values for the whole website. If that isn’t enough either, it shows no field data (PageSpeed Insights documentation (external site)). In Search Console, this state is called “No data available”: either the property is new or there’s not enough data in the Chrome UX Report (Search Console Help on the Core Web Vitals report (external site)).

Missing field data isn’t a bad rating. Google doesn’t describe in its documentation how it treats such pages in rankings.

Here’s how to go about it:

1. Check the conditions. To be included in the Chrome UX Report, a page must be publicly discoverable, return status 200 and not carry a noindex directive (CrUX methodology (external site)). If your website is missing from Google, see our how-to Why isn’t my website showing up on Google?
2. Keep measuring in the lab. With every change, take the median of five runs for your most important pages.
3. Measure it yourself if needed. Google’s web-vitals (external site) library records Web Vitals in your visitors’ browsers. You need a script on the page and somewhere for the values to go. Check with your data protection advisor first whether and how you may use it.
4. Wait. Google doesn’t give a date. Once your website reaches the minimum number of visits, the Chrome UX Report includes it automatically.

Common mistake: A lab value appears in a report to management as if it were the load time of real visits.

Done when your pages meet the conditions and you have a dated lab value for your most important pages.

The numbers in the “Sources” column refer to the source list at the end of this article.

Google doesn’t say that a higher score leads to better rankings. You’ll find more on that in our article on Core Web Vitals. Our website migration checklist shows when to measure again after a redesign.

Done when you check before every comparison that both numbers come from the same environment.