PageSpeed Insights vs Lighthouse comes down to this: PageSpeed Insights is a Google web service that shows two things on one page, real-user field data from the Chrome User Experience Report and a Lighthouse lab test run on Google’s servers. Lighthouse is the open-source auditing tool underneath, which you can also run yourself in Chrome DevTools, from the command line or in CI. Use PageSpeed Insights to see whether real visitors pass Core Web Vitals. Use Lighthouse, locally and repeatedly, to debug a page and confirm a fix before you ship it.
People treat the two names as synonyms, and that causes real mistakes. I regularly get screenshots of a 98 from Lighthouse in DevTools with the question “why does Search Console say we fail?”. The tools are related, but they answer different questions and they run in different places. This page is about the tools themselves. If you want the concept behind them, read field data vs lab data for Core Web Vitals first.
What is PageSpeed Insights?
PageSpeed Insights (PSI) is the page at pagespeed.web.dev. You give it a URL and it returns a report with two separate sections.
The top section is field data from CrUX. It shows the 75th percentile of LCP, INP and CLS from real Chrome visits over the last 28 days, plus a few diagnostic metrics such as First Contentful Paint and TTFB, and the Core Web Vitals assessment (passed or failed). You can switch between this URL and the whole origin, and between mobile and desktop.
The lower section is a Lighthouse run. Google’s servers load your page once with an emulated device and simulated throttling, then show the performance score, lab metrics, diagnostics and opportunities. That section is the same engine you have in Chrome, just run somewhere else.
PSI also has an API, which returns both sections as JSON. That is handy for monitoring a list of URLs without opening a browser.
What is Lighthouse?
Lighthouse is an open-source tool maintained by the Chrome team. It audits a page in four categories: performance, accessibility, best practices and SEO. You can run it in several ways:
- The Lighthouse panel in Chrome DevTools.
- The command-line tool or Node module.
- Lighthouse CI, to run audits on every pull request or deploy.
- Inside PageSpeed Insights, where Google runs it for you.
Besides the default navigation mode, which loads the page from scratch, Lighthouse has timespan and snapshot modes. Timespan records a period while you interact with the page, which gets you closer to what happens after load.
Lighthouse never contains field data. Every number it produces comes from the single visit it just simulated.
PageSpeed Insights vs Lighthouse: side by side
| PageSpeed Insights | Lighthouse (DevTools, CLI, CI) | |
|---|---|---|
| Where it runs | Google’s servers | Your machine or your CI runner |
| Field data from CrUX | Yes, URL and origin, mobile and desktop | No |
| Lab test | One Lighthouse run per request | As many runs as you want, with your settings |
| Core Web Vitals assessment | Yes, from field data | No |
| INP | From field data | Not in a normal page load; Total Blocking Time is the lab proxy |
| Pages behind a login or on staging | No, the URL must be public | Yes |
| Accessibility, best practices, SEO audits | Yes, from the Lighthouse run | Yes |
| Automation | PSI API | CLI, Node module, Lighthouse CI |
Why do PageSpeed Insights and Lighthouse give different scores?
Because they are not running the same test, even when the Lighthouse version matches. A few reasons I check every time the numbers disagree:
- Hardware. PSI runs on Google’s machines. Lighthouse in DevTools runs on your laptop, and a fast laptop produces a better score. Background tabs and extensions also interfere with local runs, so I use an incognito window or a clean profile.
- Network and location. PSI fetches the page from Google’s infrastructure. A local run goes through your own connection and may hit a different CDN edge or a warm cache.
- Throttling settings. Both simulate a slower device and network by default, but DevTools lets you change that, and many people do without noticing.
- Run-to-run variance. Lighthouse results vary between runs even on the same machine, because of server response, third-party scripts and timing. One run is a sample, not a verdict. I run three to five and look at the median.
None of this affects the field data section in PSI. That part comes from CrUX and is the same no matter who requests it.
Which one should I trust for Core Web Vitals?
For the question “do we pass?”, trust the field data, which you see in PageSpeed Insights and Search Console. That is the data Google uses for the Core Web Vitals assessment. The Lighthouse performance score is not part of it. A failing assessment with a high lab score is common, and the reasons are covered in what to do when the Core Web Vitals assessment fails.
For the question “why is this page slow and did my change help?”, Lighthouse is the better tool, together with the Performance panel in DevTools. You can run it on staging, compare before and after, and repeat until the numbers are stable.
How I use both in a WordPress audit
My routine is the same on almost every site:
- PageSpeed Insights on the home page and one URL from each main template (post, page, product, category), reading only the field data. Mobile first.
- Search Console’s Core Web Vitals report to see which URL groups fail and how many URLs each group has.
- Lighthouse and the DevTools Performance panel locally on the worst template, to find the LCP element, long tasks and layout shifts.
- After a fix, Lighthouse again on staging, several runs, to confirm the lab metrics moved.
- Four weeks later, PageSpeed Insights again, to see whether the field data followed.
On WordPress the lab test often catches plugin and theme problems that field data only hints at: render-blocking CSS from a builder, a slider script loaded on every page, a hero image with lazy loading. The field data then tells me whether fixing it mattered for real visitors. For the metrics themselves, see LCP in WordPress and INP in WordPress.
What about pages with no field data?
New pages and low-traffic sites often show “no data” in the field section of PSI. CrUX only publishes data when there are enough visits. You can check the origin view instead, which aggregates the whole site. If that is empty too, Lighthouse becomes your main signal by default, and you should add real user monitoring. The web-vitals library from Google can send LCP, INP and CLS from your own visitors to your analytics, which fills the gap until CrUX has enough data.
Frequently asked questions
Is the PageSpeed Insights score the same as the Lighthouse score?
The score in PSI is a Lighthouse performance score, taken from one run on Google’s servers. Your local Lighthouse score uses the same scoring but a different machine and network, so the two often differ by several points or more.
Does Google use the Lighthouse score for rankings?
Google’s page experience documentation refers to Core Web Vitals, which are assessed with field data. The Lighthouse score is a lab diagnostic. I cover the ranking side in are Core Web Vitals a ranking factor?
Can I run Lighthouse on a staging site?
Yes. Lighthouse in DevTools or the CLI works on any URL your machine can reach, including staging and pages behind a login. PageSpeed Insights only tests public URLs.
The pillar guide, Core Web Vitals for WordPress, puts both tools in the full workflow. If you would rather have someone run this routine on your site and give you a prioritized list, that is what my WordPress performance audit delivers.