Lighthouse | WebSpeed

Measured on real sites

1 of 21 images that arrived sooner through our own endpoint than from the original CDN We cut the image bytes in half and the score did not notice 9 audited sites
93% of reports flag unused JavaScript 93% of reports say to remove unused JavaScript. On the same 440 sites, what we could change was the order of delivery 440 audited sites
18% of mobile measurements put two rounds in different Lighthouse bands Measured three times in one sitting, 18% of mobile scores land in two different bands 447 audited sites
0 of 445 audited sites carry a classic render-blocking-resources key Zero of 445 audits report render-blocking resources. Of the ones we re-read, 78% still block the render 445 audited sites
5 font files the median site loads More font files, lower score — except on the platforms that choose the fonts for you 452 audited sites
63 of 482 audited sites ship the data-cfasync attribute 63 sites carry Cloudflare's opt-out attribute. Two of them run Rocket Loader 482 audited sites
3.4 MB median total page weight, over 102 requests On 45% of the sites we audited, JavaScript outweighs the images 457 audited sites
12 distinct hosts the median site loads from, beyond the one serving the page The median site we audited loads from 12 hosts it doesn't own 457 audited sites
67% of sites scored higher on mobile through the proxy Above 70, speeding up a site is a coin flip 381 audited sites
63% of sites had a hero image the browser could discover in the markup On 37% of sites, the browser can't find the hero image in the HTML 261 audited sites

Lighthouse is Google’s open-source auditing engine. It loads a page in a headless Chrome under controlled conditions, records what happens, and produces the PageSpeed score plus the underlying lab metrics and a list of opportunities. It powers the lab half of PageSpeed Insights, the Chrome DevTools “Lighthouse” tab, and command-line runs.

Lab conditions, and why the numbers feel harsh

By default Lighthouse simulates a mid-tier mobile device on a throttled connection, roughly a 4× slower CPU and a slow 4G network. That is deliberate: it models the visitor who struggles, not the developer on a fast laptop. It is why a site that feels instant on your machine can still score in the orange on mobile.

One run is not a measurement

The most useful thing we have learned from running Lighthouse thousands of times is how much a single run moves. Six consecutive mobile runs of the same URL, tailwindcss.com, through our proxy produced these performance scores:

72, 66, 64, 56, 71, 55

A sixteen-point spread, same page, same engine, same minute. That was one site, and we have since put a denominator under it: across 443 mobile measurements of pages as their owners serve them, the rounds inside a single measurement disagreed by 9 points at the median, and 18% of them placed two rounds in different score bands (the full study). Speed Index across those runs stayed between 2.8 s and 4.4 s, against 7.4 s to 11.2 s for the original, so the underlying improvement was stable and obvious. The composite score was the unstable part, because it blends five metrics and one of them, TBT, is sensitive to whatever else the CPU happened to be doing.

Lab data against field data

Lighthouse produces lab data: a single controlled load, reproducible and good for debugging. It cannot measure real interactions, so it estimates responsiveness from TBT rather than measuring INP. The field data in PageSpeed Insights, the Core Web Vitals assessment, comes from real Chrome users instead. Use Lighthouse to find and fix problems, and field data to confirm the fix reached real visitors.

Reading a run

Metrics — the five scored numbers (LCP, TBT, CLS, FCP, SI).
Insights — the advice section, named *-insight in the API response, each carrying an estimated saving per metric. In Lighthouse 13 these replaced the older Opportunities and Diagnostics lists, and some old audits were merged into one insight or retired outright.

The list arrives sorted, which is not the same as prioritised: on the 440 sites we counted, the two most frequent entries are unused JavaScript and unused CSS, both of which need the site’s own build to fix (the full breakdown).

How we run it

WebSpeed runs Lighthouse and the PageSpeed Insights API to measure every audit before and after proxying, so the before/after you see comes from the same engine Google uses. We also run it repeatedly, not once, because of everything above. If you want to run it yourself, the three ways to do it are in our guide to running a Lighthouse speed test.