Use Google PageSpeed Insights for real user speed evidence, and use Lighthouse when you need repeatable testing during development. PageSpeed Insights is better for understanding how a live page performs for actual visitors, while Lighthouse is better for controlled audits, debugging, and release checks. Google’s Core Web Vitals use thresholds such as LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1 as targets for a good user experience [source: Google]. If you care about search, conversions, and user trust, you should not treat either tool as optional.
TLDR: PageSpeed Insights and Lighthouse are related, but they do not answer the same question. PageSpeed Insights combines Lighthouse lab testing with real user data from Chrome users, so it is stronger for judging production performance. Lighthouse is better when your developer changes one script, image, or font and needs to test the effect right away. For example, an ecommerce page may score 92 in Lighthouse on a developer laptop, but show only 63 in PageSpeed Insights mobile field data because 75% of its real visitors are on slower phones and weaker networks.
What PageSpeed Insights Actually Measures
Google PageSpeed Insights, often called PSI, tests a specific URL and returns two main types of information: field data and lab data. This split is the reason many people get confused.
Field data comes from the Chrome User Experience Report, also known as CrUX. It reflects how real Chrome users experienced the page over a recent period. This is the part that matters most when you want to know whether users are actually getting a fast page.
Lab data is generated by Lighthouse inside the PSI report. It is a simulated test. It uses fixed settings for device type, network conditions, and CPU throttling. That makes it useful for diagnosis, but it is not a perfect mirror of your audience.
The catch is that PSI can be harsh. A page may feel quick in your office and still fail mobile field data. That is not a bug. It usually means your own device, Wi Fi, and location are not representative.
What Lighthouse Actually Does
Lighthouse is an open source auditing tool from Google. You can run it inside Chrome DevTools, from the command line, through Node packages, or in automated workflows. It audits performance, accessibility, SEO, best practices, and progressive web app features.
For speed testing, Lighthouse creates a lab environment and measures how a page loads under controlled conditions. It then produces a score from 0 to 100, plus detailed findings. Those findings may include unused JavaScript, render blocking resources, oversized images, poor caching, and slow server response.
Lighthouse is useful because it is repeatable. If a developer compresses a hero image from 1.8 MB to 220 KB, Lighthouse can show the effect almost immediately. If a third party tag adds 400 milliseconds of blocking time, Lighthouse can help catch it before release.
It drives me crazy that teams sometimes compare Lighthouse scores from different machines as if they are the same test. They are not always the same. Chrome version, extensions, local CPU load, and throttling settings can change results. For serious testing, run Lighthouse in a clean, scripted setup.
Google PageSpeed Insights vs Lighthouse: The Core Difference
The simplest distinction is this: PageSpeed Insights tells you how the live URL performs in the real world, while Lighthouse tells you how the page performs in a controlled test.
| Area | PageSpeed Insights | Lighthouse |
|---|---|---|
| Best use | Checking real user experience on a public URL | Testing changes during design and development |
| Data type | Field data plus Lighthouse lab data | Lab data only |
| Repeatability | Limited, because field data changes over time | High, when run in a controlled setup |
| Best audience | SEO teams, site owners, managers, analysts | Developers, QA teams, technical SEO teams |
| Main weakness | Not all pages have enough field data | Can miss real user conditions |
Why Scores Often Do Not Match
A common complaint is simple: “Why does Lighthouse show 90, but PageSpeed Insights shows 58?” The answer is usually audience conditions.
PageSpeed Insights may show poor mobile results because real users are on older Android devices, congested mobile networks, or distant locations. Lighthouse may run from a cleaner environment. It may not include the same cache state, cookie banners, location issues, or A B testing scripts seen by real users.
Another issue is timing. Field data is not instant. If you fixed images this morning, PSI field data may not reward you right away. Lab data may improve now, while field data may take more time to reflect the change.
When to Use PageSpeed Insights
Use PageSpeed Insights when the question is about production impact. It is the better choice for business reporting and performance monitoring at the page level.
- Before an SEO review: Check whether key landing pages pass Core Web Vitals.
- After a redesign: See whether real users are getting a faster or slower site.
- For stakeholder reports: Use field data because it is easier to tie to user experience.
- For competitor checks: Test public URLs and compare visible performance issues.
PSI is also useful because it shows origin level data when URL level data is not available. This helps smaller pages that do not have enough traffic for a dedicated field report.
When to Use Lighthouse
Use Lighthouse when you need control. It is ideal before code reaches production.
- During development: Test a new template, product page, or checkout step.
- In continuous integration: Block a release if performance drops below a set score.
- For debugging: Identify scripts, images, fonts, and layout shifts that need work.
- For repeat testing: Run the same page under the same lab settings after each change.
For teams with mature workflows, Lighthouse CI is often the more serious option. It lets teams set budgets for page weight, total blocking time, and other metrics. Chrome’s documentation explains that Lighthouse can be run through DevTools, the command line, and Node tooling [source: Chrome].
Which Metrics Should You Watch First?
Do not obsess over the single score. It is useful, but it can hide the real issue. Focus first on metrics that affect how a user feels the page loading.
- Largest Contentful Paint: How quickly the main content appears.
- Interaction to Next Paint: How responsive the page is after a user action.
- Cumulative Layout Shift: How much the page jumps while loading.
- Total Blocking Time: A lab metric that often explains poor responsiveness.
- First Contentful Paint: How soon anything useful appears on screen.
If you have to start somewhere, fix large images, slow server response, render blocking CSS, and heavy JavaScript. These issues appear again and again. They are boring, but they move the numbers.
A Practical Workflow That Works
A sensible testing process uses both tools. Start with PageSpeed Insights to identify pages with poor field data. Then run Lighthouse locally or in CI to isolate the causes. After fixes go live, return to PageSpeed Insights to verify lab gains first, then monitor field data over time.
For example, a publisher may find that an article page fails LCP on mobile with a 3.9 second result. Lighthouse then shows a 1.4 MB hero image and two blocking ad scripts. The team compresses the image, preloads it, and delays nonessential scripts. Lighthouse improves right away. PSI field data may improve later as real users load the fixed page.
Final Recommendation
Do not choose between PageSpeed Insights and Lighthouse as if one replaces the other. Use PageSpeed Insights to judge real user performance. Use Lighthouse to diagnose and prevent problems before users see them.
If you run only PSI, you may know that a page is slow but not have enough control to test fixes cleanly. If you run only Lighthouse, you may ship a page that looks great in a lab but struggles for real visitors. The serious approach is simple: measure live pages with PSI, debug changes with Lighthouse, and track Core Web Vitals as business metrics rather than vanity scores.
