Test the speed of a page with PageSpeed Insights

How to use the tool

Enter the address of a page, with or without “https://”, choose the simulated device and run the test. The tool asks the PageSpeed Insights API for the analysis, the same one behind the pagespeed.web.dev site. Google loads the page from its own servers and sends back its measurements.²

The result opens on a summary: the page analysed, the device, the date and the performance score. Two clearly separated blocks follow, field data then lab data, and finally the main improvement opportunities with the saving announced for each. A link leads to the full report on pagespeed.web.dev, which details every audit.

Field data and lab data

The two blocks measure different things and should not be added together. Field data comes from real visitors using Chrome: the API takes it from the Chrome User Experience Report, or CrUX.² It describes the experience people actually have on the page, with all the variety of devices, networks and behaviour. Lab data is produced by Lighthouse, which loads the page once under controlled, simulated conditions.²

The two sources differ for known reasons. The lab uses a single device, a single network and often an empty cache, while returning visitors benefit from the cache or from instant page restoration. In the field, the largest element on the page can vary from one screen to another, and layout shift counts what happens during scrolling or after a click.⁵

The approach web.dev recommends has two steps: rely on field data to set priorities, because it reflects what visitors experience, and use the lab to diagnose a problem and check that a fix works.⁵ A page with few visits has no field data, and the tool says so in that case.

The three field metrics and their thresholds

There are three Core Web Vitals. Largest Contentful Paint (LCP) measures when the largest visible element appears: the “good” threshold is 2.5 seconds. Interaction to Next Paint (INP) measures responsiveness to clicks, taps and key presses: the “good” threshold is 200 milliseconds. Cumulative Layout Shift (CLS) measures unexpected movement of content while the page loads: the “good” threshold is 0.1.¹

Google asks for these thresholds to be met at the 75th percentile of page loads, separately on mobile and on desktop. In practice, 75% of visits must do at least as well as the threshold. A page is considered to pass when all three metrics do.¹ The tool shows the 75th percentile value returned by the API and uses the category Google assigns to it, with the “good” threshold repeated under each line.

The Lighthouse performance score

The score shown at the top, from 0 to 100, comes from the lab. Lighthouse splits it into three colour bands: 90 to 100 for green, 50 to 89 for orange, 0 to 49 for red. It is calculated from five lab metrics: First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time and Cumulative Layout Shift. The opportunities do not enter the calculation, although applying them often raises those metrics.⁴

This score moves from one run to the next. The Lighthouse documentation lists A/B tests, ads, network routing changes, device differences and browser extensions among the causes, and advises treating performance as a distribution of scores rather than a single value.⁴ Run the test again after the 10-minute cache has expired if you want a second measurement.

The improvement opportunities

Below the metrics, the tool lists the Lighthouse audits that announce a saving, sorted from largest to smallest: estimated time saved, in seconds, and weight saved, in kilobytes or megabytes when the audit gives one. The text of each opportunity is Lighthouse’s own, in your language. These savings are lab estimates: they show where to look, and the real result in the field may differ.

For a page that fails on LCP, image and render-blocking resource opportunities are the first place to look. For a page that fails on INP, the lab cannot be trusted: it cannot predict this metric, which depends on real interactions.⁵ You then need field data and the browser’s developer tools.

Does speed matter for rankings?

Google answers on its page about page experience. There is no single signal: its ranking systems look at several signals, Core Web Vitals among them. A good result does not guarantee a top position, and Google states that the relevance of the content comes first, with a good page experience helping mostly when many useful pages answer the same query.⁶

For a showcase site, speed therefore serves visitors first. A slow site loses people before they have read the first line, whatever its effect on rankings. Fixing whatever makes one of the three field metrics fail pays off more than a score of 100 pursued for SEO alone.⁶

What the tool does, and its limits

The tool queries Google’s free API with the category set to “performance”, so it returns neither the accessibility, best practices nor SEO categories of Lighthouse. The mobile or desktop choice is sent explicitly, because without it the API analyses desktop.³

The API has a quota. It works without a key, but the documentation recommends using one for frequent or automated requests.² When the quota is used up, the tool says so and offers the link to the report on pagespeed.web.dev. The documentation also states that Google plans to remove field data from this API and points to the CrUX API: if that happens, the field block of the tool will stay empty and the tool will say so.²

Local and private addresses, and addresses with credentials, are refused. No tested address is kept beyond the 10-minute cache, which holds only the public measurements returned by Google.

After the test

A speed test covers only one aspect of a page. To check the rest of its tags, headings and links, the on-page SEO audit summarises them in a single analysis. Speed is also one of the points in the checklist for auditing your site. When the field metrics fail and the fixes need technical work, it falls within the SEO support I provide to my clients.

Frequently asked questions