Core Web Vitals Tools: Which Ones to Trust

Core Web Vitals tools are reliable for finding causes, but not for judging whether your pages pass Google’s test. Google’s test uses field data, meaning real Chrome user measurements aggregated over a rolling 28-day window. Lab data simulates one device and network profile, so a page can score well in the lab while real visitors on a slower mobile connection have a poor experience, and the reverse can also happen. Lab tests also capture only one page load, so they cannot show how often layout shifts affect real visitors or how performance varies across sessions.

Verdict for most teams: use PageSpeed Insights for page-level field data, Search Console for site-wide patterns, and Lighthouse to diagnose causes. Trust the field numbers for pass or fail, and use the lab numbers to decide what to fix. This guide explains why, and how to apply the same logic to the core web vitals tools you already use.

Which tool should you open first?

Your situation	Open this tool first	Why
A new page with no traffic yet	Lighthouse	No field data exists, so a controlled lab run is the only option
A sudden traffic or ranking drop	Search Console Core Web Vitals report	It shows which URL groups fell into Poor or Needs improvement
A single template failing across pages	PageSpeed Insights, then Lighthouse	Field data confirms the failure, lab data isolates the cause
A fix you want to verify	Lighthouse for the test, then field data over 28 days	Lab shows the change quickly, field data confirms it reached real users, and the time it takes for field data to update is part of the wait

Key Takeaways

• Trust field data for pass or fail. Google Search uses CrUX data to inform the page experience ranking factor.
• Use lab tools to find causes. A strong Lighthouse score can sit alongside failing field metrics.
• Check INP, not FID. Google replaced First Input Delay with Interaction to Next Paint on March 12, 2024.

Why Core Web Vitals Matter and Which Tool to Trust

Core Web Vitals are standardized metrics Google uses to describe how a page feels to users, covering loading speed, responsiveness and visual stability. Google’s algorithm was updated starting in mid-June 2021 to include Core Web Vitals as a ranking factor, so choosing a tool now carries commercial weight. Because these metrics affect search visibility, teams that monitor website performance on mobile devices have a direct business reason to measure them, and the time it takes for a page to become usable is part of that measurement. Tools that track layout shifts show whether content moves unexpectedly while a page loads.

Some tools report what real visitors experienced. Others reproduce one controlled page load to find the cause. These are different jobs, and most teams need both. Confirm that any tool uses the current web vitals metric set, and that it reports time to interactive alongside the other measures. Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) on March 12, 2024, so reports built around FID now measure a metric that no longer counts.

What Core Web Vitals Measure

Three signals make up the set. Largest Contentful Paint (LCP) tracks the time it takes for the main content to appear. Interaction to Next Paint (INP) tracks how quickly the page responds to clicks, taps or typing, which shapes the user experience. Cumulative Layout Shift (CLS) tracks how much content jumps while loading, a measure of visual stability.

Google introduced these metrics in May 2020 and began using them in its page experience signals. Those signals rolled out to desktop search in early 2022. A dashboard that reports the wrong picture can send engineering time into fixes that never move the signal Google reads, so reliable core web vitals tools matter for measuring page performance and delivering a good user experience on every mobile device and across the whole website.

Field Data vs. Lab Data: The Distinction That Decides Everything

Field data and lab data answer different questions, and this is the one distinction the rest of this guide depends on. Field data is what real Chrome users experienced on your page, aggregated over a rolling 28-day window; Google assesses Core Web Vitals for ranking using this data. Lab data is a single simulated load on a controlled device and network profile, used to diagnose causes. Every section below refers back to this distinction rather than restating it.

Why lab and field results disagree

A lab score can pass while field data fails, and the reverse happens too. A lab test runs on one simulated device, so it cannot show the slow phones and congested networks that drag down real-user numbers. It also cannot capture interactions visitors trigger after load, which is where INP is measured. Lab runs and field data are both useful, but they answer different questions about the same core web vitals metrics.

Consider a team that enlarges its hero image. Lab data suggests LCP could improve by up to 50%, according to Conductor’s Core Web Vitals guide. Over 28 days, field data may show no change, because most real visitors may be on slower connections where the image is not the bottleneck. The lab gain was a hypothesis, and the field result is the verdict.

Decision criteria: which source to trust

• Trust field data for pass or fail, since it is what Google assesses.
• Use lab data for diagnosis, reproduction and before-and-after testing.
• Check sample size first. Low-traffic pages often have no field data.
• Confirm every lab gain in field data before reporting it as a result.
• Track performance metrics across both sources, including the vitals that matter most for each page’s content.

What the CrUX report captures and how often it updates

The Chrome User Experience Report (CrUX) records real-user measurements from opted-in Chrome visitors. It groups results by origin, or by URL where there is enough traffic. Because CrUX uses a 28-day rolling window, a fix deployed today takes weeks to show fully, so do not judge a change in its first few days.

When lab data is the right tool and where it misleads

Lab data is the right tool to debug, compare two page versions, or check a fix before release. It is also the only option for pages with no field data yet, such as a new landing page. It misleads when treated as a score of real experience: a Lighthouse score reflects one device and one network profile, and cannot show how a visitor on a mid-range Android phone over a crowded network experienced your page.

The Three Core Web Vitals and Their Thresholds

Each Core Web Vital has a “good” threshold. Knowing what each metric measures tells you which number to act on. A lab score can improve while field data stays flat, so always check which view a tool is showing. Targeting a good user experience means watching field data, not just lab scores.

Largest Contentful Paint (LCP)

LCP measures the time in seconds from when the page starts loading to when the largest text block or image in the visible area is rendered. A good LCP is 2.5 seconds or less at the 75th percentile of field visits.

Common causes of a slow LCP include an unoptimized hero image, slow server response, render-blocking CSS and JavaScript, and web fonts that delay text. Compressing and correctly sizing the hero image, serving it in a modern format, and preloading it are usually the first fixes.

Interaction to Next Paint (INP)

INP measures the delay in milliseconds between a user interaction, such as a click, tap or key press, and the next visual update. NitroPack’s Core Web Vitals overview notes that Google officially replaced FID with INP on March 12, 2024. A good INP is under 200 milliseconds for 75% of recorded page loads.

FID measured only the first input. INP considers interactions across the whole visit and reports a value close to the worst one, which makes it harder to pass. Long main-thread tasks cause the delay: while the browser runs a long piece of JavaScript, it cannot respond to input or paint the next frame. Heavy JavaScript and long tasks are the usual causes of a poor score, and a slow website on a mobile device often shows this problem most clearly.

Cumulative Layout Shift (CLS)

CLS measures how much visible content moves unexpectedly while the page loads. It is a unitless score. Google made CLS more neutral to time on page in early 2021, so a long-lived page is no longer penalized simply for staying open longer.

The typical causes are images and videos without set dimensions, and ads, embeds and iframes that load late and push content down. Reserving space for media and setting width and height attributes are the standard fixes.

The 75th percentile benchmark explained

Field data is judged on the 75th percentile, not the average visit. A page passes a metric when 75% of its recorded page loads fall within the good threshold. A fast average can still fail if one visit in four is slow.

Tools usually show headline metrics and supporting diagnostics. The headline three (LCP, INP and CLS) are the ones Google assesses. The supporting metrics, such as time to interactive, help explain why a page is slow, so treat them as clues rather than verdicts. Together these vitals metrics give a fuller picture of overall performance than any single web vitals score. Thresholds and scoring weights can change, so check them against Google’s current documentation before you set targets.

Diagnostic Metrics: TBT, FCP, Speed Index, TTI and FID

Supporting metrics diagnose causes. They do not score user experience. A website can show a poor First Contentful Paint and still pass the field thresholds for every Core Web Vital, and the reverse is also true. When a Core Web Vital fails, these metrics show where to look: blocking scripts, slow server responses, or content that appears late. Core web vitals tools report them alongside field data, and the performance section of each report is the place to start. A site that delivers a good user experience usually shows these diagnostics trending in the right direction, but a single good number does not prove that.

Total Blocking Time (TBT) as the lab stand-in for INP

Interaction to Next Paint (INP) is a field metric that needs real users, so a lab tool cannot measure it directly. Total Blocking Time (TBT) is the lab proxy. It adds up the time the main thread (the browser’s single queue for running page code) is blocked long enough to stop the page responding to input.

A high TBT usually means heavy JavaScript is occupying the browser. That is the most common reason INP fails in the field. INP picks its reported value from the whole visit, using the slowest typical interaction, so one long task can drag the performance score down.

Use TBT to find the problem, then confirm the fix against INP in field data. A drop in TBT is a hypothesis, not proof that INP has improved.

FCP, Speed Index and TTI: what each one diagnoses

• First Contentful Paint (FCP) records when the first piece of content appears. A slow FCP points to render-blocking resources (files that hold up the page from displaying) or slow server response.
• Speed Index (SI) estimates how quickly the visible area fills in over time, useful when a page looks finished early but still feels slow.
• Time to Interactive (TTI) marks when the page is reliably responsive, useful for spotting scripts that delay interactivity.

None of these three appears in the Core Web Vitals assessment, so none should decide whether a website is healthy.

First Input Delay (FID): retired metric, still in old reports

First Input Delay (FID) measured the delay before the browser processed a user’s first interaction. Google replaced it with INP on March 12, 2024, and Chrome set September 9, 2024 as the transition deadline. Any report or dashboard still tracking FID uses a metric that no longer counts.

Discontinue reporting FID. Relabel or remove any legacy column, and track the INP figure at the 75th percentile instead.

The Tools Compared: Which Ones to Trust and When

Most Core Web Vitals tools fall into two groups. Field tools report real-user data, the measurements Google uses when it assesses a page. Lab tools run a simulated test on one device and one network profile.

Both are useful, but they answer different questions. Start with field tools to confirm status, then use lab tools to find causes. Lab tools are for diagnosis, not for declaring success.

Tool	Data type	What it reports	Cost	Best use
PageSpeed Insights	Both	CrUX field data plus a Lighthouse lab run	Free	Quick page-level check of field status
CrUX dashboard	Field	Real-user LCP, INP and CLS trends by origin	Free	Confirming fixes reached real visitors
Search Console Core Web Vitals report	Field	URL groups rated good, needs improvement or poor	Free	Finding templates that fail
Lighthouse	Lab	Simulated scores, opportunities and diagnostics	Free	Reproducing a problem in a controlled run
Chrome DevTools performance panel	Lab	Frame-by-frame traces of a specific interaction	Free	Debugging a slow click, tap or layout shift
Third-party RUM platforms	Field	Continuous real-user monitoring, custom segments	Paid	Ongoing monitoring across many pages and devices

PageSpeed Insights: field and lab data in one view

PageSpeed Insights is the fastest starting point because it shows both data types on one screen. The top section reports field data from the Chrome User Experience Report, which covers real Chrome users over a rolling 28-day window. Because the window is rolling, a fix can take several weeks to appear in this section.

Check that section first. If a page has no field data, you have no evidence of how real visitors experience it. The lab section below it is for diagnosis.

Google Search Console’s Core Web Vitals report for site-wide patterns

The Search Console Core Web Vitals report groups URLs by template and rates each group good, needs improvement or poor, using field data. It is the best tool for spotting that a whole product template fails rather than one page. Low-traffic pages may not appear at all. Checking the same template on each website in a portfolio shows whether a fault is isolated or shared.

Lighthouse and the performance score

Lighthouse is a lab tool. It loads a page under simulated throttling (artificially slowed network and processing) and produces a weighted performance score. A high score does not prove a passing field experience. Use Lighthouse to reproduce a problem, then confirm the fix in field data.

Chrome DevTools for debugging specific interactions

The DevTools performance panel records what the browser does during a load or interaction. It is the right tool for finding why a particular click or tap is slow, because it exposes the long tasks behind an INP problem. It is a debugging instrument, not a scoring one.

Third-party real-user monitoring: when it is worth the cost

Paid real-user monitoring (RUM) platforms collect field data continuously and let you segment by device, country, template and campaign. They earn their cost when you manage many pages, need regression alerts, or must show stakeholders trends over time. For a single small site, the free CrUX data and Search Console report usually suffice. The seo tools for small businesses guide covers budget options.

Trust criteria applied to every tool

• Official source: Google-run tools define the metrics, so their thresholds are authoritative.
• Data provenance: know whether a number is field or lab before acting on it.
• Metric currency: confirm the tool reports INP, not FID.
• Reproducibility: lab results vary between runs, so repeat tests before trusting one figure.

How to Read a Lighthouse Score Without Being Misled

Lighthouse is the number most teams open first, and it is often misread. It is a controlled experiment: one simulated device, one simulated network, one page load. That is useful for finding problems, but it is not a verdict on real visitor experience on the mobile web or on any given website. Lighthouse flags issues such as layout shifts, but a clean lab run does not guarantee good performance for every visitor. The web vitals guidance explains what the field metrics measure, and it defines the vitals metrics that matter most for real users.

How the Lighthouse performance score is calculated

Lighthouse combines several lab metrics into one weighted number from 0 to 100. Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, First Contentful Paint and Speed Index each contribute a share of the total. The weights can change between Lighthouse versions, so check the current weighting in Google’s documentation before comparing scores across releases.

The blend hides causes. A page can lose most of its points to one slow metric, such as a large hero image delaying largest contentful paint, while the others look healthy. Two rules follow:

• Treat 90 as a goal, not a certificate. Lighthouse’s own colour coding marks 90 to 100 green, 50 to 89 orange and below 50 red.
• Read the sub-metrics, not just the headline. The headline shows that something is slow. The sub-metrics show what. Check each value against its own threshold in the audit list.

Why a passing score can still fail Core Web Vitals in the field

Lighthouse runs one load on one profile. Google’s assessment uses field data from real Chrome users, aggregated over a rolling 28-day window and reported at the 75th percentile. A page passes only when at least 75% of its real visits meet the threshold for each metric.

A lab test can score 95 while many real visitors on slower phones get a poor INP or LCP. The reverse also happens: a page can score 60 in Lighthouse yet pass field data because its real audience is on fast devices.

Question	Answer source
Is there a problem, and what causes it?	Lighthouse and DevTools
Do real users pass the threshold?	Field data in PageSpeed Insights or the CrUX report
Did my fix work for real visitors?	Field data after the 28-day window closes

Getting stable results from repeated runs

Scores move between runs even on an unchanged page, because server response times and network conditions vary. To avoid chasing noise:

1. Run Lighthouse at least three times and compare the median, not the best result.
2. Test in an incognito window with extensions disabled, since extensions distort the numbers.
3. Keep device emulation and throttling settings identical across comparisons.
4. Change one thing at a time so any movement traces to a single cause.

Treat a difference of a few points as noise. A consistent shift across several runs is worth acting on.

Conclusion: Trust the Field, Diagnose in the Lab

Trust field data for the verdict, lab data for diagnosis, and Google’s own tools as your baseline. A lab score shows a simulated visit, not whether the page passes. When a green lab score sits beside a failing field LCP, act on the field metric.

Enlarging a hero image can improve lab LCP by up to 50%, according to Conductor’s Core Web Vitals guide, but that gain only counts if the Chrome User Experience Report shows it for real visitors across your site, on desktop and mobile alike.

Confirm field status in Google Search Console, reproduce issues in Lighthouse, diagnose with DevTools, then retest. Measure INP, not FID, since Google replaced FID with INP on March 12, 2024, and treat any performance gain as content that has to hold up for real users.

Frequently Asked Questions

Which Core Web Vitals tool is the most accurate?

For ranking, field data from the Chrome User Experience Report (CrUX) is the most accurate source, because Google Search uses it to inform the page experience ranking factor. Lab tools such as Lighthouse are better for finding the cause of a performance problem. Treat a lab score as a hypothesis until field data confirms it.

Why does PageSpeed Insights show different scores on each run?

Lab tests simulate one device, network speed and CPU profile, so small differences in server response and background processes change the result. Run the test several times and compare the median. Field data avoids this because it aggregates real visits over 28 days, which shows how real users experienced your website rather than one simulated load.

Is First Input Delay still a Core Web Vital?

No. Google officially replaced First Input Delay (FID) with Interaction to Next Paint (INP) on March 12, 2024. Older guides and reports may still show FID, so confirm that a report measures INP before acting on it, and drop FID from new dashboards.

What is a good INP score?

A good INP is under 200 milliseconds at the 75th percentile, meaning 75% of page loads fall below that value. Measure it in field data, since lab tools only approximate it. Validate any lab gain against field data before treating a fix as confirmed.

Do I need a paid tool to track Core Web Vitals?

No. Google Search Console, PageSpeed Insights, the CrUX dashboard and Lighthouse are free and cover most needs for a small website. A paid real-user monitoring platform is worth the cost when you need alerts, per-page history across many URLs, or data for pages too low-traffic to appear in CrUX.