Core Web Vitals checkers compared: what each one measures

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.

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:

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:

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.