Core Web Vitals 2026: How to Pass LCP, INP and CLS

Core Web Vitals are Google’s three measurements of real-world page experience: how fast the main content loads, how quickly the page responds when someone interacts with it, and how stable the layout stays while it loads. They affect how visitors feel about your site, and Google uses them in its ranking systems. This guide gives each metric its own card, with what it measures, the threshold to hit, the usual causes, the fixes that work and the tools to check them, followed by a troubleshooting table and platform tips for WordPress and Shopify.

Quick answer: To pass Core Web Vitals, at least 75% of real visits to a page must score “good” on all three metrics: Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Google measures this from field data, separately for mobile and desktop.

What are Core Web Vitals?

Core Web Vitals are a set of three user-centered metrics defined by Google that measure loading performance, interactivity and visual stability on real visits to a web page. They are part of a broader Web Vitals initiative documented on web.dev, Google’s developer resource for web quality.

Each metric has three bands: good, needs improvement and poor. A page passes when its 75th-percentile value for every metric falls in the good band. Google evaluates mobile and desktop separately, so a page can pass on one and fail on the other.

Do Core Web Vitals affect Google rankings?

Yes, but they are one signal among many. Google Search Central says Core Web Vitals are used by its ranking systems and recommends achieving good scores, while also making clear that good results in reports do not guarantee top rankings. Relevance and content quality still come first.

The more practical reason to care is your visitors. A page that loads slowly, freezes after a tap or jumps around while someone reads is frustrating, and frustration tends to show up in bounce rates and lost conversions. Many of the UX design mistakes that kill conversions are, at heart, performance problems.

Field data vs lab data: which one counts?

Field data comes from real users visiting your site, collected through the Chrome User Experience Report (CrUX). Lab data comes from a simulated test run in a controlled environment, such as Lighthouse.

Low-traffic pages may not have enough field data. In that case, PageSpeed Insights may show origin-level data or none at all, and you will rely on lab tests until traffic builds.

Core Web Vitals thresholds at a glance

The Core Web Vitals thresholds below come from web.dev and apply at the 75th percentile of page loads.

Metric card 1: Largest Contentful Paint (LCP)

What LCP measures

Largest Contentful Paint is the time from when a user starts loading a page until the largest image or text block visible in the viewport has rendered. It approximates the moment a visitor feels “the page has loaded.” On most business sites, the LCP element is a hero image, a product photo or a large headline.

LCP threshold

Aim for an LCP of 2.5 seconds or less at the 75th percentile. Above 4.0 seconds is rated poor.

What causes slow LCP?

web.dev breaks LCP into four subparts, and each points to a different type of cause:

A common misconception is that LCP is all about image size. Often the bigger delays happen before the image even starts downloading.

How to fix LCP

1. Speed up the server response. Use good hosting, enable page caching and serve pages through a content delivery network (CDN).
2. Make the LCP image discoverable. Put the hero image in the HTML as a normal img element rather than injecting it with JavaScript.
3. Never lazy-load the LCP image. Lazy loading is great for images below the fold and harmful for the main image above it.
4. Prioritize it. Add fetchpriority="high" to the LCP image so the browser downloads it early.
5. Shrink the bytes. Serve correctly sized images in modern formats such as WebP or AVIF, using srcset for different screen sizes.
6. Remove render-blocking resources. Inline critical CSS, defer non-essential JavaScript and trim unused CSS.
7. Avoid redirect chains on landing URLs, especially from ads and email links.

Tools to measure LCP

• PageSpeed Insights: field LCP from CrUX plus a lab diagnosis that identifies the LCP element.
• Search Console Core Web Vitals report: groups of URLs with poor or needs-improvement LCP.
• Chrome DevTools Performance panel: shows the LCP element and a breakdown of its subparts.
• Lighthouse: lab LCP and specific recommendations.

Metric card 2: Interaction to Next Paint (INP)

What INP measures

Interaction to Next Paint measures how quickly a page visibly responds after a user clicks, taps or presses a key. It observes interactions throughout the whole visit and reports one of the slowest, ignoring a small number of outliers on pages with many interactions. Scrolling and hovering are not counted.

INP replaced First Input Delay as a Core Web Vital in March 2024. The older metric only measured the delay before the first interaction was processed, while INP covers the full response time of interactions across the entire visit.

Each interaction has three phases:

• Input delay: waiting for the browser’s main thread to be free.
• Processing duration: running the event handlers your code attached.
• Presentation delay: calculating layout and painting the next frame.

INP threshold

Aim for an INP of 200 milliseconds or less at the 75th percentile. Above 500 milliseconds is rated poor.

What causes poor INP?

• Long tasks: JavaScript tasks that block the main thread for more than 50 milliseconds, which web.dev defines as long tasks.
• Third-party scripts: chat widgets, analytics tags, A/B testing tools, ad scripts and social embeds competing for the main thread.
• Heavy event handlers: code that does too much work in response to a click, such as re-rendering a large part of the page.
• Large DOM size: pages with huge numbers of elements take longer to update and repaint.
• Hydration and framework overhead: client-side frameworks doing expensive work during or after load.

How to fix INP

1. Audit third-party scripts. Remove tags nobody uses, and load the rest after the main content or on interaction.
2. Break up long tasks. Split heavy work into smaller chunks and yield to the main thread so the browser can respond to input in between.
3. Do the minimum on interaction. Show visual feedback first, such as a pressed state or spinner, then run non-urgent work afterwards.
4. Reduce DOM size and complexity. Simplify deeply nested layouts, paginate long lists and use content-visibility for off-screen sections.
5. Avoid layout thrashing. Batch reads and writes to the page layout instead of alternating between them.
6. Debounce frequent handlers such as live search or filters so they do not run on every keystroke.

Tools to measure INP

• PageSpeed Insights and Search Console: field INP from real users. Lab tests cannot produce INP because nobody is interacting.
• Chrome DevTools Performance panel: live interaction timings as you click around, plus traces showing which scripts caused the delay.
• Lighthouse: Total Blocking Time is a useful lab proxy; high TBT usually predicts INP problems.
• The web-vitals JavaScript library: collect INP from your own visitors and send it to your analytics.

Metric card 3: Cumulative Layout Shift (CLS)

What CLS measures

Cumulative Layout Shift measures how much visible content moves unexpectedly while a page is open. Each unexpected shift gets a score based on how much of the viewport moved and how far it moved. CLS reports the largest burst of shifts, called a session window, during the visit.

Shifts that happen shortly after a user interaction, such as opening an accordion, are excluded because the user expects them.

CLS threshold

Aim for a CLS of 0.1 or less at the 75th percentile. Above 0.25 is rated poor.

What causes layout shifts?

• Images and videos without width and height attributes or a CSS aspect-ratio
• Ads, embeds and iframes that load without reserved space
• Cookie banners, promo bars or notices inserted above existing content
• Web fonts that swap in with different dimensions from the fallback font
• Content injected by JavaScript after load, such as reviews widgets or related products
• Animations that change layout properties like top or height instead of using transform

How to fix CLS

1. Always set image dimensions. Add width and height attributes so the browser reserves space before the file arrives.
2. Reserve space for dynamic content. Give ad slots, embeds and widgets a minimum height that matches their usual size.
3. Overlay, don’t push. Show cookie banners and notices as overlays at the bottom of the screen instead of inserting them above content.
4. Stabilize fonts. Preload key fonts and use fallback font metric overrides such as size-adjust so the swap does not reflow text.
5. Animate with transforms. Use transform and opacity for movement rather than properties that trigger layout.
6. Keep pages eligible for the back/forward cache, so returning visitors see an instantly restored page with no shifting.

Tools to measure CLS

• PageSpeed Insights and Search Console: field CLS and affected URL groups.
• Chrome DevTools Performance panel: highlights layout shift regions and the elements that moved.
• Lighthouse: lists the largest layout shift culprits in a lab load.

Core Web Vitals troubleshooting table: symptom, cause, fix

Use this table when you can see the problem but are not sure where it comes from.

How to improve Core Web Vitals on WordPress

WordPress sites usually struggle because of hosting, page builders and plugin bloat rather than WordPress itself. Practical steps:

• Choose solid hosting with server-level caching and a modern PHP version.
• Use a caching plugin or host-level cache for full-page caching, and put the site behind a CDN.
• Limit plugins to those you actually use; each one can add scripts and styles to every page.
• Be careful with page builders, which can generate heavy markup and large DOM sizes. Lighter block themes often perform better.
• Rely on core image features. WordPress lazy-loads images by default, and since version 6.3 it automatically adds fetchpriority="high" to the image it judges most likely to be the LCP element. Check that your theme or builder does not override this on the hero.
• Keep speculative loading on. Since WordPress 6.8, core enables speculative loading by default, prefetching pages as visitors begin to click a link, which can make navigations feel faster.
• Optimize images with a plugin or CDN that serves WebP or AVIF in the correct sizes.

If you are still choosing a platform, our comparison of Webflow, WordPress or custom code covers performance trade-offs alongside cost and flexibility.

How to improve Core Web Vitals on Shopify

Shopify handles hosting, the CDN and image delivery for you, so most problems come from themes and apps. Practical steps:

• Check the web performance report. Shopify’s admin includes a web performance report under Analytics that shows LCP, INP and CLS from real visitors, broken down by page type and device.
• Start from a fast theme and avoid stacking heavy sections such as autoplay video, multiple sliders and large carousels above the fold.
• Audit apps regularly. Many apps inject scripts on every page even when the feature is used on one. Uninstall unused apps and check that their code was actually removed from the theme.
• Use Shopify’s responsive image tools in the theme so images are served at sensible sizes, and avoid lazy-loading the first product or hero image.
• Reserve space for app widgets such as reviews, upsells and announcement bars to avoid layout shifts.
• Be selective with tracking pixels and marketing tags, which are a frequent cause of poor INP on product pages.

For stores weighing platforms, our Shopify vs WooCommerce comparison explains how hosting responsibility changes the performance work you will own.

How should you approach Core Web Vitals fixes?

The best approach is to work from field data to lab diagnosis to fixes, then wait for field data to confirm the improvement. A simple workflow:

1. Find the failing templates. Open Search Console’s Core Web Vitals report and note which URL groups fail and on which device.
2. Pick a representative URL from each group, such as a product page or blog post template.
3. Diagnose in the lab. Run PageSpeed Insights and Chrome DevTools to find the LCP element, long tasks and shifting elements.
4. Fix by template, not page. One change to a product template can fix thousands of URLs.
5. Validate in Search Console once fixes are live, and allow time for the rolling 28-day field data to update.
6. Prevent regressions. Add performance checks to your release process, and re-test after installing new apps, plugins or tags.

Core Web Vitals should be part of a wider review. Our full technical SEO audit checklist covers crawling, indexing and the other checks that sit alongside performance, and our website redesign checklist shows how to protect these scores when you relaunch.

Faster, more stable pages often help commercial results too. If you sell online, compare your performance work with your ecommerce conversion rate, and pair it with proven conversion rate optimization tips for the biggest gains.

Keep reading

Technical SEOTechnical SEO Audit Checklist: 25 Points to Check YourselfRead articleTechnical SEOSchema Markup for Beginners: Get Rich Results in GoogleRead articleTechnical SEOWhy Is My Website Not Showing on Google? 10 FixesRead article