Should you really use PageSpeed Insights with Lighthouse to diagnose speed?

What does this integration actually change?

The integration of Lighthouse into PageSpeed Insights unifies two tools that, previously, could yield slightly different results based on their execution environment. Lighthouse, developed by Google, is an open-source auditing engine that assesses performance, accessibility, technical SEO, and PWA best practices.

PageSpeed Insights initially used its own scoring algorithms. Now, by relying on Lighthouse as the main engine, Google standardizes the evaluation methodology. This means that the displayed metrics — LCP, FID, CLS, FCP, Time to Interactive — are calculated exactly the same way as if you launched Lighthouse manually in Chrome DevTools.

Why does Google recommend this tool over others?

The reason lies in the consistency of data with the Core Web Vitals used for ranking. PageSpeed Insights now retrieves field data through the Chrome User Experience Report (CrUX) and combines it with simulated Lighthouse tests (lab data).

This dual approach allows you to cross-reference what your users are actually experiencing — aggregated CrUX data over 28 days — with what a simulated audit detects in controlled conditions. It is precisely this complementarity that Google values: a tool that diagnoses structural problems (lab) while confirming the real-world impact (field).

What limitations should you keep in mind?

The first limitation is that Lighthouse results vary depending on testing conditions. An audit run on a simulated 4G connection will yield different scores than one run on high-speed Wi-Fi. The CPU power of the machine running Lighthouse also affects Time to Interactive.

The second limitation is that PageSpeed Insights only tests one URL at a time, in isolated conditions. If your site loads third-party resources (analytics, advertising, widgets), their impact may be underestimated in lab data but evident in field data. Finally, the automatically generated recommendations don't always consider the actual technical constraints of a CMS or a proprietary stack.

• Lighthouse is natively integrated into PageSpeed Insights since this update, unifying the scoring methodology.
• Field data (CrUX) and simulated tests (Lighthouse) complement each other for a comprehensive diagnosis.
• Scores vary based on the testing environment: connection, CPU, browser cache, tested server.
• PageSpeed Insights remains a single-URL tool: it does not replace a full crawler for auditing an entire site.
• Automatic recommendations should be prioritized based on their actual impact and technical feasibility.

Is this recommendation consistent with real-world observations?

Yes, to the extent that Lighthouse has become the de facto reference for performance audits on Google's side. The Chrome and Search teams use the same Core Web Vitals metrics, so aligning PageSpeed Insights with Lighthouse ensures methodological consistency.

However, in practice, many professionals notice discrepancies between PageSpeed Insights scores and Search Console data. The Search Console aggregates CrUX data across the entire site, while PageSpeed Insights tests a single isolated URL in the lab. If your homepage shows a score of 95 but your product pages cap at 40, the Search Console will alert you to a global issue that PageSpeed Insights alone will not reveal. [To verify]: to what extent does Google weigh Lighthouse scores in its ranking algorithm — no public data specifies this.

What nuances should be added to this statement?

Google recommends PageSpeed Insights, but does not say it is the only valid tool. Solutions like WebPageTest, Dareboost, GTmetrix, or SpeedCurve provide more granular analyses, particularly on waterfalls, resource type distribution, or multi-location tests.

Another nuance: Lighthouse measures performance in a controlled synthetic context. A site can score 100/100 in the lab and show a catastrophic LCP in production if real network conditions differ. The integrated CrUX data in PageSpeed Insights corrects this bias, but they are only available for sites with sufficient Chrome traffic. Small site, no CrUX — so no field data to validate lab hypotheses.

In what cases is this tool insufficient?

PageSpeed Insights does not crawl, does not test multi-page user journeys, does not simulate concurrent server loads, and does not detect conditional performance issues — for example, a slowdown only visible after user login or on iOS Safari mobile (while Lighthouse tests with a Chrome emulator).

If you manage an e-commerce site with thousands of product pages, a media site with infinite pagination, or a complex SPA, PageSpeed Insights will give you a partial snapshot. You need to complement it with RUM monitoring (Real User Monitoring) to capture the real usage conditions, and a performance crawler to identify degradation patterns at scale.

What should you concretely do with PageSpeed Insights?

Start by testing your main templates: homepage, product page, blog article, category page. Don’t just rely on a single test — run multiple audits at different times of the day to capture server load variations. Note the discrepancies between mobile and desktop, and focus on the high-impact opportunities listed by Lighthouse.

Next, cross-reference these results with the CrUX data displayed at the top of the report. If lab data indicates an LCP of 1.8s but field data shows 3.5s, this means your real users are experiencing network conditions or third-party interactions that the synthetic test does not capture. Prioritize optimizing the blocking resources identified in the lab, and then measure the impact in the field via Search Console or a RUM.

What errors should be avoided when interpreting results?

Classic error: optimizing for the score rather than for the user. A site can reach 95/100 by deferring all non-critical JavaScript, but if the real interactivity is degraded — buttons not responding immediately, choppy animations — the user experience is poor despite the score.

Another pitfall: ignoring non-applicable recommendations. Lighthouse may tell you to reduce unused JavaScript, but if 80% of that JS comes from Google Tag Manager, Google Analytics, and advertising scripts imposed by the ad network, the room for maneuver is limited. Don’t waste time on optimizations of 0.2s if the bulk of the problem comes from a slow server or unoptimized images.

How can you check that the optimizations are effective?

Set up a systematic before/after tracking. Before any modifications, capture a complete PageSpeed Insights audit (lab + field), note the Core Web Vitals metrics in Search Console, and if possible install a RUM to track the P75 percentiles. Apply your optimizations in batches — image compression, lazy loading, CSS/JS minification — and then let it run for at least 7 days.

Then compare the new CrUX data (refreshed daily in PageSpeed Insights, aggregated over 28 rolling days in Search Console). If the field LCP drops from 3.2s to 2.1s and FID stays under 100ms, it’s validated. If there’s no visible change after 2 weeks, either the optimization is insufficient or it addresses a secondary bottleneck.

• Test the main templates (home, product, category, article) on mobile and desktop.
• Run multiple audits at different times to capture server load variations.
• Always cross-check lab data (Lighthouse) and field data (CrUX) to validate the real impact.
• Prioritize high-impact opportunities (non-optimized images, blocking JS, unused CSS).
• Monitor the evolution of Core Web Vitals in Search Console over 28 rolling days.
• Complement with RUM monitoring to capture real usage cases not detected in the lab.