How to Optimize Core Web Vitals: LCP, INP and CLS Explained

What Are Core Web Vitals?

Core Web Vitals are a set of metrics defined by Google that measure the real user experience of a web page. Since 2021, they have been a ranking factor in Google search results, meaning a slow or unstable website can lose positions to faster competitors.

The three metrics that make up Core Web Vitals measure different aspects of user experience: perceived loading speed (LCP), responsiveness to interactions (INP, which replaced FID in March 2024), and visual stability (CLS). Together, they provide a holistic picture of how users perceive your website's performance.

It's important to understand that Core Web Vitals are measured with field data (Real User Metrics or RUM), not lab data. Google collects data from real Chrome users through the Chrome User Experience Report (CrUX) and aggregates it at the page level over a 28-day period. This means the metrics reflect the actual experience of your users on their real devices and connections, not the ideal conditions of your development machine.

Each metric has three thresholds: "Good" (green, the target to achieve), "Needs Improvement" (yellow, requires attention), and "Poor" (red, needs urgent improvements). Google considers a page to pass Core Web Vitals when the 75th percentile of all page loads is in the "Good" range for all three metrics.

LCP (Largest Contentful Paint): Perceived Loading Speed

LCP measures the time it takes for the largest visible content element in the viewport to render. This element is typically a hero image, main heading, video, or large text block. LCP answers the question: "How long does it take for the main content to be visible to the user?"

Thresholds: Good: under 2.5 seconds. Needs Improvement: between 2.5 and 4 seconds. Poor: over 4 seconds.

Factors Affecting LCP

LCP depends on four main factors: server response time (TTFB), resource download time (images, fonts, CSS), CSS rendering time, and render-blocking JavaScript loading time. Optimizing LCP requires addressing each of these factors.

LCP Optimization Strategies

Optimize TTFB: Use a CDN to serve static content from servers close to the user. Implement server-side rendering (SSR) or static site generation (SSG) to reduce HTML generation time. Optimize database queries and use server caching (Redis, Memcached) for frequent responses. A TTFB under 800ms is the goal.

Prioritize the LCP resource: Identify what the LCP element is on your page (usually the hero image or main heading) and prioritize its loading. Use <link rel="preload"> for the LCP image, add fetchpriority="high" to the img tag, and avoid loading="lazy" on the LCP image (use it only for below-the-fold images).

Optimize images: Use modern formats like WebP or AVIF that offer better compression than JPEG/PNG. Serve responsive images with srcset so each device downloads only the size it needs. For the LCP image, consider using a fixed size optimized for your users' most common viewport.

Eliminate render-blocking JavaScript: Synchronous JavaScript in the head blocks HTML rendering. Use defer or async for non-critical scripts, and move non-essential JavaScript to the end of the body. For frameworks like React/Next.js, JavaScript hydration can delay LCP; consider selective hydration or partial hydration with frameworks like Astro.

Optimize web fonts: Custom fonts can significantly delay text rendering. Use font-display: swap to display text with a fallback font while the custom font loads, preload critical fonts, and use size-adjust to minimize layout shift when the custom font loads.

INP (Interaction to Next Paint): Responsiveness

INP replaced FID (First Input Delay) as a Core Web Vital metric in March 2024. While FID only measured the delay of the first interaction, INP measures the latency of all user interactions throughout the entire page visit: clicks, taps, and key presses. The INP value is the 98th percentile of all interaction latencies, or the worst latency if there are fewer than 50 interactions.

Thresholds: Good: under 200 milliseconds. Needs Improvement: between 200 and 500 milliseconds. Poor: over 500 milliseconds.

Why Is INP More Important Than FID?

FID only measured the delay before the browser started processing the first interaction, but didn't measure the time it took for the interaction to produce a visual result. INP measures the complete latency: from when the user interacts until the browser paints the next frame with the result. This captures problems that FID completely ignored, such as slow event handlers, layout thrashing, and expensive DOM updates.

INP Optimization Strategies

Reduce main thread work: The browser can only do one thing at a time on the main thread: execute JavaScript, calculate styles, perform layout, or paint. If the main thread is busy executing heavy JavaScript, user interactions are queued and responses are delayed. Identify and optimize long tasks (over 50ms) using Chrome DevTools' Performance tab.

Break up long tasks: Use scheduler.yield() or setTimeout to split long tasks into smaller chunks that allow the browser to process user interactions in between. This is especially important during page initialization and in complex event handlers.

Optimize event handlers: Event handlers that do heavy synchronous work (expensive calculations, massive DOM updates, synchronous network calls) are the main cause of high INP. Move heavy work to Web Workers, use debouncing for frequent events, and update only the parts of the DOM that actually changed.

Reduce total JavaScript: Less JavaScript means less parsing, compilation, and execution. Audit your dependencies, remove the ones you don't use, and consider lighter alternatives. Every kilobyte of JavaScript you remove directly improves INP.

CLS (Cumulative Layout Shift): Visual Stability

CLS measures the cumulative visual instability throughout the page's lifetime. Every time a visible element unexpectedly changes position (without user interaction), a layout shift is recorded. CLS is the sum of all these unexpected shifts. A high CLS means the page "jumps around" while the user tries to read or interact with it.

Thresholds: Good: under 0.1. Needs Improvement: between 0.1 and 0.25. Poor: over 0.25.

Common Causes of CLS

Images without dimensions: When an image doesn't have width and height attributes, the browser doesn't know how much space to reserve. When the image loads, it pushes surrounding content, causing a layout shift. Always include width and height on img tags, or use CSS aspect-ratio to reserve the space.

Ads and embeds: Ads that load asynchronously without a fixed-size container are one of the main causes of CLS. Reserve space for ads with a fixed-dimension container, even if the ad hasn't loaded yet. The same applies to video embeds, iframes, and third-party widgets.

Web fonts: When a custom font loads and replaces the fallback font, text can change size and cause a layout shift. Use font-display: optional or font-display: swap with size-adjust to minimize the metric difference between the fallback and custom font.

Dynamically injected content: Cookie banners, notifications, ad bars, and asynchronously loaded content inserted above existing content cause layout shifts. To avoid this, reserve space for these elements or insert them below existing content instead of above.

CLS Optimization Strategies

The general rule is: reserve space for everything that will appear. If you know an image will be 600x400px, reserve that space before the image loads. If you know an ad will take up 300x250px, create a container of that size. If a cookie banner will appear at the bottom, reserve space or use position: fixed so it doesn't displace content.

Use the Layout Shift Regions tool in Chrome DevTools to visualize exactly which elements are moving and causing CLS. This allows you to quickly identify the source of layout shifts and take specific corrective actions.

Tools for Measuring Core Web Vitals

Field Tools (Real Data)

Google Search Console: The "Core Web Vitals" section shows the performance of your URLs grouped by status (Good, Needs Improvement, Poor) based on real Chrome user data. It's the most important source because it reflects exactly what Google sees for ranking.

PageSpeed Insights: Combines field data (CrUX) with a lab analysis (Lighthouse) for a specific URL. It provides specific, prioritized recommendations to improve each metric.

Chrome UX Report (CrUX): Public database with real performance metrics for millions of URLs. You can query it directly via BigQuery or use the CrUX API to get data programmatically.

web-vitals library: Google's official library for measuring Core Web Vitals in your own application. Install it to send metrics to your analytics system and monitor performance in real time.

Lab Tools (Local Testing)

Lighthouse: Built into Chrome DevTools (Lighthouse tab), it provides a comprehensive analysis of performance, accessibility, SEO, and best practices. It generates a report with scores and actionable recommendations.

Chrome DevTools Performance tab: The most powerful tool for performance debugging. Record a usage session and analyze every millisecond in detail: main thread tasks, rendering, painting, layout, and LCP, CLS, and INP events.

WebPageTest: Online tool that allows you to test your site from multiple locations, devices, and connection speeds. It provides detailed waterfall charts, loading videos, and advanced metrics.

Conclusion

Optimizing Core Web Vitals is not just an SEO exercise; it's a real improvement to your users' experience. A website that loads fast (LCP), responds instantly to interactions (INP), and doesn't visually jump around (CLS) generates more trust, more engagement, and more conversions.

Start by measuring: check your metrics in Google Search Console, identify the worst-performing pages, and tackle the most impactful problems first. Typically, optimizing images and reducing JavaScript produce the biggest improvements with the least effort. Performance optimization is an ongoing process, not a one-time project: integrate Core Web Vitals measurement into your CI/CD pipeline to catch regressions before they reach production.