Core Web Vitals 2026: Complete Optimization Checklist

Understanding the Three Core Web Vitals in 2026

Largest Contentful Paint (LCP) measures the time it takes for the largest visible content element — typically a hero image, above-the-fold heading, or video poster — to render fully. Google's Good threshold is LCP under 2.5 seconds. Interaction to Next Paint (INP) measures the latency from a user's input (click, tap, or keypress) to the next visual update — essentially how responsive the page feels to interactions. The Good threshold is INP under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual instability — how much page elements shift during loading. The Good threshold is a CLS score below 0.1. All three are measured from real user field data collected through Chrome User Experience Report (CrUX), which means your scores reflect actual user experiences on your live site — not just lab tests. This field data is what Google uses for ranking purposes, making real-world performance improvement the correct goal.

• LCP Good threshold: under 2.5 seconds (2.5-4s = Needs Improvement, above 4s = Poor)
• INP Good threshold: under 200ms (200-500ms = Needs Improvement, above 500ms = Poor)
• CLS Good threshold: under 0.1 (0.1-0.25 = Needs Improvement, above 0.25 = Poor)
• Field data from CrUX (real user data) is what Google uses for ranking — not lab test scores
• Pass threshold: 75% of page visits must meet Good thresholds for a URL to pass Core Web Vitals
• PageSpeed Insights shows both lab (Lighthouse) and field (CrUX) data — optimise for field data

LCP Optimisation: Achieving Sub-2.5 Second Load Times

LCP is the Core Web Vital most commonly failing for Indian websites, primarily due to slow server response times, unoptimised images, and render-blocking JavaScript. The LCP element is almost always a hero image or above-the-fold heading — identifying your LCP element using PageSpeed Insights is the first step. For image-based LCP, the most impactful fixes are: serving images in WebP or AVIF format (40-60% smaller than JPEG at equivalent quality), ensuring the LCP image is not lazy-loaded (add fetchpriority='high' and loading='eager' to the LCP image element), and preloading the LCP image with a link rel='preload' tag in the document head. For server response time issues (Time to First Byte above 600ms), the fix is typically upgrading hosting or implementing a CDN. For Indian businesses, using a CDN with nodes in Mumbai, Bangalore, or Chennai reduces TTFB by 200-400ms for Indian visitors.

1. 1Identify your LCP element using the PageSpeed Insights Diagnose performance issues section
2. 2Convert LCP images to WebP or AVIF format using Squoosh, ImageOptim, or server-side conversion
3. 3Add fetchpriority='high' and remove any lazy loading from the LCP image element
4. 4Add a link rel='preload' as='image' tag in the document head pointing to the LCP image URL
5. 5Measure Time to First Byte — if above 600ms, upgrade hosting or add a CDN with Indian edge nodes
6. 6Implement Cloudflare or AWS CloudFront with Indian edge locations to reduce TTFB for Indian users
7. 7Remove render-blocking CSS and JavaScript that delays when the LCP element can start rendering

INP Optimisation: Improving Page Interactivity

INP (Interaction to Next Paint) became an official Core Web Vital in March 2024, replacing FID. INP is harder to optimise than LCP because it requires diagnosing JavaScript execution performance rather than simply reducing file sizes. Poor INP is almost always caused by long tasks — JavaScript tasks that run for more than 50ms on the main thread — excessive event listeners, or third-party scripts that block the main thread during user interactions. The primary diagnostic tool is Chrome DevTools' Performance panel — record a trace while interacting with the page and identify which tasks run when you click buttons, submit forms, or navigate. Common culprits include analytics scripts that run heavy processing on click events, poorly optimised React or Vue re-renders triggered by user interactions, and third-party chat widgets or ad scripts that monopolise the main thread. Fixes typically involve code splitting, deferring non-critical JavaScript, breaking up long tasks, and auditing third-party script impact.

• Use Chrome DevTools Performance panel to identify long tasks triggered by user interactions
• Break up long JavaScript tasks (50ms+) using setTimeout breaks or the scheduler.yield() API
• Audit third-party scripts (analytics, chat widgets, ad scripts) for main thread blocking
• Defer non-critical JavaScript with async or defer attributes
• Optimise React/Vue/Angular component re-renders triggered by user interactions
• Use web workers for CPU-intensive operations to move processing off the main thread
• Test INP improvements with real user testing tools like WebPageTest's INP measurement

CLS Optimisation: Eliminating Layout Shifts

Cumulative Layout Shift is caused by elements that change position or size after the initial page render, pushing other content around unexpectedly. The most common causes are: images without explicit width and height attributes (the browser does not reserve space before the image loads), ads inserted into the page without reserved space, web fonts that cause Flash of Unstyled Text or Flash of Invisible Text as they load, and dynamically injected content (banners, cookie notices, newsletter popups) that push page content down. For images, the fix is always adding explicit width and height attributes or using CSS aspect-ratio — this gives the browser the information it needs to reserve space before the image loads. For web fonts, use font-display: optional or font-display: swap with size-adjust property to minimise layout impact. For injected content, pre-reserve the space with min-height on the container before the content loads.

• Add explicit width and height attributes to all img elements — this prevents layout shift on load
• Use CSS aspect-ratio property for responsive images that cannot have fixed dimensions
• Use font-display: swap with size-adjust to minimise font swap layout shifts
• Pre-reserve space for ad slots and dynamically injected content with min-height CSS
• Ensure cookie banners and popups use position: fixed rather than pushing page content down
• Audit animations — only animate properties that do not trigger layout (use transform and opacity)
• Test CLS with PageSpeed Insights and identify the specific elements causing shifts

Image Optimisation: The Biggest LCP Win

Unoptimised images are responsible for poor LCP scores in the majority of failing websites. A comprehensive image optimisation strategy addresses format, compression, sizing, lazy loading, and delivery. Modern image formats — WebP reduces file size by 25-35% compared to JPEG at equivalent quality; AVIF reduces by 40-55% — should be used for all images served to modern browsers, with JPEG or PNG fallbacks for older browsers using the picture element. Compression should reduce file sizes without visible quality degradation — target under 100KB for standard content images and under 200KB for hero images. Images should be served at the exact display dimensions rather than relying on CSS to downscale large images. Lazy loading should be applied to all below-fold images, but critically never to the LCP image. A CDN with image transformation capabilities such as Cloudflare Images or Imgix enables automatic WebP serving and resize-on-delivery.

• Convert all images to WebP format — use the picture element for JPEG/PNG fallbacks
• Consider AVIF for the best possible compression ratios on modern browsers
• Compress images to under 100KB for content images, under 200KB for hero images
• Always specify correct width and height attributes on img elements
• Apply loading='lazy' to all below-fold images — never to the LCP image
• Use a CDN with automatic image format conversion and resize-on-delivery capability
• Audit image file sizes with PageSpeed Insights Serve images in next-gen formats opportunity

JavaScript and CSS Optimisation for Core Web Vitals

Render-blocking JavaScript and CSS are common causes of poor LCP and INP scores. Render-blocking resources are scripts and stylesheets that prevent the browser from rendering visible page content until they fully download and parse. Identify render-blocking resources using PageSpeed Insights' Eliminate render-blocking resources opportunity. Fixes include: adding async or defer attributes to non-critical JavaScript files, moving non-critical CSS to load asynchronously, implementing code splitting to load JavaScript only when needed, removing unused CSS using tools like PurgeCSS, and minifying both JavaScript and CSS to reduce parse time. For modern JavaScript frameworks (React, Vue, Next.js), server-side rendering or static site generation eliminates much of the JavaScript rendering bottleneck by delivering pre-rendered HTML. Each third-party script added to a site adds an average of 50-200ms of main thread blocking — audit and remove any scripts that do not directly contribute to user experience or revenue.

• Add defer attribute to all non-critical JavaScript — prevents render blocking without deferring execution
• Add async to analytics and third-party scripts that do not need to execute in order
• Remove unused CSS with PurgeCSS — unused CSS in large frameworks can add 100-500KB of parse overhead
• Minify JavaScript and CSS with Terser and CSSNano respectively
• Implement code splitting — load JavaScript modules only when the feature they power is needed
• Consider SSR or SSG for React/Vue/Angular sites to eliminate client-side rendering bottlenecks
• Audit and remove unnecessary third-party scripts — each adds main thread blocking time

Server Performance: TTFB and Hosting for Indian Sites

Time to First Byte (TTFB) — the time between a user's browser requesting a page and receiving the first byte of the response — is a root-cause metric that affects LCP. Google's recommended TTFB threshold is under 800ms; above 1,800ms is considered Poor. High TTFB is caused by slow server processing (database queries, server-side rendering overhead), geographic distance between user and server, or insufficient server resources. For Indian businesses, the most common TTFB issue is hosting on servers located in the US or Europe — adding 200-400ms of network latency for Indian users before any content loads. Switching to Indian data centre hosting (AWS ap-south-1 Mumbai, Google Cloud asia-south1 Mumbai) or implementing a CDN that caches full pages at Indian edge locations dramatically reduces TTFB. For dynamic sites, server-side caching with Redis or Varnish, or managed WordPress hosting from Kinsta or WP Engine, reduces database query overhead significantly.

• Measure TTFB using PageSpeed Insights, WebPageTest, or Chrome DevTools Network panel
• For Indian businesses, use Indian data centre hosting or CDN with Mumbai/Bangalore edge nodes
• Implement full-page caching to serve pre-built HTML rather than dynamically generating each request
• Optimise database queries — slow database responses are a common dynamic site TTFB cause
• Use Redis or Memcached for server-side caching of frequent database queries
• Consider managed WordPress hosting (Kinsta, WP Engine) for built-in performance infrastructure

Measuring and Monitoring Core Web Vitals

Continuous monitoring of Core Web Vitals is essential because performance regressions — caused by new content, plugin updates, or JavaScript additions — are common and can go undetected for weeks. The primary monitoring tools are: Google Search Console's Core Web Vitals report (field data aggregated from real user visits, updated weekly), PageSpeed Insights (combines field data from CrUX with lab data from Lighthouse), and the Chrome User Experience Report (CrUX) accessed via the CrUX API or BigQuery for granular URL-level data. For automated regression alerting, set up Lighthouse CI in your deployment pipeline to fail builds that cause Core Web Vitals regressions. WebPageTest provides the most detailed waterfall diagrams for root-cause diagnosis. Schedule a monthly Core Web Vitals review using Search Console data and use PageSpeed Insights to diagnose any URLs showing field data regressions.

• Monitor Google Search Console Core Web Vitals report weekly for field data performance
• Use PageSpeed Insights for individual URL diagnosis — test both mobile and desktop
• Set up Lighthouse CI in your CI/CD pipeline to catch performance regressions before deployment
• Use WebPageTest for detailed waterfall analysis when diagnosing root causes
• Access CrUX data via the PageSpeed Insights API for automated monitoring across multiple URLs
• Set performance budgets and alert when any metric falls below Good thresholds