In Chrome DevTools

This runs on your machine, over your connection, in your browser profile. It is the fastest to reach and the easiest to contaminate: extensions, other tabs and whatever else your CPU is doing all land in the result.

  1. Open the page you want to test in Chrome. Use a regular tab, then open DevTools with F12 or Ctrl+Shift+I (Cmd+Option+I on macOS).
  2. Switch to the Lighthouse panel. It sits alongside Elements and Network. If you do not see it, open it from the overflow menu.
  3. Choose Mobile and the Performance category. Mobile is the harsher configuration and the one Google reports on first. Leave the other categories on only if you want them.
  4. Click Analyze page load. The page reloads under throttling and the report appears in about half a minute.
  5. Run it at least three times. Take the median of the runs rather than the first one, and compare bands rather than single points.

Two settings matter more than the rest. Mobile applies CPU and network throttling and produces the number people quote; desktop is a different, gentler test, not a better one. And an incognito window with extensions disabled removes the largest source of local noise, because an ad blocker changes what the page loads, which is exactly what you are measuring.

On the PageSpeed Insights site

pagespeed.web.dev runs the same Lighthouse on Google's machines instead of yours. Paste a URL and you get two things DevTools cannot give you: a run unaffected by your laptop, and, if the page has enough traffic, field data from real Chrome users alongside the lab score.

The page has to be publicly reachable, so no staging behind a login and no localhost. And be aware that a repeat test of the same URL moments later can hand you the previous analysis rather than a fresh one; see below.

From the command line

For repeat measurement, scripting or CI, run it directly. Node 18 or newer, and Chrome installed: 

npx lighthouse https://example.com \
  --preset=desktop \
  --output=html --output-path=./report.html

Drop --preset=desktop to get the mobile configuration, which is the default. Add --only-categories=performance to skip the rest, and --chrome-flags="--headless" to run without a visible window. The same engine also answers over the PageSpeed Insights API, which is what our own audits call.

The score moves. Plan for it

This is the part missing from most instructions, and it changes what a single result is worth. We measure every page three times per audit and keep each round. Across 443 mobile measurements of sites as they are, before anything of ours touched them, the rounds inside one sitting disagreed by 9 points at the median, and 18% of those measurements produced two rounds in different Lighthouse bands: the same URL, minutes apart, reported in two different colours.

Three habits follow, and they cost nothing.

  • Run it three times and take the median. Lighthouse's own documentation puts it plainly: the median of five runs is twice as stable as one.
  • Check that your repeat runs actually ran. PageSpeed can answer a repeat request for the same URL with the previous analysis. In the API the giveaway is an identical analysisUTCTimestamp, and a reply that arrives in under a second. Change the URL with a parameter your server ignores, or wait.
  • Compare bands, not points. A move from 62 to 68 is inside what one page produces twice in a row. A move from 48 to 71 is not.

The full measurement is in our study of what one PageSpeed run tells you, including what happens to a before/after comparison when both sides carry that spread.

Reading what comes back

The performance section arrives as a sorted list, which reads like a priority order and is not one. Across 440 sites we audited, the two most common entries are unused JavaScript (93%) and unused CSS (86%), and both are answered by rebuilding the site's own bundles. Three more of the top six, bootup time, main-thread work and long tasks, describe the same scripts from three angles.

So the first useful cut is not "which item do I open" but "which of these needs the source code". Everything that does is a job for whoever owns the build. Everything that does not, meaning order of delivery, priority, caching headers and image sizing, can be changed in front of the site.

The full comparison, hint by hint across all 440 sites, is in what Lighthouse tells you to fix, and what can actually be fixed.

For the metrics themselves, the definitions are in our glossary: LCP, CLS, TBT, Speed Index and how the score is computed from them.