Check this page with an assistantOpens a chat asking it to summarise this article and name the evidence behind each claim.
Claude opens with the prompt on your clipboard: Anthropic does not support prefilled prompts on the web, and we would rather copy it than ship a button that drops it.
Three Metrics, Three Different User Failures
Core Web Vitals measure loading, responsiveness, and visual stability through Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. A page is “good” only when its slowest metric meets the good threshold for the relevant URL group and device.
| Metric | Good threshold | Human question |
|---|---|---|
| LCP | 2.5 seconds or less | When does the main content feel loaded? |
| INP | 200 milliseconds or less | How quickly does the page respond to interaction? |
| CLS | 0.1 or less | Does visible content stay where the user expects? |
These thresholds are evaluated at the 75th percentile of real visits, separately for mobile and desktop. That means a fast developer laptop and one green Lighthouse run cannot establish success. The slower devices, networks, interaction paths, and page states in actual use belong to the metric.
Field Data Finds the Problem; Lab Data Explains It
Start with Search Console’s Core Web Vitals report or another CrUX view. It groups URLs that Google expects to share an experience and labels the group according to its worst metric. A representative URL is a doorway into the group, not proof that every page behaves identically.
Then reproduce the template in PageSpeed Insights, Chrome DevTools, or Lighthouse. A lab trace gives a network waterfall, main-thread tasks, layout-shift regions, and resource priorities. It can identify a cause, but it does not replace field evidence.
| Evidence | Best use | Limitation |
|---|---|---|
| Search Console / CrUX | Real-user outcome and template prioritization | Rolling, grouped, and unavailable on low-traffic pages |
| PageSpeed Insights | Field context plus a diagnostic lab run | A single URL may not represent the group |
| DevTools / Lighthouse | Reproduction, traces, and engineering diagnosis | Controlled environment, not the user population |
| Real-user monitoring | Own templates, releases, devices, and interaction details | Requires instrumentation and privacy-aware analysis |
Prioritize by Template, Severity, and Business Reach
Do not hand engineers a list of individual slow URLs. Group by the code path that can change: product detail, category, article, location, checkout, or landing-page template. Add the affected URL count, device, failing metric, field value, impressions, and conversion role.
- Fix Poor groups before Need improvement groups.
- Within a status, prefer the shared cause affecting more useful URLs.
- Confirm the representative page truly uses the same component stack.
- Choose one measurable hypothesis and one owner for the release.
- Protect the gain with a template-level performance budget.
A high-traffic product template with poor INP usually outranks a one-off marketing page that misses LCP by 50 milliseconds. The goal is fewer bad experiences and stronger business journeys, not a wall of perfect scores.
Fix LCP by Following the Critical Resource
LCP is often a hero image, poster frame, or large text block. Break its time into the initial server response, the delay before the browser discovers the LCP resource, the resource’s load duration, and the delay before the element can render. Each segment points to a different owner and fix.
- Reduce server delay. Cache stable responses, remove avoidable redirects, and keep origin work predictable.
- Expose the resource early. Put the image URL in initial HTML instead of discovering it through JavaScript or a CSS background.
- Prioritize the likely LCP asset. Do not lazy-load it; use
fetchpriority="high"selectively when testing supports the choice. - Deliver fewer bytes. Use correctly sized, responsive, compressed media from a reliable origin.
- Remove render delay. Reduce blocking CSS, font delay, and client rendering required before the element appears.
High priority on every image is no priority at all. Optimize the actual LCP element per template and viewport. The image SEO guide covers responsive sources, explicit dimensions, thumbnails, and delivery.
Fix INP by Shortening the Interaction’s Critical Path
INP observes click, tap, and keyboard interactions across the page visit and reports a high-latency interaction while limiting outlier influence. The delay includes waiting for the main thread, event handler work, and the browser’s next presentation.
Reproduce the slow interaction, not merely the page load. Open the menu, change a filter, select a variant, type in search, accept consent, and add to cart. Long startup tasks can block later input, but application code inside the interaction is often the real cause.
- Split long tasks and yield so the browser can respond.
- Reduce JavaScript shipped, parsed, and executed on the template.
- Keep event handlers narrow; defer work not required for the next paint.
- Avoid synchronous layout reads and writes that force repeated calculation.
- Render smaller DOM updates and virtualize genuinely large interactive lists.
- Move appropriate heavy computation off the main thread.
Hydration volume matters because it competes for the same main thread. The JavaScript SEO guide helps identify where server output can preserve search content while less client code handles the interaction.
Fix CLS by Reserving the Final Geometry
CLS accumulates unexpected layout shifts across the page’s lifetime, not only initial load. Images without dimensions are a common cause, but banners, consent interfaces, ads, embeds, late fonts, injected recommendations, and expanding validation messages can all move a target after the user commits attention.
| Cause | Reliable control |
|---|---|
| Images and video | Width/height attributes or a stable aspect-ratio box |
| Ads and embeds | Reserve a realistic slot before the resource arrives |
| Web fonts | Match fallback metrics and control loading behavior |
| Late banners | Overlay appropriately or reserve space from the start |
| Animation | Animate transforms instead of layout dimensions |
Use DevTools layout-shift regions and real-user attribution to find the moving element and the element that caused it. They are not always the same. Test long sessions, responsive breakpoints, consent states, and components that appear after interaction.
Validate Without Waiting Blindly
Before release, capture a baseline for representative pages under consistent mobile and desktop conditions. Ship the smallest template change that tests the hypothesis. Confirm the expected trace change in lab, watch real-user monitoring for regressions, and then start Search Console validation.
Search Console uses a 28-day validation period because the report is based on rolling real-user data. Starting validation does not request recrawling. If a group fails, compare release dates, device mix, geography, traffic changes, and individual template behavior before reverting a sound fix.
Review the report in the weekly workflow described in the Search Console operator’s guide. Keep performance alongside indexability, visibility, and outcomes so the organization does not mistake a metric improvement for the whole search strategy. Verify content and signal parity separately with the mobile SEO field note.
Questions About Core Web Vitals
- Are Core Web Vitals a Google ranking factor?
Google says Core Web Vitals are used by its ranking systems, but there is no single page-experience signal and good scores do not guarantee top rankings. Relevance remains central. Treat the metrics as user-experience outcomes that can contribute when several useful results compete, not as a substitute for content or demand.
- Why does Search Console disagree with Lighthouse?
Search Console and Lighthouse answer different questions. Search Console uses aggregated real-user CrUX data over a rolling period and groups similar URLs. Lighthouse runs a controlled lab simulation for one page load. Use field data to identify the real problem and lab traces to reproduce and diagnose likely causes.
- How long does Core Web Vitals validation take?
Search Console’s validation tracks field data through a 28-day monitoring period. A deployed fix can look better immediately in a lab test while the field report changes gradually as new real-user visits replace older data. Starting validation does not trigger recrawling or speed up collection.
- What if Search Console says there is no data?
The property or URL group may not have enough eligible real-user data in Chrome UX Report. That does not mean the page is fast. Test representative templates with PageSpeed Insights, Lighthouse, DevTools, and your own real-user monitoring, then keep a performance budget in deployment checks.
Primary Sources Reviewed
- Google Search Central: Core Web Vitals and search results
- Google Search Central: Understanding page experience
- Google Search Console: Core Web Vitals report
- web.dev: Optimize Largest Contentful Paint
- web.dev: Optimize Interaction to Next Paint
- web.dev: Optimize Cumulative Layout Shift
Reviewed July 28, 2026. Web Vitals definitions, browser behavior, and report interfaces evolve; verify current thresholds and measure the actual production templates before prescribing a fix.
