Since 2020, Google has developed a vast ecosystem of tools to analyze website performance from the perspective of Core Web Vitals. Some rely on real user data, others on on-demand tests, and the two best-known, PageSpeed Insights and Lighthouse, are so often confused that audits still present lab scores as a rating assigned by Google to the site.
Lighthouse is an open-source audit engine, integrated into Chrome's developer tools, which loads a page under simulated conditions and produces a score and recommendations. PageSpeed Insights is an online service that runs this same engine on Google's servers, and adds field data from the Chrome User Experience Report. The difference can be summed up in one sentence: one measures a simulation, the other adds reality to it, and only reality matters for SEO.
This article explains the difference between field and lab data, what the two tools share and what distinguishes them, how to read a Lighthouse score since the redesign of version 13 in October 2025, and which one to use depending on the question asked. Why might a site show 100 on Lighthouse and fail Core Web Vitals in Search Console?
What's the difference between field and lab data?
Field data is collected from your real visitors during their browsing, on their devices and connections; lab data comes from a replayed load under controlled conditions, a simulated Moto G4 on a mobile network for PageSpeed Insights. The former measures what happens, the latter explains why. Neither replaces the other.
What is field data?
Field data, or data from the field, is recorded on your visitors' devices and connections, then aggregated at the 75th percentile over 28 rolling days. The only public source is the Chrome User Experience Report, CrUX, powered by Chrome users, and it's what Google uses to evaluate Core Web Vitals in Search Console. Its methodology specifies that for a user to contribute to it, four conditions must be met:
- have enabled usage statistics reporting in Chrome;
- sync their browsing history with their Google account;
- not have set a sync passphrase, which encrypts data end-to-end;
- use a supported platform, which excludes Chrome on iOS, Android WebViews, and other Chromium-based browsers like Edge.
Google does not publish the proportion of users who meet these criteria, and the absence of iOS introduces a known bias: iPhone owners, often better equipped, are not included, which pulls the numbers down. This data is also subject to high variability, depending on each visitor's location, connection, hardware, and extensions. This is why we work at the 75th percentile, and with the three-segment distribution gauge, well, to improve and bad:
What is lab data?
Lab data, or synthetic data, comes from an on-demand load on a simulated machine and network. It is reproducible, immediately available, and detailed down to the request and line of code. It says nothing about your real visitors, but it is the only way to diagnose, because it exposes the complete loading cascade.
Analysis can be launched from a user's browser, as Lighthouse does in DevTools, or from dedicated infrastructure, as PageSpeed Insights, WebPageTest, or GTmetrix do. In the latter case, the advantage is that the conditions remain identical from one test to another: same processor, same memory, same simulated bandwidth and latency. This stability allows comparing the same site over time, or several sites against each other, with indicators that do not depend on network mood.
Unlike field data, the lab produces unique values, in milliseconds for FCP, LCP, Speed Index, and Total Blocking Time, as an index for CLS, each associated with a green, orange, or red threshold. One metric is missing, and it's no coincidence: INP does not exist in the lab, due to lack of interactions, and TBT is only an approximation during loading.
What are the common points between PageSpeed Insights and Lighthouse?
Both tools run the same analysis engine, Lighthouse, and therefore produce the same performance score and recommendations on a given page. PageSpeed Insights is Lighthouse run on Google's servers, in a data center in North America, Europe, or Asia depending on the load, with an imposed network and hardware configuration.
The PageSpeed Insights documentation specifies that Lighthouse simulates a mid-range device, a Moto G4, on a mobile network, and an emulated desktop on a wired connection. The first tool thus performs the test via Google's infrastructure, the second via your own machine and your own connection, which explains most of the discrepancies between the two. The results are presented in a visually identical interface, adapted for mobile and desktop :
This common layout is divided into three sections. An overall performance score out of 100, calculated transparently from lab metrics, orange from 50 and green from 90. The five main metrics, FCP, Speed Index, LCP, TBT, and CLS, which are supposed to reflect the user experience. And a filmstrip view of the loading stages, which allows you to spot an excessively high TTFB, a main image discovered late, or a layout shift at a glance.
Since Lighthouse 13, the old audits have been replaced by insights, the same ones as in the Performance panel of DevTools.
For both, you need to take a step back: this data is only a snapshot at a given moment, under conditions that probably do not reflect those of your visitors. The PageSpeed Insights documentation states this plainly: good lab data does not necessarily mean that the real user experience will be good. A green score does not guarantee passing the Core Web Vitals in the field, and only CrUX data counts for Google.
Is your site as fast as your visitors expect?
What are the differences between PageSpeed Insights and Lighthouse?
PageSpeed Insights adds field data from CrUX, which is absent from Lighthouse; Lighthouse, locally, analyzes four facets instead of just one, accepts non-public pages, and allows you to choose the simulated device and network. One is used to position a site, the other to diagnose it, including in pre-production or behind authentication.
| Criterion | PageSpeed Insights | Lighthouse |
|---|---|---|
| Field data | Yes, via CrUX, 28-day rolling | No |
| Lab data | Yes, Lighthouse engine | Yes, locally |
| Facets analyzed | Performance | Performance, accessibility, best practices, SEO |
| Execution environment | Google servers, simulated Moto G4, imposed | Your machine, configurable |
| Private or local pages | No | Yes |
| Recommended use | Position and track | Diagnose and test |
The decisive line of this table is the first one. Only PageSpeed Insights exposes field data, the data Google uses to evaluate your site: a lab score of 100 on a page with poor field Core Web Vitals is worthless for SEO. The opposite is also true, and much more common than we think: a score of 70 with a completely green field means the site is doing well.
Lighthouse, beyond performance
Lighthouse is not limited to performance: it also analyzes accessibility, best practices, and SEO, each scored out of 100. These three aspects are absent from the public PageSpeed Insights score. This is what makes it a recipe tool, executable before each production release, including from the command line in a continuous integration:
# Lighthouse en ligne de commande : les quatre volets, en JSON, sur une page de preproduction
npm install -g lighthouse
lighthouse https://preprod.exemple.fr/produit/ \
--preset=desktop \
--only-categories=performance,accessibility,best-practices,seo \
--output=json --output-path=./rapport.json
# Les scores, entre 0 et 1
jq '.categories[] | {id, score}' rapport.json
# Les insights de performance qui ont echoue (Lighthouse 13)
jq '.audits | to_entries[] | select(.key | endswith("-insight")) | select(.value.score != null and .value.score < 0.9) | .key' rapport.jsonThese complementary aspects do not replace an RGAA accessibility audit or an SEO audit, but they allow you to take the temperature in a few seconds and detect gross regressions with each deployment. As web performance is a cross-functional discipline, it is common for an expert to address these related topics, and Lighthouse is the first, least expensive approach to do so.
PageSpeed Insights, with field data added
PageSpeed Insights displays, above the lab score, the Core Web Vitals actually measured on your site by Chrome users over the last 28 days. This section only appears if your traffic is sufficient to feed the CrUX: the documentation specifies that if there is no data for the page, the tool falls back to the entire origin, and if there is no data for the origin, it displays nothing. Its absence signals a site that is too little visited to appear in the public database, not a fast site.
This section is presented first, before the synthetic analysis, and this is not a layout coincidence. It is important to clearly distinguish the "Discover your users' experience" section, which covers field data, from the "Analyze performance issues" section, which covers lab data. The first tells you if you have a problem, the second helps you understand what it is:
The panel is read in four zones. To the right of the title, a selector toggles between page metrics, This URL, and those of the entire site, Origin, very useful for identifying a cross-cutting issue. At the top center, the tool indicates whether the page or site passes the Core Web Vitals assessment. In the center, field metrics in distribution bars, including the three Core Web Vitals, LCP, INP, and CLS, plus FCP and TTFB.
At the bottom, on a gray background, the collection conditions, with the 28-day rolling period, which explains the inertia of these figures: a correction deployed today takes almost a month to be fully reflected.
How to interpret a Lighthouse score?
A Lighthouse score is read in three tiers: from 90 to 100 it is good and green, from 50 to 89 it requires fixes and is displayed in orange, below 50 it is bad and red. This score is not a measure of site quality, but the weighted average of five lab metrics, where Total Blocking Time alone accounts for 30%.
A weighted average, not a grade
The weighting explains most of the misunderstandings. The score calculation documentation gives the weights in effect since Lighthouse 10: First Contentful Paint 10%, Speed Index 10%, Largest Contentful Paint 25%, Total Blocking Time 30%, Cumulative Layout Shift 25%. TBT and LCP therefore account for more than half the score, and gaining ten points does not require the same effort depending on the target metric: two sites with the same score can have opposite profiles, one slow to display and responsive, the other the reverse.
Variability, and what is not a signal
Two successive runs on the same page commonly yield scores differing by several points. The same documentation acknowledges this: a large part of the variability does not come from Lighthouse but from underlying conditions, A/B tests or ads served, network routing, test device, extensions injecting JavaScript, antivirus.
Google also recommends viewing a site's performance as a distribution of scores rather than a single number, and specifies that a perfect score of 100 is extremely difficult to achieve and not expected. A difference of less than five points is not a signal, it is measurement noise.
What changed with Lighthouse 13
The score hasn’t changed, but the recommendations have changed form. Since Lighthouse 13, released on October 10, 2025, and deployed in PageSpeed Insights the following week, the old audits have been replaced by common insights from the Performance panel in DevTools: document latency, LCP discovery and phases, CLS culprits, render-blocking, third parties. Barry Pollard from the Chrome team announced this as early as April 2025, specifying the logic behind this consolidation.
In some cases, the advice from many audits is grouped into a single insight, and we have removed some advice.
Barry Pollard, Web Performance Developer Advocate at Google, in his post Lighthouse is moving to performance insight audits, published on April 28, 2025
Among the removed advice are the audits for third-party facades, offscreen images, and preload, which were deemed too often counterproductive. A 2026 report therefore no longer resembles a 2024 report, and guides that still list the old audits are outdated. What Lighthouse will never see, however, hasn’t changed: the lab score has no ranking value. Google uses field Core Web Vitals, at the 75th percentile, and a site can pass them with a score of 75.
Which tool to choose between PageSpeed Insights and Lighthouse?
Use PageSpeed Insights to know where you stand, Lighthouse to understand why and fix it. The former is the arbiter, as it carries the data Google uses; the latter diagnoses, on any page, even private ones, with the device and network you choose. Relying solely on the lab score is the most common mistake we encounter.
Both tools approach web performance from a particular angle, and they complement each other at all levels. Ideally, they are just one piece of a larger ecosystem. At the agency, we use complementary tools that don’t come from Google: WebPageTest and GTmetrix, which offer much more extensive testing options, detailed waterfall, domain blocking, user journey scripting, repeat views; and dozens of specialized tools for CLS, HTTP headers, fonts, or security.
Our article on measuring web performance situates each within this landscape, and the guide on third-party scripts shows how domain blocking settles a debate in five minutes.
There remains a case where neither is sufficient. An iframe widget, a chat, or a review block, producing CLS and INP that CrUX counts but neither Lighthouse nor a custom RUM sees, and a tag manager degrades INP with every click without ever appearing in a loading report. These blind spots will be the subject of dedicated guides for customer relationship widgets and Google Tag Manager.
In principle, the only data you cannot do without is from the Chrome User Experience Report, and Search Console already gives you access to it via the Core Web Vitals tab, with more detail than PageSpeed Insights. Neither of the two tools is therefore indispensable : the essential thing is to know what question each can answer, which is precisely the starting point for a web performance audit.
