Core Web Vitals Checklist: Measure, Diagnose and Improve LCP, INP and CLS

Core Web Vitals thresholds and pass criteria

Core Web Vitals are Google’s real-user metrics for three aspects of page experience: loading, responsiveness and visual stability. Largest Contentful Paint, or LCP, measures when the main visible content renders. Interaction to Next Paint, or INP, measures responsiveness across qualifying user interactions. Cumulative Layout Shift, or CLS, measures unexpected visual movement.

The assessment uses the 75th percentile of page visits. A page passes only when every available metric is good. First Input Delay is no longer a Core Web Vital. INP replaced it in March 2024.

Measure the right data before changing code

1. Start with field data. Review the Core Web Vitals report in Google Search Console, then inspect representative URLs in PageSpeed Insights. Both can expose Chrome User Experience Report, or CrUX, data. Field data reflects eligible Chrome users under real devices, networks and behaviors.

2. Confirm the scope. Determine whether the result is URL-level or an origin fallback. CrUX may show origin data when a specific page lacks enough observations. Its rolling 28-day window is updated daily, so a production fix will not instantly replace the earlier sample.

3. Segment the population. Separate mobile from desktop, then compare templates, browsers, countries, connection quality, logged-in states and traffic sources in real-user monitoring. An acceptable site-wide median can conceal a poor mobile p75 on product pages.

4. Use lab tools for diagnosis. Lighthouse provides a repeatable simulated load. Chrome DevTools Performance, Performance Insights and network panels reveal request chains, main-thread tasks and layout shifts. Lab data explains a possible cause; it does not replace field eligibility or prove that the CrUX assessment has passed.

The complete implementation checklist

1. Record current mobile and desktop p75 values for LCP, INP and CLS.
2. Map Search Console issue groups to actual templates, components and release owners.
3. Verify whether PageSpeed Insights is reporting URL or origin data.
4. Identify the LCP element and inspect its request discovery, priority, TTFB and render delay.
5. Capture real INP interactions by element, event type, route and duration.
6. Inspect long tasks, script evaluation, framework hydration and repeated rendering.
7. Review layout shift clusters and identify the elements that moved and caused movement.
8. Add explicit dimensions or aspect ratios to images, video, embeds and reserved ad containers.
9. Preload only critical resources, and remove ineffective or competing preloads.
10. Delay noncritical third-party code without blocking consent, accessibility or required functionality.
11. Test low-powered mobile hardware, slow networks, cached visits and uncached visits.
12. Deploy by template or component, compare against a control period and watch error metrics.
13. Verify the release in DevTools and real-user monitoring immediately.
14. Annotate the deployment date and monitor CrUX throughout the following 28-day cycle.
15. Create a performance budget and automated regression checks for future releases.

LCP checklist: make the main content discoverable and fast

Break LCP into four practical stages: server response, resource load delay, resource load duration and element render delay. The correct fix depends on which stage consumes the time.

• Reduce TTFB: improve caching, edge delivery, database work, redirects and server rendering. Test authenticated and uncached paths, not only warm cache responses.
• Expose the resource: put the hero image in initial HTML when possible. A background image hidden in CSS or an image created by JavaScript can be discovered late.
• Prioritize carefully: apply high fetch priority to the true LCP image where appropriate. Avoid lazy-loading an above-the-fold LCP image.
• Choose efficient media: serve responsive dimensions and modern formats while preserving acceptable visual quality.
• Remove render delay: reduce blocking CSS, expensive client rendering, font delays and overlays that postpone the final LCP element.

A common failure is optimizing image bytes while ignoring discovery. A moderately sized image requested immediately can beat a smaller image discovered after CSS, JavaScript or hydration. If the LCP element is text, investigate fonts, server-rendered markup and blocking styles rather than applying image fixes.

INP checklist: optimize the interaction path, not only startup

INP evaluates qualifying interactions throughout a visit, not merely the first input. Diagnose it as input delay, processing duration and presentation delay. Real-user monitoring should capture the slow interaction, target element, event type, route, device class and surrounding long tasks.

• Break long JavaScript tasks into smaller units and yield to the browser between noncritical chunks.
• Remove duplicate listeners, unnecessary synchronous work and excessive component rerenders.
• Defer analytics, experimentation and chat code that competes with important interactions.
• Use code splitting to keep route-specific functionality out of the initial bundle.
• Avoid large synchronous storage operations and forced layout during event handlers.
• Give immediate visual acknowledgement when the underlying operation must continue asynchronously.
• Test menus, filters, search suggestions, accordions, form validation, checkout controls and single-page navigation.

A fast Lighthouse load does not prove good INP because a scripted lab test may never reproduce the interaction that users find slow. Short visits can also produce limited interaction evidence. Collect enough context to fix the responsible component instead of applying broad JavaScript reductions without knowing the affected path.

CLS checklist: find what moved and what caused it

CLS failures often happen after the initial viewport looks complete. Use DevTools layout shift records and real-user attribution to identify both the element that moved and the earlier element that created or removed space.

• Set width and height attributes or CSS aspect ratios for images and video.
• Reserve realistic space for ads, recommendation widgets and embeds before they load.
• Do not inject banners above existing content unless space was already reserved.
• Keep cookie and promotional interfaces in overlays or predefined containers where appropriate.
• Preload essential fonts selectively, use suitable fallback metrics and test the font swap.
• Animate with transforms where possible instead of layout-changing properties.
• Test responsive breakpoints, localization, personalization and empty ad responses.

Do not assume the visibly moving element caused the problem. A late-loading ad above an article may push several stable elements downward. Also distinguish expected movement following a user action from unexpected movement. The diagnostic objective is not to freeze every interface, but to prevent movement users did not request or anticipate.

Diagnostic decision framework

Prioritize fixes by templates, business paths and risk

Do not rank the backlog solely by the worst score. Combine severity, affected visits, conversion importance, template reach, engineering effort and regression risk. A shared product-card component affecting thousands of indexed pages may deserve priority over one extremely slow low-traffic page.

Start with reusable components and high-value paths such as category pages, lead forms, product detail pages and checkout. Preserve canonical tags, structured data, internal links and indexable server-rendered content during framework or rendering changes. Review server logs after major migrations to ensure performance work did not introduce crawler errors, redirect chains or unstable responses.

Set budgets for JavaScript, critical CSS, LCP resource size, long-task time and layout shifts. Add synthetic tests to continuous integration, but keep field dashboards as the outcome measure. Use before-and-after cohorts or controlled rollouts where traffic permits. Track Core Web Vitals beside conversion rate, bounce behavior, errors and revenue so a faster release is not accepted if it breaks functionality.

High-risk shortcuts include hiding meaningful content until after load, serving bots a different experience or delaying essential functionality merely to improve a test. These approaches can damage usability and create cloaking or measurement problems. Optimize the same experience users and crawlers receive.

Search rankings, AI retrieval and content strategy

Google states that Core Web Vitals are used by ranking systems, but good scores do not guarantee top rankings. Relevance, helpful content and overall page experience remain decisive. Treat a pass as a quality baseline and tie-breaker opportunity, not a substitute for satisfying search intent.

Performance also affects how reliably users and automated systems access a page. For answer engines, keep the central definition, thresholds and diagnostic steps in crawlable HTML rather than requiring interaction or client-only rendering. Use descriptive headings, concise answer-first paragraphs, explicit metric relationships and visible tables that can be extracted without losing context.

Build a focused performance topic cluster around this checklist: dedicated LCP, INP and CLS guides; a PageSpeed Insights interpretation guide; a real-user monitoring implementation page; and framework-specific troubleshooting. Consolidate overlapping thin posts, maintain canonical discipline and link from relevant technical SEO hubs using descriptive anchors. Refresh screenshots, thresholds and tool behavior when standards change.

An anonymized benchmark or template-level performance study can create natural link demand if its methodology and limitations are published. Comparison assets, reproducible tests and expert engineering contributions are more defensible than generic statistics pages. Monitor link intersections and unlinked citations to the original asset, then request attribution without fabricating evidence or endorsements.

What is proven, what practitioners infer and what remains uncertain

Established by official documentation

LCP, INP and CLS are the current Core Web Vitals. The good thresholds are 2.5 seconds, 200 milliseconds and 0.1 at the 75th percentile. Field data is the appropriate basis for judging real-user performance, while Lighthouse is a diagnostic lab tool. Core Web Vitals participate in Google’s ranking systems, but passing does not guarantee rankings.

Supported by independent data and practitioner consensus

The independent State of Web Vitals Q2 2026 dataset reports roughly 200,000 sites and phone p75 figures of 2,209 milliseconds for LCP, 128 milliseconds for INP and 0.02 for CLS. Its reported pass rates are 81.7 percent, 91.9 percent and 88.8 percent. These figures provide context, not official Google ranking data. Practitioners commonly prioritize severe failures and shared components before chasing perfect scores.

Still uncertain or site-specific

No public formula establishes the ranking lift from moving a particular score. CrUX excludes some users and products, and crawl datasets do not represent every template or interaction. Community reports of lab and field disagreement are useful diagnostic clues, but they are anecdotal. The business effect of a fix should therefore be measured on the specific site rather than inferred from a universal conversion promise.