How to Improve Core Web Vitals in 2026

Core Web Vitals (CWV) are a set of three user-centric performance metrics that Google uses as ranking signals to evaluate real-world page experience. First introduced in May 2020, they became an official Google ranking factor in June 2021 as part of the Page Experience Update and were significantly updated in March 2024 when INP replaced the original First Input Delay (FID).

The three metrics measure distinct aspects of user experience:

• LCP (Largest Contentful Paint) , Loading performance: when the largest visible content element finishes rendering
• INP (Interaction to Next Paint) , Responsiveness: how quickly the page responds to user interactions
• CLS (Cumulative Layout Shift) , Visual stability: how much visible content shifts unexpectedly during the page visit

Google evaluates CWV using field data from real Chrome users, aggregated in the Chrome User Experience Report (CrUX). The data is collected over a rolling 28-day window at the 75th percentile , meaning 75% of your actual visitors must experience 'good' scores for the page to pass.

The evolution of CWV reflects Google's deepening commitment to user experience as a ranking factor. The original 2020 trio (LCP, FID, CLS) was refined when Google recognized that FID only measured the first interaction, missing the many subsequent interactions users have with a page. INP, which replaced FID in March 2024, measures all interactions throughout the page lifecycle, making it a far more comprehensive responsiveness metric.

In 2026, CWV remain among the most important technical SEO factors. While content quality is still the primary ranking signal, CWV act as a tiebreaker in competitive SERPs , and in industries like e-commerce, finance, and healthcare, that tiebreaker can mean the difference between page one and page two.

Since the June 2021 Page Experience Update, Core Web Vitals have been a confirmed ranking factor in Google Search. Google has stated explicitly that when two pages have similar content relevance, the page with better CWV will rank higher.

In practice, studies by Searchmetrics, Sistrix, and Ahrefs found that pages passing all three CWV thresholds saw an average ranking improvement of 1–3 positions. While this may seem modest, in competitive SERPs where the top 10 results have similar content quality, a 1–3 position improvement can mean a 30–50% increase in organic click-through rate.

Google Search Console now prominently displays CWV pass/fail status for all indexed pages, making it a key metric in performance audits. The CWV report groups pages by similar URL patterns and shows the percentage passing each metric, allowing you to prioritize optimization efforts on the highest-traffic templates.

The business case for CWV optimization extends well beyond rankings. Multiple large-scale studies have documented the direct relationship between page performance and business outcomes:

• Vodafone improved LCP by 31% and saw a 15% increase in sales
• NDTV reduced LCP by 55% and saw 50% lower bounce rates
• Akamai research shows that a 100ms delay in load time can decrease conversion rates by 7%
• SpeedCurve found that sites with 'good' INP scores see 22% more page views per session
• Google's own research shows 24% fewer page abandonments on sites passing all CWV

For e-commerce sites processing $100K/month, improving CWV from 'poor' to 'good' can translate to $8K–$15K in additional monthly revenue. CWV optimization also reduces Google Ads cost-per-click , Google factors landing page experience (including CWV) into Quality Score, meaning faster pages pay less per click. We've seen clients reduce CPC by 12–18% after passing CWV thresholds.

CWV performance varies significantly by industry. For a full, sourced breakdown across 18 verticals on mobile and desktop, see our 18-industry Core Web Vitals benchmark, Government and Healthcare lead at 78.9% mobile pass, while Technology & SaaS lags at 10.0%, a 69-point spread that dwarfs any single industry-average number.

These benchmarks matter because Google evaluates CWV relative to your competitive landscape. If your competitors are all failing CWV and you pass, the ranking advantage is significant. Conversely, in industries with high pass rates, CWV becomes table stakes rather than a differentiator.

Each Core Web Vital measures a distinct dimension of user experience. Understanding exactly what each metric captures , and doesn't capture , is essential for effective optimization.

Largest Contentful Paint (LCP) measures when the largest visible content element in the viewport finishes rendering. The LCP element is typically a hero image, video poster, large text block, or background image painted via CSS. LCP does NOT measure when the entire page finishes loading , only when the single largest element is visible. Target: ≤ 2.5 seconds from navigation start.

What counts as LCP: <img> elements, <video> poster images, elements with background-image via CSS, block-level elements containing text nodes. What doesn't count: elements with opacity: 0, full-viewport background images used as backgrounds rather than content, placeholder/skeleton elements.

Interaction to Next Paint (INP) measures the responsiveness of your page to user interactions throughout the entire page lifecycle. Unlike FID (which only measured the first interaction), INP considers all clicks, taps, and keyboard inputs, then reports the worst interaction (with some outlier handling). Target: ≤ 200 milliseconds.

INP is calculated as: Input delay + Processing time + Presentation delay. Input delay is time the main thread is busy when the user interacts. Processing time is the event handler execution. Presentation delay is the time to render the next frame after the handler completes.

Cumulative Layout Shift (CLS) measures the total of all unexpected layout shift scores that occur during the entire lifespan of the page. A layout shift occurs when a visible element changes its position from one rendered frame to the next without being triggered by user interaction. Target: ≤ 0.1.

CLS uses a 'session window' approach: layout shifts are grouped into windows with a maximum of 5 seconds and a 1-second gap between shifts. The CLS score is the maximum session window score. This means a single burst of shifts (like during an ad loading) is weighted more heavily than many tiny, spread-out shifts.

The CWV thresholds have remained unchanged since their 2020 introduction:

• LCP: Good ≤ 2.5s | Needs Improvement 2.5–4.0s | Poor > 4.0s
• INP: Good ≤ 200ms | Needs Improvement 200–500ms | Poor > 500ms
• CLS: Good ≤ 0.1 | Needs Improvement 0.1–0.25 | Poor > 0.25

The critical detail most site owners miss: Google evaluates CWV at the 75th percentile (p75) of real-user data. This means that even if your median (50th percentile) scores are 'good,' your page can still fail if the bottom quartile of visitors have poor experiences. This is why testing on your own fast developer machine gives misleading results , you need field data from diverse devices and networks.

Device differences matter enormously. Mobile CWV scores are typically 2–3x worse than desktop due to slower processors, constrained memory, and variable network conditions. Google primarily uses mobile data for ranking in mobile search results (which account for 60%+ of all searches). Always prioritize mobile optimization.

Effective CWV optimization requires understanding both field data (real users) and lab data (simulated tests). They serve different purposes:

Field Data (what Google uses for ranking): Field data captures CWV from actual Chrome users visiting your site. It's aggregated in the Chrome User Experience Report (CrUX) and reflects real-world conditions: diverse devices, networks, geographies, and browsing contexts. Field data is what determines your ranking signal.

Key field data tools:

• Google Search Console , CWV report shows pass/fail for all indexed pages
• PageSpeed Insights , Shows CrUX field data alongside Lighthouse lab data
• CrUX Dashboard , Historical trends in Data Studio
• CrUX API , Programmatic access for bulk monitoring

Lab Data (what you use for debugging): Lab data simulates a page load in a controlled environment with consistent device and network settings. It's reproducible and provides detailed performance traces, making it invaluable for diagnosing issues.

Key lab tools:

• Lighthouse (in Chrome DevTools) , Full audit with actionable recommendations
• WebPageTest , Advanced waterfall analysis, filmstrip comparison, multi-location testing
• Chrome DevTools Performance panel , Frame-by-frame execution traces

How to interpret results: Always check field data first (PageSpeed Insights → 'Discover what your real users are experiencing'). If field data shows failures, use lab tools to diagnose the specific causes. Don't celebrate passing lab scores if your field data is still failing , they measure different things.

1. Only checking desktop scores , Mobile is typically 2–3x worse and is what Google primarily uses for ranking
2. Relying solely on Lighthouse , Lab conditions don't match real-world user experiences; field data determines rankings
3. Testing a single page , Google evaluates CWV at both URL and origin level; check your top 20 pages
4. Ignoring the 28-day window , A one-day fix won't immediately reflect in CrUX data; plan for the lag
5. Testing on fast dev machines , Use Chrome DevTools throttling (4x CPU slowdown, Slow 3G) to simulate real users
6. Not segmenting by device , A page might pass on desktop but fail on mobile
7. Confusing lab INP with field INP , Lab tools measure Total Blocking Time (TBT) as an INP proxy; real INP depends on actual user interactions
8. Ignoring third-party script impact , Analytics, chat widgets, and ad scripts often don't appear in lab tests but devastate field scores

The most common LCP failures (58% of failing pages):

• Unoptimized hero images: Full-resolution JPEGs served to all devices without responsive sizing or modern formats
• Slow server response (TTFB > 800ms): Uncached dynamic pages, distant origin servers, slow database queries
• Render-blocking CSS/JS: Large stylesheets and synchronous scripts in <head> that delay first render
• Missing preload hints: The LCP image not discovered early enough by the browser's preload scanner
• Web font blocking: Custom fonts delaying text rendering (the LCP element is often a heading)

The most common INP failures (hardest to fix, requires JS expertise):

• Long Tasks: JavaScript functions executing for 50ms+ without yielding to the main thread
• Heavy event handlers: Click/scroll handlers doing too much synchronous work
• Third-party scripts: Analytics, chat, social widgets, and ad scripts competing for main thread time
• Excessive DOM size: Pages with 3000+ DOM nodes requiring expensive style recalculations on interaction
• Framework hydration: React/Vue/Angular hydrating large component trees on page load, blocking interactions

CLS Failures (usually quickest to fix):

• Images without dimensions: <img> tags missing width/height attributes cause layout shifts when the image loads
• Dynamic content injection: Banners, cookie notices, and chat widgets inserted above existing content
• Web font loading: Custom fonts with different metrics than fallback fonts causing text reflow
• Ad slots without reserved space: Ads loading asynchronously and pushing content down
• Late-loading CSS: Stylesheets loaded asynchronously that change element sizes after initial render

WordPress: Plugin bloat is the #1 issue. The average WordPress site has 20+ plugins, each adding JavaScript and CSS. Common offenders: page builders (Elementor, Divi add 500KB to 2MB of CSS/JS), social sharing plugins, slider plugins, and security plugins that add front-end scripts. Theme quality varies wildly; avoid themes with bundled plugins and heavy frameworks. See our Ultimate WordPress Speed Guide for platform-specific fixes.

Shopify: App JavaScript accumulates silently. Each Shopify app injects scripts that persist even after the app is uninstalled. Shopify's Liquid rendering is synchronous, so theme complexity directly impacts TTFB. Dawn theme is well-optimized; older themes like Debut and Brooklyn are significantly slower.

WooCommerce: Combines WordPress's plugin issues with e-commerce complexity. Cart fragments AJAX (updating cart count in header) fires on every page load by default, adding 200 to 500ms. Product variation selectors can trigger heavy JavaScript on interaction. High product counts slow database queries. See our Ultimate WooCommerce Speed Guide.

React/Next.js/SPA: Client-side hydration is the primary INP killer. Large JavaScript bundles block the main thread during hydration. Solution: use React Server Components, Suspense boundaries, and dynamic imports. Next.js App Router with streaming SSR significantly improves LCP vs traditional client-side rendering.

These optimizations provide the highest impact with the least effort. Most can be implemented in under an hour each:

1. Preload the LCP image: Identify your LCP element (usually hero image) and add <link rel='preload' as='image' href='...' fetchpriority='high'> in the <head>. This alone can reduce LCP by 500ms–1.5s.

1. Convert images to WebP/AVIF: Modern formats are 30–70% smaller than JPEG/PNG. Use an image CDN (Cloudinary, imgix) or build-time conversion. Serve with <picture> for fallback.

1. Add width/height to all images: Every <img> tag needs explicit width and height attributes (or CSS aspect-ratio) to prevent layout shifts. This is the #1 CLS fix.

1. Defer non-critical JavaScript: Move analytics, chat widgets, and marketing scripts to defer or async loading. Use Google Tag Manager's 'Container Loaded' trigger instead of 'All Pages.'

1. Enable text compression: Ensure your server sends Brotli (preferred) or Gzip compression for HTML, CSS, and JS. This reduces transfer sizes by 60–80%.

1. Set proper cache headers: Static assets should have Cache-Control: max-age=31536000, immutable. HTML should have short cache with revalidation. A CDN makes this much easier.

Want this done for you? Get our Core Web Vitals Optimization Service.

LCP time is the sum of four sub-parts: TTFB (server response), resource load delay (gap between first byte and the browser starting to fetch the LCP resource), resource load time (how long the LCP image itself takes to download), and render delay (main-thread work between the resource arriving and the pixel painting). Diagnose which sub-part dominates in PageSpeed Insights or Chrome DevTools > Performance before choosing a fix.

The single highest-impact fix on most sites is making the LCP image discoverable in the initial HTML and adding `fetchpriority="high"` (with a matching preload when the URL is known at build time). TTFB is the foundation: any TTFB above 600 ms will cap what any other fix can do, so caching and a CDN come first.

Read the full step-by-step guide: How to Improve LCP.

INP is the 98th-percentile response time across every interaction on the page, so one slow click can fail the metric even when everything else feels fast. Each interaction has three phases: input delay (main thread was busy when the input arrived), processing time (the event handler running), and presentation delay (rendering the resulting paint). Find your specific slow interactions with DevTools > Performance or the web-vitals attribution build before optimizing.

The main fix is breaking long tasks (over 50 ms) into smaller chunks with yield patterns (`scheduler.yield()` with a `setTimeout(0)` fallback), then deferring or delaying third-party scripts, trimming heavy event handlers, and reducing DOM size when node counts push past 3,000.

Read the full step-by-step guide: How to Improve INP.

CLS is usually the quickest metric to fix, with most solutions being CSS-based:

1. Explicit Image Dimensions

Every <img> and <video> must have width and height attributes. The browser uses these to calculate aspect ratio and reserve space before the resource loads.

1. Font Loading Strategy

Custom fonts cause layout shifts when they swap with fallback fonts. The solution:

• Use font-display: swap (or optional for non-critical text)
• Add size-adjust, ascent-override, descent-override to the @font-face fallback to match the custom font's metrics
• Preload critical fonts: <link rel='preload' as='font' type='font/woff2' crossorigin>

1. Reserve Space for Dynamic Content

Ads, embeds, and dynamically loaded content need reserved space:

• Use min-height on ad containers matching the expected ad size
• Use skeleton/placeholder UI for lazy-loaded content
• Never insert content above existing visible content (e.g., sticky banners should push content down, not overlay)

1. CSS containment

Use contain: layout on elements that shouldn't affect the layout of their siblings. This tells the browser that the element's internals won't cause external layout shifts.

1. Avoid Intrinsic Size Changes

Don't animate width/height or top/left properties. Use transform and opacity for animations , they don't trigger layout recalculations and can't cause CLS.

For the full definition, thresholds and fix checklist, see the Cumulative Layout Shift glossary entry.

For sites already passing basic CWV thresholds, these advanced techniques push performance to the next level:

HTTP/3 with QUIC: Reduces connection setup time by 33% vs HTTP/2. Eliminates head-of-line blocking. Available on all major CDNs (Cloudflare, Fastly, AWS). Directly improves TTFB and LCP.

Partial Hydration: Frameworks like Astro, Qwik, and React Server Components dramatically reduce client-side JavaScript by only hydrating interactive components. A 60% reduction in JS bundle size is typical, directly improving INP.

Edge Computing: Cloudflare Workers, Vercel Edge Functions, and Deno Deploy bring server logic to the edge, achieving TTFB under 50ms globally. Combined with edge-side rendering, this virtually eliminates LCP issues.

Speculation Rules API: Enables instant navigations by pre-rendering likely next pages based on user behavior. Chrome supports speculative prerendering for same-origin links with configurable eagerness. This makes subsequent page loads appear instant.

View Transitions API: Provides smooth, native transitions between pages without JavaScript animation libraries. Combined with Speculation Rules, creates an app-like navigation experience while maintaining SEO benefits of multi-page architecture.

AI-Powered Image Optimization: Services like Cloudinary and imgix now use ML models to determine optimal compression per-image, achieving 20–30% smaller files than fixed-quality compression without visible quality loss.

WordPress Tools:

• WP Rocket (Premium, $59/yr) , Best all-in-one: caching, critical CSS, lazy loading, database optimization
• Perfmatters ($24.95/yr) , Script manager for disabling plugins per-page, local analytics, preloading
• ShortPixel ($4.99/mo) , Bulk image optimization with WebP/AVIF conversion
• Flying Scripts (Free) , Delays JavaScript execution until user interaction
• Asset CleanUp (Free) , Removes unused CSS/JS per-page

Shopify Tools:

• Theme optimization (manual) , Audit Liquid templates, remove unused sections
• TinyIMG ($0-39/mo) , Image compression and lazy loading
• Shopify's built-in Performance Dashboard , Monitors storefront speed

General Tools:

• Cloudflare (Free–$200/mo) , CDN, auto-minification, HTTP/3, Polish image optimization
• Cloudinary/imgix , Image transformation CDN with responsive delivery
• Partytown (Free, open source) , Moves third-party scripts to web workers
• Unlighthouse (Free, open source) , Batch Lighthouse scanning for entire sites

Monitoring:

• SpeedCurve ($15–525/mo) , Continuous CWV monitoring with competitive benchmarking
• DebugBear ($79–249/mo) , CrUX tracking, Lighthouse monitoring, alerts
• Calibre ($45–500/mo) , Performance monitoring with budget enforcement
• Web Vitals Chrome Extension (Free) , Real-time CWV overlay while browsing

Page experience is more than CWV , our page experience tuning service tunes the whole signal set.

PSI is the canonical CWV reporter , our PageSpeed Insights optimization service fixes what PSI flags.

For before/after examples of these tools and techniques applied to real client sites, see all our client results.