Page speed and Core Web Vitals checker

Real visitors versus the lab test

This page speed checker shows two different kinds of measurement, and they often disagree.

Field data (real visitors) comes from the Chrome User Experience Report: anonymous timings from Chrome users who opted in, collected over the last 28 days. It's what your visitors actually got, on their phones and their connections. Google uses this data for the Core Web Vitals in Search Console and in its page experience signals. It only exists for pages and sites with enough Chrome traffic; when a single page has too little, you'll see your whole site's numbers instead, or none.

Lab data comes from one simulated visit by Lighthouse: a mid-range phone on a slowed-down mobile connection, or a desktop computer. It's repeatable, so it's the right tool for finding causes and testing fixes. But it's one visit in one place, so a lab score of 60 can sit next to field data that passes, and the reverse.

When the two disagree, trust the real-visitor numbers for how you're doing, and use the lab test to work out why.

The three Core Web Vitals in plain English

• Largest Contentful Paint (LCP): how long until the main thing on screen (a hero image, a headline) has loaded. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP): how quickly the page responds when someone taps, clicks or types. Good is 200 milliseconds or less. It needs real people interacting, so only field data has it; in the lab, Total Blocking Time stands in.
• Cumulative Layout Shift (CLS): how much the page jumps around while loading, the thing that makes you tap the wrong button. Good is 0.1 or less.

Each real-visitor number is the 75th percentile: three in four visits were that fast or faster. A page passes the Core Web Vitals assessment when all three are in the good range. These thresholds are the ones Google publishes on web.dev.

Reading the fix list

The fixes come from the lab test's audits, sorted by how much time they'd save. Estimated savings are Lighthouse's own estimates for that one simulated visit, so treat them as a ranking of what to do first, not a promise.

The usual culprits are the same on most sites: images that are too big or in old formats, JavaScript the page doesn't need, third-party scripts (chat widgets, trackers, embeds) that load before your content, web fonts that hide text while they download, and a slow first response from the server. The section above the list shows your largest element: if it's an image, making that one image small, early and not lazy-loaded often moves LCP more than anything else.

Fix one thing, test again, and compare the lab numbers. Real-visitor data takes up to 28 days to catch up, because it's a rolling window.

How much does speed matter for SEO?

Google has said page experience, including Core Web Vitals, is one of many signals it uses, and that great content can outrank a faster page with weaker content. So speed rarely lifts a page on its own. Where it matters most is when results are otherwise close, and for the people who leave before a slow page finishes loading.

If your real-visitor numbers pass, you're done with speed for SEO purposes. Spend the time on content. If they fail, start with the metric that fails and the element behind it.