The short version
- They run the same engine. Lighthouse is the audit tool; PageSpeed Insights runs it and adds real-user field data.
- The field data is the important part — it is what Google actually measures, and Lighthouse alone does not have it.
- Your local Lighthouse score varies with your machine, network and browser extensions. Treat it as diagnostic, not as a measurement.
- For a site-wide view, use the Core Web Vitals report in Search Console rather than testing URLs one at a time.
People run Lighthouse in Chrome DevTools, get 94, then run PageSpeed Insights on the same URL and get 62, and conclude one of them is broken. Neither is. They are reporting different things, and understanding which is which resolves most confusion about web performance measurement.
Lighthouse is a lab test: one simulated load, under controlled conditions, on whatever machine is running it. PageSpeed Insights runs that same lab test and also reports field data from real users on real devices and real networks.
What each gives you
The third row explains most of the discrepancy people notice. Running Lighthouse on a fast laptop over office broadband produces a much better result than the simulated mid-range mobile connection PageSpeed Insights uses. Neither is wrong; the second is closer to a real user.
Which to use when
- Debugging locally? Lighthouse in DevTools. It works on localhost and iterates fast.
- Assessing a live page? PageSpeed Insights, and read the field data first.
- Reporting to a stakeholder? Field data only. A lab score is not a measurement of anything a user experienced.
- Looking at the whole site? The Core Web Vitals report in Search Console, which groups URLs by pattern.
- Monitoring over time? The PageSpeed Insights API, which is free and easy to schedule.
Why the lab score moves and the field data does not
A pattern that confuses teams: a developer optimises a page, the Lighthouse score jumps from 71 to 94, and the Core Web Vitals report in Search Console does not move for weeks. Nothing is broken. Field data is collected from real visits over a rolling window, so it reflects a population of sessions that mostly predate your change.
Expect a lag of several weeks before an improvement shows up in field data, and longer on low-traffic pages where there are fewer sessions to shift the distribution. That lag is the single most common reason performance work gets abandoned just before it would have registered — the lab number improved, the real number had not caught up, and somebody concluded it had not worked.
The way to manage that is to agree in advance which number you are judging by and when. Use the lab score during the work, as the fast feedback loop that tells you whether a change did anything. Use field data afterwards, on a stated review date several weeks out, as the number that decides whether it mattered. Mixing the two — optimising against the lab score and then reporting it as a result — is how performance work gets both over-claimed and prematurely abandoned.
A related trap is testing the wrong URL. PageSpeed Insights reports on the specific page you give it, and teams routinely test the homepage — usually the most carefully optimised page on the site — then conclude performance is fine. Test the templates that carry your traffic instead: an article page, a product page, a category listing. Those are what most visitors actually load and what the field data is aggregating.
Chrome extensions distort local Lighthouse runs
Extensions inject scripts into every page you load, which Lighthouse measures as part of the page. Always run local audits in an incognito window with extensions disabled, or your score is partly a measurement of your own browser setup.