Core Web Vitals for several websites: what to measure and fix first

Core Web Vitals are Google's three measures of how a page feels to real users: how fast the main content appears, how quickly the page reacts, and how much it jumps around. They are a ranking signal and, more importantly, a conversion factor. This guide explains what to measure, why your small sites may have no data, and how to decide what to fix first when you look after many sites.

The three metrics and their thresholds#

Google assesses each metric at the 75th percentile of real visits, separately for mobile and desktop.

INP replaced First Input Delay in March 2024. If an old report still talks about FID, it is out of date.

Field data versus lab data#

• Field data (CrUX) comes from real Chrome users over the last 28 days. It's what Google uses. It only exists for pages and origins with enough traffic.
• Lab data (Lighthouse) is a simulated load on one device and connection. It is available for any page and great for debugging, but it is not what users experience, and a Lighthouse score of 100 doesn't guarantee good field data.

Use both: field data to know whether there is a problem, lab data to find out why.

Why your small sites have no CrUX data#

CrUX needs a minimum number of real Chrome visits. Many small business sites don't reach it, so PageSpeed Insights says "no data" for the field section. In that case:

1. Use origin-level data if it exists (the whole domain rather than the single page).
2. Otherwise rely on lab tests of your most visited pages, run regularly so you see trends.
3. Watch your own analytics: a jump in bounce rate on mobile after a release is often a performance problem.

Prioritising across many sites#

With ten sites, you cannot fix everything. Rank the work like this:

1. Mobile first. Most traffic is mobile and mobile is where sites fail.
2. Pages with the most visits. A slow page that nobody visits is not a priority; a slow homepage or top landing page is.
3. Poor before "needs improvement". Getting out of red matters more than getting from amber to green.
4. Fix templates, not pages. On most sites, one template (product page, blog post) explains most of the problem.

The usual fixes#

• LCP: serve the hero image in a modern format at the right size, preload it, don't lazy-load it; reduce server response time (caching, a CDN); remove render-blocking CSS and fonts.
• INP: remove or delay heavy third-party scripts (chat widgets, tag managers, A/B testing); split long JavaScript tasks.
• CLS: set width and height on images and embeds; reserve space for ads and banners; avoid inserting content above what the user is reading. Cookie banners pushing content down are a classic cause, one more reason to avoid the banner where you can.

Tracking it for all your sites#

byanalytics stores CrUX field data and Lighthouse lab scores for each site's most visited pages, keeps the history so you can see whether a release helped or hurt, flags popular pages that are slow, and links each issue to a step-by-step fix. Core Web Vitals sit next to traffic, search and uptime in one dashboard, and they appear in the client report. The full setup is in How to monitor multiple websites from one dashboard.

FAQ#

What are good Core Web Vitals scores?#

LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of real visits.

Why does PageSpeed Insights say there is no field data for my site?#

The Chrome UX Report only publishes data for pages and origins with enough real Chrome traffic. Small sites often fall below that threshold, so only lab data is shown.

Do Core Web Vitals affect SEO?#

They are part of Google's page experience signals. They rarely outrank relevance, but between similar pages they can make a difference, and they clearly affect conversions.

How often should I check Core Web Vitals?#

Field data moves over a 28-day window, so weekly is enough, plus a lab test after every release or theme change.