Lighthouse vs PageSpeed Insights: what's the difference?

PageSpeed Insights and Lighthouse use the same engine. PageSpeed Insights (PSI) runs a Lighthouse lab test on Google’s servers and adds real-user field data from the Chrome UX Report, while Lighthouse on its own runs wherever you start it and only produces lab data. That one difference explains most of the confusion when the two show different numbers.

The short answer

Lighthouse is Google’s open-source auditing tool. You can run it from Chrome DevTools, from the command line, from its Node module, or through PageSpeed Insights. Every run tests one URL and scores it in four categories: Performance, Accessibility, Best Practices and SEO.

PageSpeed Insights is a web page that wraps two things:

• A Lighthouse lab run, done on Google’s infrastructure with fixed settings.
• Field data from the Chrome UX Report (CrUX), which shows how real Chrome users experienced that URL, or the whole origin, over the last 28 days.

So when someone asks “Lighthouse or PageSpeed Insights?”, the honest answer is that PSI already includes Lighthouse. The real question is whether you need lab data, field data or both.

What Lighthouse does on its own

Lighthouse loads a single page in a controlled environment and measures what happens. By default it emulates a mid-range phone on a slow 4G connection with a slowed-down CPU, using simulated throttling. It then reports lab metrics such as Largest Contentful Paint, Total Blocking Time and Cumulative Layout Shift, along with dozens of audits that explain what slowed the page down.

Where you run it changes the environment:

• Chrome DevTools runs Lighthouse inside your own browser, on your own computer. It is the quickest way to test a page you are building, including localhost and pages behind a login.
• The CLI and Node module run Lighthouse from a terminal or a script. This is the usual choice for automation and CI pipelines.
• PageSpeed Insights runs it on Google’s machines, so you cannot change the settings, but everyone who tests the same URL gets a similar environment.

Lighthouse never sees real visitors. It produces one simulated page load, which makes it ideal for debugging and for checking a fix right away.

What PageSpeed Insights adds

The field data section is what makes PSI different. At the top of the report, PSI shows a Core Web Vitals assessment based on CrUX data. A page passes when LCP, INP and CLS are all in the good range at the 75th percentile of real visits.

A few details matter here:

• Field data is shown separately for mobile and desktop visitors.
• PSI shows data for this URL when the page has enough traffic, and for the origin (the whole site) otherwise, if the origin qualifies.
• The data covers a rolling 28-day window, so a fix you ship today takes weeks to show in full.
• Interaction to Next Paint appears only in the field section, because a lab test has no real user clicking or typing.

Below that, PSI shows the Lighthouse lab report: the performance score, the five lab metrics, and the diagnostics and insights you would see in DevTools.

Lighthouse vs PageSpeed Insights at a glance

	Lighthouse (DevTools or CLI)	PageSpeed Insights
Engine	Lighthouse	Lighthouse
Where it runs	Your computer or server	Google’s servers
Lab data	Yes	Yes
Real-user field data (CrUX)	No	Yes, where Google has enough data
INP	No (TBT is the lab proxy)	Yes, in the field section
Can test localhost or private pages	Yes	No, the URL must be public
Settings you can change	Device, throttling method, categories and more	Mobile or desktop only
Best for	Debugging and testing changes	A quick public check plus real-user data

Why the two scores differ

It is normal for DevTools and PSI to disagree by a few points on the same page. The engine is the same, but the environment is not.

1. Hardware. Simulated throttling models a slower device starting from a page load on the machine that ran the test. A powerful laptop, a busy laptop with 40 tabs open and a Google server all produce slightly different traces, and so slightly different scores.
2. Browser state. DevTools runs in your profile. Extensions, cookies, a logged-in session or a consent banner you already dismissed can all change what loads. Testing in an incognito window removes most of this.
3. Location. PSI runs from a Google data center. If your server is in Frankfurt and the test runs from the US, server response time goes up, which affects every timing metric.
4. Lighthouse version. DevTools ships with your Chrome version, and PSI updates on its own schedule. A new Lighthouse version can change audits or how a metric is calculated.
5. Settings. DevTools lets you switch from simulated throttling to applied DevTools throttling, or pick desktop instead of mobile. If the settings differ, the scores are not comparable.
6. Normal variance. Even with identical settings, two back-to-back runs rarely match exactly. Ads, A/B tests and third-party scripts load differently each time. We cover this in detail in why your Lighthouse score changes every time you run it.

Why the lab score and field data in PSI disagree

A second, bigger kind of mismatch happens inside a single PSI report: the lab score says one thing, and the field data says another. This is not a bug. The lab test is one simulated visit on a fixed device. Field data is thousands of real visits on whatever phones, laptops and networks your audience actually uses, measured over the whole visit rather than only the initial load.

For example, a product page might score 92 in the lab but fail INP in the field, because real shoppers open size pickers and filters that run heavy JavaScript. Lighthouse never clicks those controls. The reverse also happens: a page can score 55 in the lab and pass Core Web Vitals in the field, because most real visitors use faster devices than the throttled test phone. Our guide to lab data vs field data explains these cases in depth.

Which one to trust for what

Each tool answers a different question, so match the tool to the job.

• “What is slowing this page down?” Use the Lighthouse lab report, in either tool. The audits and insights point at specific files, images and scripts.
• “Did my change help?” Use lab data, in the same tool, with the same settings, before and after. Run each version several times and compare the medians rather than single runs.
• “Are real visitors having a good experience?” Use the field data in PSI, or the Core Web Vitals report in Google Search Console, which groups similar URLs and is also based on CrUX.
• “Does this page pass Core Web Vitals for Google?” Field data only. The Lighthouse score is not what Google uses for page experience.
• “Is my staging site ready?” DevTools or the CLI, since PSI can only test public URLs.
• “I need to test hundreds of pages.” The CLI in a script, the PSI API, or a hosted bulk tool.

A simple rule: trust lab data to tell you why, and trust field data to tell you whether it matters to real users.

How to check this across your whole site

Both tools test one URL per run, which is the core problem we describe in Lighthouse only tests one page. The manual route is to export your sitemap, then either paste URLs into PSI one at a time, call the PageSpeed Insights API in a loop with an API key, or script the Lighthouse CLI. Each works, but you have to handle rate limits, retries, timeouts and the job of combining hundreds of reports. Our guide to bulk PageSpeed testing without the CLI walks through the options.

If you would rather not script it, AiroPages is a hosted option. You enter a domain or sitemap URL, and it runs Lighthouse on every page on mobile and desktop with PageSpeed Insights settings, records the Lighthouse version and test region for each run, and shows CrUX field data next to the lab scores where Google has it. Issues are grouped by page template, so you can see which fix helps the most pages.

The bottom line

Lighthouse and PageSpeed Insights are not competitors. PSI is Lighthouse plus real-user data, run on Google’s hardware. Use the lab report from either tool to diagnose and test fixes, keep your settings consistent when you compare numbers, and use field data to decide whether real visitors, and Google’s Core Web Vitals assessment, see the improvement.