Core Web Vitals across several sites: what to measure first

Core Web Vitals are simple for one page and tiring for twenty sites. Each report is per property, each tool shows a different number, and half your smaller sites show no data at all. Here’s how to get a useful picture without a week of tabs.

The thresholds

Three metrics, measured at the 75th percentile of page loads, separately on mobile and desktop. A page passes when all three are good. The bands below are from PageSpeed Insights’ documentation.

Between the two is “needs improvement”. INP replaced First Input Delay in March 2024, so older guides that talk about FID are out of date.

Keep the ranking question in proportion. Google highly recommends good Core Web Vitals and says they align with what its core ranking systems seek to reward. It doesn’t say they’ll lift a page past better content, and we wouldn’t promise that either.

Why two tools give you two numbers

Most confusion comes from mixing up field and lab.

Field data is what real visitors experienced. It comes from the Chrome UX Report (CrUX), as a rolling 28-day average, and only from users who opted in, on supported platforms: Chrome on iOS and other Chromium browsers aren’t included. A fix you shipped today takes weeks to show fully.

Lab data is a single simulated load, such as Lighthouse. It’s immediate and reproducible, and can’t measure INP, since it can’t predict when someone will interact. It uses Total Blocking Time as a stand-in. PageSpeed Insights’ 0 to 100 score is a lab score: good lab data doesn’t necessarily mean real users have a good experience.

The rule is short: use field data to decide what to fix, and lab data to debug it.

How Search Console’s report judges you

The Core Web Vitals report groups pages with a similar experience rather than judging each URL. Three details matter:

• The weakest metric decides. One poor metric makes the whole group poor.
• Each device gets its own status. A group can pass on mobile and fail on desktop.
• Without enough data, it falls back. A group short of data takes the origin’s figures, so a slow template can colour pages that are fine.

After a fix, validation monitors for 28 days before calling it fixed.

When a small site shows no data

Plenty of sites have nothing in CrUX. A page or origin must be publicly discoverable and sufficiently popular, and Google doesn’t publish the threshold. “No data available” doesn’t mean a problem, and it doesn’t mean you’re fine.

You then have two options. Run Lighthouse on your key templates, which tells you about loading and layout but not interaction. Or collect your own field data with a real-user monitoring tool, even a small script that reports the same metrics. For a low-traffic site, the first is usually enough.

Watching many sites without a week of tabs

Use the CrUX API. It’s free with a Google Cloud API key, limited to 150 queries a minute per project, updated daily around 04:00 UTC, and takes an origin or a URL. You can loop over every origin you run in a few seconds, and store the result. A site that answers with no data simply isn’t popular enough yet: record that too.

Start with origins, then drill down. Pull each origin’s three metrics on mobile. Sort by the metric furthest from its threshold, weighted by how much traffic the site gets. A poor LCP on your main site beats a poor CLS on a side project.

Fix templates, not pages. Sites built on the same stack tend to share their problems. If four sites use one layout, the shift on the header is one fix for all four. It’s why this is worth doing across sites rather than one at a time.

Start with what usually moves the number. Google’s guides break each metric down: LCP into server response, resource load and render delay, INP into input delay, processing and presentation, and CLS into what moves and why. For LCP on most marketing sites, look at the hero image first: its size, its format, and whether it’s lazy-loaded when it shouldn’t be. For CLS, look for images without dimensions, and anything injected above existing content. For INP, look at long tasks from third-party scripts.

Remember the delay. After you ship, lab tools show the change at once. Field data takes up to 28 days to reflect it in full, so don’t judge a fix after a week, and note the date you shipped it.

What Owlseen will do about it, and when

PageSpeed and Core Web Vitals are on Owlseen’s list for after the first version, reading the same sources described here. It isn’t released, so none of this depends on it: the CrUX API and a spreadsheet will get you most of the way today.

Meanwhile, if your speed is fine and your traffic is falling, the cause is elsewhere: see content decay and what Search Console holds back.