Enter an address and we read what real Chrome visitors experienced — LCP, INP and CLS at the 75th percentile, on phone, desktop and tablet. You get the dates the measurement covers, LCP broken into the four parts it is made of, and a plain statement of anything Chrome had no data for.
Three metrics: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. All three have to be good at the 75th percentile for a site to pass. First Contentful Paint and Time to First Byte are useful for working out why LCP is slow, but they are not part of the assessment, and this tool labels them that way rather than mixing them into the verdict.
LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1 — each measured at the 75th percentile, so three out of four visits have to be good. Every one of those numbers is shown next to the metric in the report, with a link to the Google page it was read from and that page’s own last-updated date. If a threshold here ever disagrees with Google, the link is how you catch us.
Chrome only publishes field data once an origin has enough opted-in visitors for the sample to stay anonymous. A quiet site is not slow, it is unmeasured, and no tool can read field data that does not exist. A single page needs considerably more traffic than a whole origin, so if your page comes back empty, try the whole site first.
Field data, from real Chrome visitors over a rolling 28-day window. This is the data Google’s own page-experience signals are built on. A lab test reloads your page once on a simulated device: reproducible, good for debugging, and unable to measure INP at all because nobody clicks anything. We report the field numbers and tell you the exact dates they cover, so you can see how stale they are.
Because the window is 28 days wide and rolls forward a day at a time, a fix landing today is averaged with four weeks of the old behaviour. The weekly history is the honest way to watch this: one period per week, up to 40 of them, so an improvement shows up as a trend rather than as a single number you cannot interpret.
LCP is the sum of four parts: how long the server took to answer, the gap before the largest image started downloading, how long that download took, and the gap before the browser painted it. We show all four with their shares. The largest part is the only one worth your morning — optimising any other part cannot move LCP by more than that part contributes, which is the arithmetic most speed reports leave out.
A visit restored from the back-forward cache is close to instant and counts in your averages. If a large share of your traffic is those restores, your reported numbers are better than what a first-time visitor actually gets. We surface the navigation mix so you can tell the difference, and warn when the cached share is large enough to be flattering the result.
If the biggest slice of your LCP turns out to be render delay rather than server time or download time, the browser had the content and was waiting on something else — very often a stylesheet it had to fetch and parse before it could paint anything at all. Our critical CSS generator extracts the rules your first screen actually needs so the rest can load without holding up the paint.
Page experience is also one of the factors behind every number in our website valuation method: a site that fails these metrics is harder to keep ranked, which makes its traffic less durable and the site itself worth less.