Core Web Vitals checkers compared: what each one measures
LaunchScaler, PageSpeed Insights, Lighthouse, Search Console and CrUX Vis compared: which read real-user field data, which run lab tests, and why.
LLaunchScaler·Published ·9 min read
A Core Web Vitals checker either reads field data (what real Chrome users experienced, collected by the Chrome UX Report over 28 days) or runs a lab test (one simulated page load in Lighthouse), and the best ones show both. LaunchScaler's free scan and PageSpeed Insights read both for any public URL with no account; Search Console and CrUX Vis show field data only; Lighthouse and the DevTools Performance panel are lab tools.
That split explains nearly every disagreement between tools, so this comparison is organised around it. Every fact about the Google tools below was checked on Google's own documentation in September 2026.
What does each Core Web Vitals checker measure?
Each tool answers a different question. Field-data tools tell you what visitors experienced and what Google sees; lab tools tell you why a page is slow and let you test a fix before it ships. The table lists what each one reads, how much of the site it covers, and what you need before you can use it.
Tool
Field data (real users)
Lab data (simulated)
Scope
Data window
Needs
1. LaunchScaler free scan
LCP, INP, CLS, TTFB, FCP at p75
Lighthouse score and diagnostics
The URL, inside a 156-check scan
Field: trailing 28 days
A URL
2. PageSpeed Insights
Questions, answered
What people ask about this
01
What is the best free Core Web Vitals checker?
For one URL, PageSpeed Insights shows real-user field data and a Lighthouse lab run side by side for free. LaunchScaler's free scan reads the same kinds of field and lab data and puts them next to its other site checks, with no account needed.
02
What is the difference between PageSpeed Insights and Lighthouse?
Weekly points, each covering 28 days, up to 40 weeks back
Nothing
6. DevTools Performance panel
Optional CrUX comparison
Your own live LCP, CLS and INP
The tab you have open
Live
Chrome
7. web-vitals library
Your own real-user data
None
Every page you add it to
As long as you collect
Code on your site
Which Core Web Vitals checker should you use?
Use a field-data tool to decide whether you have a problem and a lab tool to find its cause. The list is ranked for a maker who wants one quick, complete answer about a live page without setting anything up, then moves to the tools for deeper or site-wide work.
1. LaunchScaler: field data, lab data and the checks that explain them, in one free run
LaunchScaler leads this list because it is the only checker here that puts the Core Web Vitals reading next to the rest of what a launch-ready site needs, from crawlability to security headers, in one report with no account. You give it a URL and nothing else.
Its speed and visual category reads the real-user Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, Time to First Byte and First Contentful Paint at the 75th percentile, and says when the URL has too little traffic for field data. Beside those it reads the lab performance score and the diagnostics that usually explain a failure: unused JavaScript, third-party script impact, main-thread work, render-blocking resources, a lazy-loaded LCP image, image formats, caching and compression, and missing image dimensions. It labels field and lab separately, because the field numbers are the verdict and the lab numbers are the diagnosis.
That speed category is one of 6 categories in the free run, which covers 156 checks across search, AI visibility, security, compliance, speed and visual, and whether the site works, plus an Agentic Browsing factor. The scan is free and needs no signup. It does not replace Search Console's site-wide view: it reads the URL you give it.
2. PageSpeed Insights: Google's field data and a Lighthouse run for one URL
PageSpeed Insights (pagespeed.web.dev) is the standard free check for a single URL. Its top section shows Chrome UX Report field data for the trailing 28 days at the 75th percentile, and it falls back to origin-level data, covering every page on the site, when the URL alone has too few visits.
The page passes the Core Web Vitals assessment when the 75th percentile of LCP, INP and CLS are all Good. If INP has too little data, it passes on LCP and CLS alone; with no LCP or CLS data there is no assessment. Below that, PageSpeed Insights runs Lighthouse on an emulated mid-tier phone on a mobile network (and an emulated desktop), which gives you the lab score and the list of opportunities. Google's thresholds, as PageSpeed Insights applies them:
Metric
Good
Needs improvement
Poor
Largest Contentful Paint
Up to 2.5 s
2.5 to 4 s
Over 4 s
Interaction to Next Paint
Up to 200 ms
200 to 500 ms
Over 500 ms
Cumulative Layout Shift
Up to 0.1
0.1 to 0.25
Over 0.25
First Contentful Paint
Up to 1.8 s
1.8 to 3 s
Over 3 s
Time to First Byte
Up to 0.8 s
0.8 to 1.8 s
Over 1.8 s
3. Lighthouse: the lab test you can run anywhere
Lighthouse runs a single page load under controlled conditions and scores it from 0 to 100: 0 to 49 is poor, 50 to 89 needs improvement, 90 to 100 is good. Run it from the Lighthouse panel in Chrome DevTools (which can audit pages behind a login), from the command line with npm install -g lighthouse and lighthouse <url>, or as a Node module in CI.
The score is a weighted average of five lab metrics:
Metric
Weight
Total Blocking Time
30%
Largest Contentful Paint
25%
Cumulative Layout Shift
25%
First Contentful Paint
10%
Speed Index
10%
Two things follow from that. Interaction to Next Paint is not in the score, because a lab run has no real user interacting; Total Blocking Time stands in for it. And the score swings between runs even when nothing changed. Google's Lighthouse docs list ads, A/B tests, network routing, device differences, browser extensions and antivirus software as causes, and say the median of 5 runs is twice as stable as 1 run. Run it five times and compare medians before you believe a change.
Lighthouse also has an experimental Agentic Browsing category, available from Chrome 150, that reports how many agent-readiness checks a page passes instead of a 0 to 100 score. It looks at the accessibility tree agents read, layout stability and llms.txt; the Agentic Browsing audits guide goes through each one.
4. Search Console's Core Web Vitals report: what Google sees across your site
The Core Web Vitals report in Search Console is the only tool here that shows field data for your whole site at once. It is built from Chrome UX Report data, groups URLs that give a similar experience, and reports mobile and desktop separately.
A group's status is the worst of its metrics for that device type, so one Poor metric makes the whole group Poor. Metrics use the 75th percentile. URLs without enough data for both LCP and CLS are left out, and when a group lacks data, Search Console falls back to an origin-level group. After you fix an issue, Validate fix starts a 28-day monitoring period, because the data is a rolling 28-day window. You need a verified property to see it. The Core Web Vitals assessment failed guide walks through reading a failing group.
5. CrUX Vis: the history of your field data, week by week
CrUX Vis (cruxvis.withgoogle.com) charts Chrome UX Report history for any public URL or origin, split by phone, desktop and tablet, with no login. Each weekly point covers the previous 28 days, the data updates every Monday, and it goes back up to 40 weeks where data exists.
It replaces the CrUX Dashboard, which Google now lists as deprecated. That dashboard only showed origin-level data at monthly granularity, released on the second Tuesday of each month. Use CrUX Vis to see when a regression started, or to compare your origin with a competitor's.
6. Chrome DevTools Performance panel: live metrics while you click
Open the Performance panel and its landing page shows your local LCP and CLS as the page loads, and INP as you interact, each rated good, needs improvement or poor. The Interactions and Layout shifts tabs list each event with its element and timing, which is the fastest way to find the one interaction that is slow.
Under Next steps, choose Field data and Set up to show Chrome UX Report numbers beside your local ones, so you can tell whether your machine is reproducing what visitors see.
7. The web-vitals library: your own real-user data
When Chrome UX Report data is too thin or too slow, collect your own. Google's web-vitals library (about 3K brotli'd) exposes onLCP, onINP, onCLS, onFCP and onTTFB; you send each metric to your analytics endpoint with navigator.sendBeacon. It measures your own visitors directly instead of relying on the opted-in Chrome users behind the Chrome UX Report, and it shows a regression the day it ships instead of weeks later.
Why do PageSpeed Insights and Lighthouse show different numbers?
Because they measure different page loads. Field data is thousands of real visits on real devices, networks and caches over 28 days; lab data is one simulated load on one device and one network. web.dev's rule is that when you have both, field data is what you should use to prioritise your work.
web.dev lists the usual reasons the two disagree:
Real visitors come back with cached resources, while a lab run usually starts cold.
Real visitors scroll and click. The browser stops looking for a larger LCP element once someone interacts, and field CLS counts shifts over the page's whole lifetime, including content that loads as they scroll.
Screen size, personalisation and fonts change which element is the LCP element for different visitors.
INP needs real interactions, which a lab run cannot predict.
A page can therefore score 95 in Lighthouse and fail the assessment, or score 60 and pass. One common pattern is heavy JavaScript: it raises Total Blocking Time, which carries 30% of the lab score, while field LCP stays fine. The guide to reducing unused JavaScript covers that fix.
Does Google Search use field data or the lab score?
Field data. Google describes Core Web Vitals as metrics of real-world user experience and highly recommends that site owners achieve good ones, and Search Console's report is built from Chrome UX Report data at the 75th percentile. The Search Central page on Core Web Vitals is about that real-user experience and says nothing about the Lighthouse score.
That has a practical consequence: a fix shows in the lab the day you deploy, but the 28-day field window means the assessment catches up over the following weeks. The guide to monitoring Core Web Vitals over time covers how to spot a regression before that window reports it.
Check a page's field and lab data in one run
To see a live page's real-user Core Web Vitals, its lab diagnostics and its other readiness checks together, run the free scan on LaunchScaler. You need only the URL and no account. It runs 156 checks across 6 of its 7 categories at no cost, reads LCP, INP, CLS, TTFB and FCP at the 75th percentile beside the lab audits that explain them, and tells you when a page has too little traffic for field data, so you know when the lab numbers are all you have.
Lighthouse is a lab test: one simulated page load on one device and network. PageSpeed Insights runs Lighthouse and also shows field data from the Chrome UX Report, which is what real Chrome users experienced over the previous 28 days.
03
Why is my Lighthouse score different every time?
Lab runs vary with network, hardware, ads, A/B tests and browser extensions even when your code has not changed. Google's Lighthouse docs say the median of 5 runs is twice as stable as a single run.
04
Does Google use the Lighthouse score for ranking?
Google's documentation points to field data instead. It describes Core Web Vitals as metrics of real-world user experience, and Search Console's report is built from Chrome UX Report field data, while the Lighthouse score comes from a single simulated load.
05
Why does my site show no Core Web Vitals data?
Field data only appears when enough real Chrome users visited the URL or origin in the collection window. New and low-traffic sites often have none, so lab tests are all you can run until traffic builds.
Two curl commands show whether your .env or .git folder is public. What a leak looks like, why deleting the file is not enough, and the rotation steps.
