Core Web Vitals checker. Paste your LCP, INP and CLS from the field data section of PageSpeed Insights. This grades them and names the fixes. It does not crawl your site.
This tool does not crawl or measure your site. It cannot: field data comes from real visitors on real devices, and no page can collect that for a domain it does not run on. Get your numbers from PageSpeed Insights, the Chrome User Experience Report, Search Console, or your own real-user monitoring, then grade them here. Nothing you type is sent anywhere.
In short
What are the Core Web Vitals thresholds?
A page passes when, at the 75th percentile of real visits, Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less. Anything up to 4 seconds, 500 milliseconds and 0.25 is needs improvement. Above that is poor.
Compared
The three metrics, plainly. Each one measures a different kind of bad experience: waiting, tapping and nothing happening, and the page moving under your thumb.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Time until the largest visible element has rendered | 2.5s or less | 2.5s to 4.0s | Over 4.0s |
| INP | How long the page takes to visibly respond to an interaction | 200ms or less | 200ms to 500ms | Over 500ms |
| CLS | How much visible content moves unexpectedly during load | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
INP replaced First Input Delay as a Core Web Vital in March 2024. FID only measured the delay before the browser started handling the first interaction, which nearly every site passed; INP measures the full round trip to the next paint, for every interaction, which is what a visitor actually feels.
How it works
Getting numbers worth grading.
- 1
Open PageSpeed Insights
Enter the URL of a page that gets real traffic. Not your staging site, and not a page nobody visits, because field data needs visitors to exist.
- 2
Read the field data, not the lab score
The top section, labelled as real-user data over the last 28 days, is what counts. The Lighthouse score below it is a simulation and does not include INP.
- 3
Check mobile and desktop separately
They are assessed separately and usually differ a lot. If only one is failing, that is where the work is.
- 4
Grade and fix the worst one
Paste the numbers above. Fix one metric at a time: the causes barely overlap, and changes aimed at LCP rarely help INP.
One reading is a snapshot.
PageSpeed Insights tells you where a page stood over the last 28 days. It does not tell you that INP got worse the day you added a chat widget, or that LCP is fine everywhere except one template.
mrkr collects Core Web Vitals from your real visitors as part of ordinary analytics, so the numbers sit next to the traffic that experienced them. That is the version you can act on: this page, on mobile, from this country, got slower on Tuesday.
Things that quietly wreck your vitals.
Lazy-loading the hero image
loading="lazy" on the largest above-the-fold image delays the exact element LCP measures.
The cookie banner
Early JavaScript that blocks the main thread and then inserts a large element. It hurts all three at once.
Third-party tags
Chat widgets, heatmaps and tag managers compete for the thread your interactions need.
Fonts that swap late
A font arriving after first paint reflows every line. Preload it and match the fallback metrics.
Slots with no reserved height
A zero-height ad or embed that expands shifts everything below it. Reserve the space in CSS.
Measuring only your own machine
Your laptop is not the 75th percentile. The failures are mid-range Android on mobile networks.
Live demo
Vitals next to the traffic that felt them. The mrkr demo is a fully populated dashboard on real demo traffic, including per-page performance. No signup, no card, cookieless by default.
Open the live demoWhy does the 75th percentile matter so much?
Because averages let you ignore the people having the worst time. A page that loads in 1.2 seconds for three quarters of visitors and 9 seconds for the rest averages to about 3.2 seconds, which sounds mild. In reality one visitor in four stares at a blank screen for nine seconds and most of them leave. To pass at the 75th percentile, three out of four visits have to be good, which forces you to care about older phones, weak connections and visitors far from your servers.
One honest caveat on ranking: Core Web Vitals are a real signal but a light one, and no amount of speed will outrank a page that answers the query better than yours. Fix them because slow pages lose people before they read anything, and because a layout that jumps makes visitors click the wrong thing. The ranking effect is a bonus.
FAQ
What are the Core Web Vitals thresholds?
A page passes when, at the 75th percentile of visits, Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less. Between those and 4 seconds, 500 milliseconds, and 0.25 respectively counts as needs improvement. Beyond that is poor.
Does this tool test my website?
No, and it says so plainly. Core Web Vitals are field data, collected from real visitors on their own devices and networks. A page in your browser cannot measure that for a site it does not run on. Bring your numbers from PageSpeed Insights, Search Console or your own monitoring, and this grades them and tells you what to fix.
Why is my lab score good but my field data bad?
Lab tools like Lighthouse simulate one load on one throttled connection, and they cannot measure INP at all, because nobody interacts with the page. Field data is your actual visitors on real phones. When the two disagree, the field data is the one Google uses and the one your visitors experienced.
Why is the 75th percentile used rather than the average?
An average hides the visitors having a bad time. If three quarters of your loads are fast and the rest are terrible, the average still looks acceptable. The 75th percentile means three out of four visits must be good, which is a threshold you cannot pass by serving a fast experience only to people on fast connections.
Do Core Web Vitals actually affect rankings?
They are a real but small ranking signal, and they act as a tiebreaker rather than a substitute for relevance. The stronger argument is commercial: slow pages lose visitors before they see anything, and a layout that jumps loses clicks to the wrong element.
How long until a fix shows up in my scores?
Field data in the Chrome User Experience Report is a rolling 28-day window, so a deployed fix takes several weeks to fully show up and about a week to start moving. Your own real-user monitoring shows the change immediately, which is a good reason to have some.
Start with one line of HTML.Your first visitors show up within a minute.