Core Web Vitals check
See how fast and stable a site really is for Chrome users: loading (LCP), responsiveness (INP) and visual stability (CLS) over the last 28 days, from Google’s Chrome UX Report.
By using these tools you accept the Terms and the Privacy page.
How the Core Web Vitals check works
The Core Web Vitals check reads Google’s Chrome UX Report, the public dataset of how real Chrome users experience websites. Use it to see whether a site passes Google’s Core Web Vitals, which metric holds it back, and whether phones fare worse than desktops.
The three Core Web Vitals
Two more metrics are shown for context but don’t count toward the assessment: First Contentful Paint (when anything at all shows; good is 1.8 s or less) and Time to First Byte (how long the server and network take to start sending the page; good is 800 ms or less). Every number is the 75th percentile: three in four visits were at least that fast.
- Largest Contentful Paint (LCP): how long until the main content, the largest image or text block, shows. Good is 2.5 s or less, poor is over 4 s.
- Interaction to Next Paint (INP): how long the page takes to react visibly to taps, clicks and key presses. Good is 200 ms or less, poor is over 500 ms.
- Cumulative Layout Shift (CLS): how much the content jumps around while people read it. Good is 0.1 or less, poor is over 0.25.
How your input is checked
A domain is looked up as its https origin, for example https://example.com. If Google has no data under that name, the www or non-www spelling is tried next, because many sites redirect one to the other and Chrome records the address people end up on. Paste an email address and its domain is checked.
A full link to a page checks that page. Its query string and fragment are removed first: Google keys pages without them, and they can carry tokens. If Google has no data for the page, the result shows the whole site’s numbers and says so. Only http and https links are accepted; internal and reserved addresses are refused.
Reading the result
Passes (green) means all three Core Web Vitals are in the good range for all devices combined. Needs improvement (amber) means the site doesn’t pass but no metric is poor. Fails (red) means at least one metric is poor. Not enough data means LCP or CLS is missing, and No field data means Google’s dataset doesn’t include the site.
Findings list each metric with its share of good, needs-improvement and poor visits, then any device that fares differently: Google Search assesses phones and desktops separately, so a site can pass overall and still fail on phones. The table shows every metric for all devices, phones and desktops side by side. The trend compares the first and the latest of Google’s weekly snapshots (each a 28-day window, up to about six months back) and adds a finding when a metric moved into a different range. Copy report gives a plain-text summary ready to paste into a ticket.
Limits, and what to check next
Only Chrome users who share usage statistics and sync their browsing history are counted, on Chrome for desktop and Android; Chrome on iPhone, Safari, Firefox and Edge visits aren’t in the data. Fresh lookups stop at a daily limit, and Google allows this site 150 lookups a minute in total, so a very busy minute can ask you to try again.
To find out why a page is slow, run a lab test such as Google PageSpeed Insights on it. The tech stack detector shows what the site runs on, and the redirect trace shows redirects that delay every visit.
Updated · Maintained by Liviu Tanase
Questions
What does this check?
It asks Google’s Chrome UX Report (CrUX) for the numbers real Chrome users recorded on the site over the last 28 days: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability), plus First Contentful Paint and Time to First Byte. It shows the 75th percentile for all devices, phones and desktops, and Google’s pass or fail assessment. The check never opens the site.
How is the pass or fail decided?
With Google’s own rule, as PageSpeed Insights applies it: a site passes when the 75th percentile of LCP is 2.5 s or less, INP 200 ms or less and CLS 0.1 or less. When there isn’t enough interaction data for INP, it passes on LCP and CLS alone. Without LCP or CLS data it can’t be assessed.
Why does it say there’s no data for my site?
The Chrome UX Report only covers sites and pages that search engines can find and that get enough visits from Chrome users who share usage statistics; Google doesn’t publish the minimum. Small, new or private sites aren’t in it. That isn’t a bad sign. A lab test such as Google PageSpeed Insights can still measure the page.
How is this different from PageSpeed Insights or Lighthouse?
Lighthouse runs one test in a lab on one simulated device. This check shows field data: what real visitors experienced across all their devices and networks over 28 days. Field data is what Google’s page-experience signals use; lab data is better for finding the cause.
How fresh is the result?
Google updates the 28-day data once a day and the weekly history once a week, and its data runs about two days behind. Answers are kept here for 12 hours, and “Check again” reuses a kept answer, so a fix shows up gradually over the next four weeks as old visits drop out of the window.
Who sees what I check?
The domain, or the page address without its query string, is sent from our server to Google. Your IP address isn’t sent and the API key stays on our server. Answers are kept for 12 hours. Cloudflare’s request logs record the request, as the privacy page explains.