The Core Web Vitals report in Search Console, page group by page group

The report shows field data, not a lab test. It reads the Chrome User Experience Report for your origin and for individual URLs when there is enough traffic.

• Largest Contentful Paint: good up to 2.5 s, poor above 4 s.
• Cumulative Layout Shift: good up to 0.1, poor above 0.25.
• Interaction to Next Paint: good up to 200 ms, poor above 500 ms.

It uses the 75th percentile of real user page loads over the last 28 days. That is the slice Google cares about for Search. It is based on opted in Chrome users on Android and desktop, not iOS.

There are Mobile and Desktop tabs. Mobile matters first for Search because Google crawls with a smartphone user agent as of 2023. You should fix mobile first if you must pick one round of work.

Search Console clusters URLs with similar issues. A “Poor” or “Needs improvement” group is usually one template or one component shared across many pages.

1. 1

   Open the group

   In the Core Web Vitals report, click a group under Mobile or Desktop. You will see a representative URL and the issue, for example “LCP issue: longer than 2.5 s.”

2. 2

   Map the URL to a template

   Identify the route or component: product detail page, blog post, category, documentation article. For example, /blog/how-we-built-analytics and /blog/launch-notes use the same layout.

3. 3

   List the affected set

   Use your router, your CMS, or your sitemap to list every URL that uses the same layout. For example, all /blog/* posts, or all /product/* pages.

4. 4

   Fix the template, not one page

   Ship the change in the shared code. One deploy moves the whole group when enough real users load those pages.

5. 5

   Validate in Search Console

   After release, click “Validate fix” on the issue. Google will watch field data on the group for fresh loads over the next weeks.

A fixed group looks like this: the same group flips to Green on Mobile within a month, and the Desktop tab follows if it shared the cause. You will still see a lag while new field data rolls in over 28 days.

Field data needs visits. If a URL has too few Chrome users, Search Console falls back to origin level data or shows nothing for that URL. That is normal on new sites, small blogs, or lightly visited routes like /legal/terms.

• Check PageSpeed Insights for the URL. The top card shows field data if there is enough traffic. If not, it shows origin data or no field data.
• Use lab data as a guide when field data is missing. Fix the template, ship, and wait for visits to populate field data.
• Do not create artificial visits. You need real users for CrUX to record a change that Search trusts.

Core Web Vitals are a ranking signal at the Good thresholds. The signal is smaller than relevance and content, but it can tip close results. Your aim is to pass the Core Web Vitals assessment for the pages that matter to you, especially on Mobile.

A Poor group costs you when many users land on it from Search. For a SaaS, this can be /pricing, /signup and /guides/getting-started. For a store, /product/* templates and /category/* matter most. Fix the shared code and you lift many landing pages at once.

1. 1

   Open the representative URL in PageSpeed Insights

   Use pagespeed.web.dev. Check Mobile first. The top “Discover what your real users are experiencing” section is the field data. The lower section is a Lighthouse run on a simulated device.

2. 2

   Confirm the failing metric

   Is it LCP, CLS or INP in field data? Note the Mobile pass or fail on the Core Web Vitals assessment. The field result is the one that matters for Search.

3. 3

   Use Lighthouse audits to find causes

   Scroll to “Diagnose performance issues.” Look for render blocking resources, large images, third party scripts, layout shifts and main thread work.

4. 4

   Fix the template

   Make the change in the layout, include components and assets. Use your staging site and run Lighthouse locally until the core issue is gone.

5. 5

   Release and wait 28 days

   Field data is a 28 day window at the 75th percentile. You will see the group move when enough users have loaded the new version.

6. 6

   Validate the fix

   In Search Console, click the issue and then “Validate fix.” Watch the status. If some URLs lag, they may not get enough visits yet, or they use a different component.

On a site with traffic, Mobile often moves within two to three weeks from release. Desktop can differ if it serves other assets or fonts. Keep your change small and targeted so the impact is clear when you read the next window of data.

LCP is often your hero image or a large block of text. Slow servers, lazy loaded hero images, late discovery and unoptimised assets delay it. You win by reducing TTFB and by making the hero asset arrive earlier and smaller.

• Do not lazy load the hero. Remove loading=lazy from the above the fold image.
• Add fetchpriority=high to the hero image. Preload it if it is a CSS background.
• Name the hero image in the HTML so the browser discovers it early. Avoid injecting it late with JavaScript.
• Use responsive images: srcset and sizes. Serve AVIF or WebP. Use a CDN close to users.
• Cut server time: cache or pre render HTML, use HTTP/2 or HTTP/3, keep connections alive, and avoid redirect chains.

A fixed /pricing page looks like this: TTFB drops, the hero loads eagerly, and LCP lands under 2.5 s on Mobile in field data after the release window fills. The group flips to Good if CLS and INP also pass.

CLS comes from boxes that shift after paint. Ads, images, fonts and banners are the usual causes. Template level fixes remove the jolt for every page in the group.

• Give every image, video, iframe and ad slot fixed dimensions or an aspect ratio. Reserve space for dynamic slots with min height.
• Do not insert banners above content. Use an overlay for cookie notices or use space that already exists.
• Reduce font shifts. Self host WOFF2. Preload only the face used above the fold. Use font display swap or optional. Match fallback metrics with size adjust and ascent override.
• Do not animate layout properties like top or height. Use transform for movement.
• Avoid inserting content above the fold after load. If you must, reserve the space ahead of time.

A fixed /blog/* group looks like this: the title, date and cover image render in a reserved box and no bar pushes content down later. CLS settles under 0.1 in the Mobile field data panel in PageSpeed Insights once users reload the new version.

INP measures the worst interaction in a visit, excluding rare outliers. Slow taps and clicks come from main thread work and heavy handlers. Hydration on large frameworks is a common reason on apps and dashboards.

• Break long tasks into smaller chunks. Use scheduler.yield or a setTimeout to give the main thread a chance to paint.
• Render the visual change first, then do the work. For example, open the menu, then load its data.
• Load fewer and smaller scripts. Remove dead code and unused packages. Delay third party scripts until after interaction when possible.
• Use web workers for heavy computation. Keep the DOM small and avoid sync layout reads after writes.
• Reduce hydration cost. Server render UI, split routes, and hydrate only what is interactive above the fold.

A fixed /app/settings screen looks like this: the Save button responds within 200 ms on real devices, and slow tasks run in the background. The group’s Mobile INP moves to Good in field data after release traffic accumulates.

PageSpeed Insights shows two different datasets. The top card is field data from CrUX with a pass or fail on the Core Web Vitals assessment. The lower section is a Lighthouse lab run on a simulated mid range phone over throttled 4G. They can disagree. Trust field data for Search and use Lighthouse audits to find causes.

Lighthouse weights Total Blocking Time the highest in the score. It is a proxy for interaction issues in lab. Use it to spot main thread work when you cannot measure INP in lab. Still, ship for field outcomes, not for a round score that jitter between runs.

Most group wide problems come from shared assets. Clear the render path, make media efficient and keep third party code in check across the layout. Here is the short list to apply once per template.

• Inline critical CSS for the above the fold view. Load the rest with media=print and onload. Defer or async scripts. Type=module defers by default.
• Remove unused CSS and avoid @import. Each stylesheet blocks rendering until it arrives.
• Optimise images. Use srcset and sizes. Prefer AVIF or WebP. Do not lazy load the first viewport image. Use decoding=async on other images. Preload the one hero that defines LCP.
• Preload the one font face used above the fold with rel=preload as=font and crossorigin. Self host WOFF2. Use a system stack when you can. Match fallback metrics to avoid shifts.
• Trim third party scripts. Keep the tag manager lean. Load heavy embeds on interaction with a facade. Defer analytics until after load if the data can wait. Preconnect to early critical origins.

Ship these in the shared head and header includes. Test /, /pricing and one content page. If those three pass, most groups that use the same layout will pass too once field data refreshes.