Reading Core Web Vitals Without Chasing the Wrong Number
Enter a URL and this runs a real Lighthouse audit through Google's own PageSpeed Insights API, returning the four category scores, the lab metrics behind them, and — where Google has enough real-user data for the page — what actual Chrome visitors experienced.
Every figure comes from Google. Nothing here is estimated locally, and when the API fails the tool says so rather than producing a plausible-looking score. That is worth stating because a performance number nobody can trace is worse than no number at all.
At a glance
- Field data is what Core Web Vitals is assessed on. Lab data is a diagnostic, not the grade.
- The three vitals are LCP, INP and CLS. FID was retired in March 2024.
- Field data is missing for low-traffic pages. That is normal and not a fault.
- A perfect Lighthouse score does not mean you pass Core Web Vitals.
How to Use This Tool
Enter the URL
Any public page. Google loads and renders it on its own infrastructure, which genuinely takes 10 to 30 seconds — a faster answer would mean it had not really been measured.
Choose mobile or desktop
Mobile is the default and usually the one that matters, because Google assesses Core Web Vitals on mobile for most sites and the throttled mobile profile is far harsher.
Look at field data first
If it is there, it is the number that counts. Lab metrics tell you what to fix; field data tells you whether you have a problem.
Work the opportunities in order
They are sorted by estimated saving. The first two usually account for most of the available gain, and the rest have sharply diminishing returns.
Lab Data and Field Data Are Not the Same Thing
This distinction decides whether you are optimising something real, and most performance advice glosses over it.
Lab data is one simulated load on Google's hardware, on a throttled connection, with no cache and no extensions. It is reproducible, which makes it excellent for comparing a change against the version before it. It is also a single sample under artificial conditions, and it is not what anyone experienced.
Field data comes from the Chrome User Experience Report — anonymised measurements from real Chrome users who actually visited your page over the previous 28 days, on their own devices and connections. It is the 75th percentile, so it describes the experience of your slower quarter rather than your average visitor.
Core Web Vitals as a ranking signal is assessed on field data. The lab score is a diagnostic that tells you what to change; it is not the thing being graded.
This is why a page can score 100 in the lab and still fail Core Web Vitals. Google's test machine is fast and unencumbered. Your visitors are on mid-range phones, on mobile networks, with ad blockers and extensions and a cold cache.
The Three Metrics
INP replaced First Input Delay in March 2024. If you are working from older guidance that mentions FID, it is out of date — FID only measured the delay before processing began on the first interaction, which turned out to be easy to score well on while still feeling sluggish. INP measures the full time until the screen actually updates, on every interaction.
- LCP — Largest Contentful Paint. How long until the biggest thing above the fold has rendered, usually a hero image or heading. Good is under 2.5 seconds. Slow server response and unoptimised images are the two usual causes.
- INP — Interaction to Next Paint. How long the page takes to visibly respond after someone taps or clicks, measured across the whole visit rather than just the first interaction. Good is under 200ms. Heavy JavaScript blocking the main thread is almost always the cause.
- CLS — Cumulative Layout Shift. How much content jumps around while loading. Good is under 0.1. Images without dimensions, ads and embeds inserted into the flow, and fonts swapping late are the usual sources.
Why Field Data Is Often Missing
A page needs enough real Chrome visitors before Google will report field data for it, because reporting on too few would risk identifying individuals. New pages, low-traffic pages and most pages on small sites simply do not have it.
This is not a fault and nothing is broken. When it happens, Google may still show origin-level data — the aggregate across your whole domain — which is useful context even though it does not describe this particular page.
With no field data, the lab metrics are what you have. They are still worth acting on, since the causes they identify are real; you just cannot confirm the improvement showed up for real users until enough of them arrive.
How Much Core Web Vitals Actually Affects Rankings
Less than the amount of attention it receives. Google has been consistent that page experience is a light signal, and that it acts mainly as a tiebreaker between pages that are otherwise comparable in relevance.
A fast page about the wrong thing will not outrank a slow page that answers the query. If your content does not match intent, performance work will not rescue it, and this is the single most common way effort gets misdirected.
Where it does pay reliably is conversion. Slow pages get abandoned, and the abandonment happens before anyone reads anything. That effect is direct, measurable in your own analytics, and does not depend on any ranking mechanism.
So the honest framing: fix Core Web Vitals because leaving is what people do to slow pages, not because it will move you up the results. The ranking benefit is real and small; the abandonment cost is real and large.
What Usually Fixes These
- For LCP: serve the hero image in a modern format at the right size, preload it, and stop server response times drifting. A slow time to first byte puts a floor under LCP that no front-end work can get past.
- For INP: reduce and defer JavaScript. Long tasks on the main thread are what stops the page responding, and third-party scripts are usually the largest contributor.
- For CLS: set explicit width and height on every image, reserve space for ads and embeds before they load, and use font-display so text does not reflow when the real font arrives.
- Across all three: fewer third-party scripts. Analytics, chat widgets, tag managers and ad scripts are frequently the difference between passing and failing, and each one is easier to remove than to optimise.
About the API Key
This tool calls Google's PageSpeed Insights API, which is free. Requests made without an API key share a single quota across everyone using it that way, and in practice that quota is exhausted almost all the time.
If the tool reports a quota error, that is what has happened — the site owner has not configured a key. A key is free, requires no billing, and takes a few minutes: create a project in Google Cloud Console, enable the PageSpeed Insights API, and generate one under Credentials.
The page says which situation you are in before you run anything, rather than letting you discover it through a failure.
Where This Fits
Performance is one input among several, and it is worth checking the others on the same page rather than optimising a fast page nobody can find. Our SEO Analyzer covers the on-page fundamentals, and the HTTP Header Checker shows the caching directives that affect repeat visits — a page with no cache headers re-downloads everything on every visit.
The Image Alt Text Auditor is worth a run too. It is an accessibility tool rather than a performance one, but accessibility is one of the four scores here, and missing alt text is the most common thing dragging that number down.
Frequently Asked Questions
What is the difference between lab data and field data?
Lab data is one simulated load on Google's hardware under throttled conditions — reproducible and good for comparing changes. Field data is anonymised measurement from real Chrome users over the last 28 days. Core Web Vitals is assessed on field data; lab data is a diagnostic.
Why is there no field data for my page?
Google needs enough real Chrome visitors before it will report on a URL, so that individuals cannot be identified. New and low-traffic pages usually have none. It is not a fault, and the lab metrics still show you what to fix.
What happened to FID?
First Input Delay was retired in March 2024 and replaced by INP. FID only measured the delay before processing started on the first interaction, which was easy to score well on while the page still felt slow. INP measures the full time until the screen updates, across every interaction.
What are the thresholds for good Core Web Vitals?
LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1 — each measured at the 75th percentile of real visits, so the slower quarter of your visitors has to clear them too.
Do Core Web Vitals affect rankings?
Yes, but lightly. Google treats page experience as a tiebreaker between comparably relevant pages rather than a major factor. A fast page about the wrong subject will not outrank a slow page that answers the query. The stronger reason to fix them is that people abandon slow pages.
Why does the score change between runs?
Lab tests vary — network conditions, server load and which resources happen to be cached all move the number. Swings of a few points between identical runs are normal, which is why a single run is a weak basis for a decision.
Why does the audit take so long?
Google is loading and rendering the page on its own infrastructure, throttled to simulate a mid-range phone. Ten to thirty seconds is normal. Anything much faster would mean the page had not really been measured.
Why do I get a quota error?
Google's shared quota for requests made without an API key is small and usually exhausted. The fix is a free PageSpeed Insights API key, which needs no billing. This page tells you whether one is configured before you run an audit.
Related Tools
HTTP Header Checker
Check the caching headers that decide how fast a repeat visit is.
Advanced On-Page SEO Analyzer
Cover the on-page fundamentals alongside performance.
Image Alt Text Auditor
Fix the most common cause of a low accessibility score.
Redirect Chain Checker
Find redirect hops that add a round trip before the page even starts loading.