A developer runs PageSpeed Insights and gets 42. The client runs GTmetrix and gets an A. Someone runs Lighthouse twice in a row and gets 68 then 81. Search Console says the pages are passing. All four are correct, and the argument that follows wastes an afternoon.
The disagreement is not a bug and it is not a matter of one tool being better. These tools measure different quantities, on different hardware, under different network conditions, for different populations of users, and some of them are not measuring your visitors at all. This piece explains what each tool actually does, where the numbers come from, why they differ, and which one to use for which decision. The fixes themselves are elsewhere on this site; this is about reading the instruments correctly before you start fixing anything.
Everything factual here is from official documentation read on 2 November 2026, with sources at the end.
The single distinction that resolves most arguments
Every measurement in this subject is either lab data or field data, and confusing the two is the cause of almost every pointless debate.
Lab data is a page loaded once, by a machine, under conditions the tool chose. It is reproducible, it is available for any URL immediately, and it tells you what is slow and why. It is not what your users experienced.
Field data is what real people actually measured in their own browsers, on their own phones, on their own networks, aggregated. It tells you whether you have a problem. It cannot tell you what to fix, it needs enough traffic to exist at all, and it lags by weeks.
Both are necessary and they answer different questions. Field data decides whether to act. Lab data decides what to change. A team arguing about which score is real is usually comparing a lab number to a field number.
Google’s Core Web Vitals, and the 75th percentile
Before the tools, the targets they are all reporting against. Google’s own guidance gives three metrics with these good thresholds: Largest Contentful Paint should occur “within 2.5 seconds of when the page first starts loading”, Interaction to Next Paint should be “200 milliseconds or less”, and Cumulative Layout Shift should stay at “0.1 or less”.
The part that matters for reading any report: assessment is at the 75th percentile. Google’s wording is that “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices”. So a page passes when three quarters of real loads met the target, split by device type. Your own fast load on office wifi is not the measurement, and neither is the worst load you have ever seen. If a quarter of your visitors are on a struggling connection, that quarter decides your result.
Lighthouse: the lab engine inside almost everything
Lighthouse is the open-source audit tool that powers PageSpeed Insights, the Chrome DevTools Lighthouse panel, and a good number of third party tools. It is, in Google’s description, “an open-source, automated tool to help you improve the quality of web pages”, with “audits for performance, accessibility, SEO, and more”.
The performance score is a weighted average, and knowing the weights changes what you work on. For Lighthouse 10 they are: Total Blocking Time 30 per cent, Largest Contentful Paint 25 per cent, Cumulative Layout Shift 25 per cent, First Contentful Paint 10 per cent, Speed Index 10 per cent.
Read that distribution carefully. Total Blocking Time alone carries 30 per cent, which is JavaScript execution blocking the main thread, and it is the metric most teams ignore while they compress images. Together, blocking time and layout shift are 55 per cent of the score, and neither is about file sizes. That is why a site can pass every image audit and still score badly, and it is why the third party script problem dominates real results on most marketing sites.
Note also that the weights changed between versions. Lighthouse 8 included Time to Interactive at 10 per cent and weighted Cumulative Layout Shift at 15 per cent. A score from two years ago is not comparable to one from today, which is reason enough to stop recording the score as a KPI.
Why two Lighthouse runs disagree
This is documented rather than mysterious. Google states that “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse”, and lists the causes: A/B tests and shifting ad content, changes in internet traffic routing, running tests on different hardware such as a desktop versus a laptop, browser extensions that inject JavaScript or alter network requests, and antivirus software.
The practical consequences. Never run Lighthouse in your everyday Chrome profile, because your extensions are in the measurement. Use an incognito window with extensions disabled, or the command line, or the hosted version. Run it three to five times and take the median rather than the best or the most recent. And never compare a score from your laptop with a score from someone else’s, because the hardware is part of the result.
PageSpeed Insights: two reports on one screen, and the confusion that follows
PageSpeed Insights shows both kinds of data for a URL, which is its value and the source of most misreadings. The top section is field data from the Chrome UX Report, which is real users. The lower section is a Lighthouse run performed on demand, which is lab. People screenshot the big score, which is the lab number, and discuss it as though it described their visitors.
When the two sections disagree, nothing is broken. Lab shows a slow single load on an emulated mid-range device; field shows that most of your actual visitors are on better hardware or are hitting warm caches, or the reverse. Field data is the one that answers whether users are suffering.
Why PageSpeed Insights often shows no field data at all
This is the most common unanswered question in this subject, and the documentation answers it precisely. The Chrome UX Report has eligibility rules, and most Indian business sites fail at least one of them.
An origin or page must be publicly discoverable, using, in Google’s words, “the same indexability criteria as search engines”. A page fails if it returns a non-200 status after redirects, carries an X-Robots-Tag: noindex header or equivalent, or includes a <meta name="robots" content="noindex"> tag or equivalent.
It must also be sufficiently popular. The documentation states that “An origin is determined to be sufficiently popular if it has a minimum number of visitors across all of its pages”, and that the exact threshold is not disclosed. Pages have the same kind of minimum, which is why a site can have origin-level data and no data for an individual page. Usefully, experiences that meet the user and origin criteria but not the page criteria still count toward origin-level data, so a low-traffic page contributes to the site’s number even when it has none of its own.
And who is actually in the data
This part is rarely mentioned and it reframes everything. A user’s experience is included only if they have usage statistic reporting enabled, sync their browser history, have no Sync passphrase set, and are on a supported platform: desktop Chrome on Windows, macOS, ChromeOS or Linux, or Android Chrome including Custom Tabs and WebAPKs.
Which means Chrome on iOS contributes nothing. Android apps using WebView contribute nothing. Other Chromium browsers, Microsoft Edge among them, contribute nothing. And Google “does not publish data about the proportions of users that meet these criteria”.
So field data is a sample of consenting, signed-in, syncing Chrome users on particular platforms, not a census of your traffic. For a business with a largely iPhone audience, the field data describes a minority of visitors. That is not a reason to ignore it, because it is still real people on real devices, and it is the data Google itself uses. It is a reason to stop treating it as the whole truth, and a strong reason to run your own real user monitoring if the numbers matter commercially.
Search Console’s Core Web Vitals report
The same Chrome UX Report field data, grouped into URL groups by similarity, reported at origin and group level over a rolling window. Its value is that it covers your whole site rather than one URL, and it tells you which templates are failing rather than which page someone happened to test. Its weakness is the lag, which makes it useless for checking whether this morning’s fix worked.
Use it to decide what to work on. Do not use it to verify a deployment.
The CrUX API and BigQuery dataset
For teams that want the field data programmatically, the same dataset is available through an API for current values and through BigQuery for history, including month by month trends and distributions rather than single figures. This is where the honest reporting lives, because a distribution shows how many users are having a bad time rather than a pass or fail badge. For anyone already pulling Search Console data with the approach in how to export all your Search Console data with Python, adding the CrUX pull is a small extension and makes the monthly report honest.
WebPageTest: the tool for diagnosing, not scoring
WebPageTest runs a real browser on real hardware in a chosen location, over a chosen connection profile, as many times as you ask, and returns a waterfall, a filmstrip and connection-level detail. It is lab data, like Lighthouse, but with control that Lighthouse does not give you: test location, device, connection speed, number of runs, first view against repeat view, and scripted multi-step journeys.
This is the tool for the question “why is this slow”, and in particular for anything involving geography. A site hosted in the United States serving customers in Pune behaves differently from the same site tested from Virginia, and WebPageTest is how you see that rather than assume it. The repeat-view run is the one most people never look at, and it is what tells you whether your caching is doing anything.
Its weakness is that its numbers are not the ones anyone else quotes, so it is a diagnostic instrument rather than a reporting one.
GTmetrix and the other third party dashboards
GTmetrix and similar services run Lighthouse, or their own variant of it, from their own locations with their own defaults, and present the result with their own grading. That is why a GTmetrix grade and a PageSpeed Insights score diverge: different location, different device profile, different connection assumption, sometimes a different Lighthouse version, and a different formula on top.
They are genuinely useful for two things: scheduled monitoring with alerting over time, and a shareable report for a client who will not open DevTools. They are not useful as the authority in a disagreement, because the grade is the vendor’s own construction. Check which location and device profile the free tier is testing from, because the default is often a server in another continent on a connection no customer has, and for an Indian audience that single setting explains most of the difference from a local test.
Chrome DevTools: the Performance panel
Not a score, which is the point. A recording of what the main thread did, millisecond by millisecond, with the long tasks, the layout shifts and the script execution visible. This is where a Total Blocking Time problem becomes a named function in a named file.
Two habits make it reliable: throttle the CPU, because your development machine is not a customer’s phone, and disable extensions, because they appear in the trace. The devices most Indian visitors actually use are the subject of mobile performance on low-end Android phones, and the CPU throttling setting is how you simulate them.
Real user monitoring on your own site
The gap that none of the above fills is your own users, all of them, now. Real user monitoring collects the same metrics from every visitor in your own analytics, with no eligibility rules, no platform exclusions and no reporting lag. The web-vitals library collects the three Core Web Vitals in the browser and you send them wherever you keep data; several caching and performance plugins also collect it for you.
This is the only measurement that includes your iOS visitors, your Edge visitors and the ones who never consented to Chrome usage statistics, and it is the only one available on a site too small to be in the Chrome UX Report at all. For any site where speed affects revenue, it is worth the afternoon it takes, and it is what lets you segment by device, by city and by connection rather than arguing about an average.
The comparison
| Tool | Data type | Covers | Best for | Do not use it for |
|---|---|---|---|---|
| PageSpeed Insights | Both | One URL | A quick read on one page | Quoting the lab score as a user experience |
| Lighthouse, local or CLI | Lab | One URL | Finding what to fix, in CI | Single runs, or comparing across machines |
| Search Console Core Web Vitals | Field | Whole site, grouped | Deciding which templates to work on | Verifying today’s deployment |
| CrUX API and BigQuery | Field | Origin and eligible pages | Honest monthly reporting and trends | Sites below the popularity threshold |
| WebPageTest | Lab | One URL, chosen conditions | Diagnosis, geography, repeat view | A number to report to leadership |
| GTmetrix and similar | Lab | One URL | Scheduled monitoring, client reports | Settling a disagreement on authority |
| Chrome DevTools Performance | Lab | One session | Naming the exact slow script | Anything resembling a score |
| Your own real user monitoring | Field | Every visitor | The truth about your actual audience | Comparing yourself to competitors |
A diagnosis order that avoids the argument
- Start with field data, from Search Console or your own real user monitoring, and establish whether there is a problem at the 75th percentile. If there is not, stop.
- Identify which templates fail, not which pages, because fixes apply to templates.
- Take one failing URL into Lighthouse, run it five times in a clean profile, and take the median.
- Look at which metric is dragging the score, and remember the weights: blocking time and layout shift are more than half of it.
- Take the same URL into WebPageTest from a location your customers are actually in, and look at the waterfall and the repeat view.
- Take it into the DevTools Performance panel with CPU throttling to name the specific scripts.
- Fix, then verify in lab immediately and in field four weeks later, because field data lags.
- Report the field distribution, never the lab score.
What is a waste of effort
Chasing a lab score of 100. It is a weighted average of emulated conditions, and the last fifteen points usually cost more than they return.
Recording the Lighthouse score as a monthly KPI. The weights change between versions, so the series is not comparable with itself.
Running tests in a Chrome profile full of extensions, then arguing about the result.
Comparing your GTmetrix grade with a competitor’s PageSpeed Insights score.
Optimising a page that has no field data problem because a tool showed an orange number.
Testing from a default location on another continent when every customer is in India.
Where to go next
For the fixes rather than the measurement: performance budgets for marketing websites sets the limits worth enforcing, an audit of every third party script on the page is usually the largest single win, Core Web Vitals for WordPress without plugin overload covers the commonest platform, and mobile performance on low-end Android phones covers the devices that decide your 75th percentile.
If two tools are giving your team two answers and the argument is now a month old, get in touch.
Last verified: 2 November 2026. We review this page quarterly, and sooner when Lighthouse changes its scoring weights.
Sources. Chrome for Developers, Lighthouse overview and “Performance audit scoring”, read 2 November 2026. Chrome for Developers, “Chrome UX Report: About” and “Methodology”, read 2 November 2026. web.dev, “Web Vitals”, read 2 November 2026.