Core Web Vitals Explained: LCP, INP, and CLS Deep Dive

Core Web Vitals are Google's standardized set of metrics that quantify real-world user experience on the web. Introduced in 2020 and continuously refined, these metrics measure the three pillars of page experience: loading performance, interactivity, and visual stability. Since their integration into Google's ranking algorithm, they have become essential benchmarks for any engineering team serious about web performance.

This guide breaks down each of the three current Core Web Vitals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — with the depth required to move from understanding to optimization. Whether you are working with lab data during development or analyzing field data from the Chrome User Experience Report, the concepts here form the foundation for every performance improvement decision.

The Three Pillars of User Experience

Each Core Web Vital targets a distinct dimension of the user's perception. Loading speed is captured by LCP, which measures how quickly the main content becomes visible. Responsiveness is captured by INP, which tracks how fast the page reacts to user input. Visual stability is captured by CLS, which penalizes unexpected layout movements that disorient users.

Google evaluates these metrics at the 75th percentile (p75) of page loads over a 28-day rolling window. This means at least 75% of your visitors must experience values within the "Good" threshold for your page to pass. The p75 approach deliberately weights the metric toward the slower end of real-world conditions — users on mid-range Android devices, on cellular networks, in regions with higher latency.

Largest Contentful Paint (LCP): Loading Performance

LCP measures the render time of the largest image or text block visible within the viewport, relative to when the page first started loading. It is the most intuitive of the three vitals — it answers the question users implicitly ask: "Is the page loaded yet?"

What Qualifies as an LCP Element

The browser identifies the LCP element by tracking the largest content element as it appears in the viewport. Candidate elements include:

• <img> elements (the rendered size, not the intrinsic size)
• <image> elements inside an SVG
• <video> poster images (or the first frame when no poster is set)
• Block-level elements containing text nodes (paragraphs, headings)
• Elements with a CSS background-image loaded via url()

The LCP candidate can change as the page loads. A heading might initially be the largest element, but once a hero image finishes loading and renders at a larger size, the browser updates the LCP candidate. The final LCP value is recorded when the user first interacts with the page (tap, scroll, or keypress) or when the page finishes loading completely.

LCP Sub-Parts

LCP can be decomposed into four sequential phases, and optimizing each one requires different strategies. For a detailed breakdown, see our complete LCP optimization guide.

The most common LCP bottleneck is TTFB — the time the server takes to begin sending the HTML response. This is why optimizing server response time is often the single highest-impact change for LCP improvement. CDN deployment, efficient server-side rendering, and database query optimization all contribute directly to reducing TTFB.

Common LCP Pitfalls

Several patterns consistently produce poor LCP scores despite appearing harmless:

• Lazy-loading the LCP image: The loading="lazy" attribute defers loading until the element nears the viewport. When applied to the hero image (often the LCP element), it delays loading until scroll or interaction — exactly the opposite of what LCP measures.
• CSS background images without preload: The browser cannot discover a CSS background image until it parses the stylesheet. Adding <link rel="preload" as="image"> in the document head allows parallel discovery.
• Client-side rendering of above-the-fold content: SPAs that render their initial content via JavaScript force the browser to download, parse, and execute JS before any LCP candidate appears.
• Render-blocking third-party scripts: Synchronous scripts in the <head> delay parsing of the HTML body, which delays discovery and rendering of LCP elements.

Interaction to Next Paint (INP): Responsiveness

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. While FID measured only the delay of the first interaction, INP tracks all interactions throughout the page lifecycle and reports a value representative of the worst interactions — specifically, the interaction at the 98th percentile (or the second-worst interaction, whichever is higher on pages with fewer than 50 interactions).

An "interaction" in the INP model is a discrete user gesture: a click, a tap, or a key press. Scrolling is explicitly excluded because it is handled by the browser's compositor thread and does not engage the main thread in the same way. For an in-depth exploration of INP measurement and optimization, see our INP guide.

The Three Phases of an Interaction

Every interaction passes through three measurable phases:

1. Input Delay: The time from the user's physical input to the start of the first event handler. This is dominated by main-thread contention — if a long JavaScript task is running when the user taps, the browser cannot process the input until that task yields.
2. Processing Time: The time spent executing all event handlers associated with the interaction (e.g., pointerdown, pointerup, click). Expensive computations, synchronous DOM manipulations, and blocking network calls during handlers inflate this phase.
3. Presentation Delay: The time from the last event handler's completion to the browser painting the next frame. This includes style recalculation, layout computation, and compositing — work triggered by the DOM changes made during processing.

Why INP Is Harder Than FID

FID was relatively easy to pass because it measured only the first interaction's input delay, and most pages had a quiet main thread by the time the user made their first tap. INP raises the bar dramatically:

• It includes interactions later in the page lifecycle, when JavaScript from analytics, ads, and deferred scripts has loaded
• It measures end-to-end latency (input delay + processing + presentation), not just input delay
• It selects a near-worst interaction, not the first one

Pages that passed FID comfortably can fail INP because their event handlers trigger expensive layout recalculations or because third-party scripts occupy the main thread during mid-session interactions. Understanding error tracking patterns can help identify which interactions are failing and under what conditions.

Cumulative Layout Shift (CLS): Visual Stability

CLS quantifies how much visible content shifts unexpectedly during a page's lifetime. The score is unitless — it's calculated by multiplying the fraction of the viewport that shifted (impact fraction) by the distance the elements moved (distance fraction). A CLS of 0.1 means roughly 10% of the viewport shifted by 10% of the viewport height — or any equivalent combination.

For strategies to prevent layout shifts in practice, our CLS prevention guide covers every common cause and its fix.

Session Windows

CLS does not simply sum every layout shift across the entire page visit. Instead, it uses a "session window" model: consecutive layout shifts are grouped into windows of at most 5 seconds each, with no more than 1 second between any two shifts. The page's CLS score is the largest session window's total shift score.

This windowing approach was introduced to prevent long-lived single-page applications from accumulating arbitrarily high CLS scores. A page that loads cleanly, shifts slightly during a route transition, then stabilizes again will only report the worst single window — not the sum of all windows.

What Causes Layout Shifts

Layout shifts are triggered whenever a visible element changes its start position between two frames without being initiated by user input. Common causes include:

• Images and iframes without dimensions: When the browser encounters an <img> without width and height attributes, it allocates zero space initially, then expands the element when the image loads — pushing subsequent content downward.
• Dynamically injected content: Ad slots, cookie banners, notification bars, and late-loading embeds that insert themselves above existing content.
• Web fonts causing FOUT: When a web font loads and replaces the fallback font, differences in font metrics (x-height, character width) cause text to reflow.
• Animations that trigger layout: CSS animations that change properties like height, width, top, or left instead of transform cause the browser to recalculate layout on every frame.

Field Data vs. Lab Data

Understanding the distinction between field data and lab data is critical for interpreting Core Web Vitals correctly.

Lab data comes from synthetic testing tools like Lighthouse, WebPageTest, or Chrome DevTools' Performance panel. These run in a controlled environment — fixed device emulation, fixed network throttling, no real user interaction. Lab data is useful for debugging specific issues and validating changes before deployment, but it does not capture the full diversity of real-world conditions.

Field data comes from real users visiting your site, collected via the Chrome User Experience Report (CrUX) or through Real User Monitoring (RUM) libraries like the web-vitals JavaScript library. Field data reflects actual device capabilities, network conditions, and user behavior patterns. It is the authoritative source for Google's ranking signals.

Our PageSpeed Insights guide explains how to interpret both data sources and prioritize optimization based on real-world impact. For proactive detection before real users are affected, synthetic monitoring provides continuous lab-like testing from distributed global locations.

Chrome User Experience Report (CrUX)

CrUX is Google's public dataset of real user experience metrics, collected from Chrome users who have opted in to syncing their browsing history and usage statistics. It provides origin-level and URL-level data for sites with sufficient traffic.

CrUX data powers the "field data" section of PageSpeed Insights and is accessible via the CrUX API, BigQuery dataset, and the CrUX Dashboard. The dataset updates monthly (with a 28-day collection window) and includes metrics for LCP, INP, CLS, TTFB, FCP, and more.

Limitations of CrUX

• Chrome-only: CrUX collects data exclusively from Chrome browsers. Safari, Firefox, and other browsers are not represented.
• Traffic threshold: Pages or origins with low traffic may not appear in the dataset.
• Opt-in population: The data comes from users with usage statistics reporting enabled, which may skew slightly toward more engaged or technical users.
• Granularity: CrUX reports at the origin or URL level. You cannot segment by user agent, geography, or device type through CrUX alone — RUM tools provide that granularity.

Measurement Tools and Implementation

There are multiple ways to measure Core Web Vitals, each suited to different stages of your workflow:

• Chrome DevTools Performance Panel: Records a timeline of the page load and interactions, visualizing LCP, CLS events, and long tasks that contribute to poor INP. Best for debugging individual issues.
• Lighthouse (via DevTools or CI): Provides a lab-based performance audit with specific optimization recommendations. Useful for automated testing in CI/CD pipelines.
• PageSpeed Insights: Combines CrUX field data with a fresh Lighthouse lab audit. The single most comprehensive view of a page's vital status.
• web-vitals JavaScript library: A lightweight library (under 2KB gzipped) that reports LCP, INP, and CLS values from real users. Integrating it with your analytics pipeline gives you continuous field data independent of CrUX.
• Search Console Core Web Vitals report: Groups your site's URLs by status (Good, Needs Improvement, Poor) and tracks trends over time. Useful for identifying patterns across large sites.

For teams operating at scale, integrating Application Performance Monitoring (APM) with frontend performance metrics creates a full-stack view — correlating backend latency with the LCP and INP degradation users actually experience.

Optimization Priority Framework

Not all Core Web Vitals failures deserve equal attention. A pragmatic optimization sequence considers both impact and effort:

1. Fix CLS first: CLS issues are usually caused by missing image dimensions or late-injected content. Fixes are often CSS-only (adding aspect-ratio or explicit width/height) and can be deployed quickly with immediate impact.
2. Tackle LCP second: LCP improvements often require server infrastructure changes (CDN deployment, caching strategy, image optimization pipeline). The sub-parts analysis tells you exactly where time is being lost.
3. Address INP last: INP optimization frequently involves JavaScript architecture changes — breaking up long tasks, debouncing event handlers, offloading computation to Web Workers. These require the most code changes and testing.

This ordering reflects a general pattern: CLS fixes have the highest ROI per engineering hour, while INP fixes require the deepest changes but often produce the largest perceived improvement in user experience.

Beyond Core Web Vitals

While LCP, INP, and CLS are the three current Core Web Vitals, Google also tracks supplemental metrics that influence overall page experience:

• First Contentful Paint (FCP): Measures when the first text or image is painted. A fast FCP reassures users that the page is loading.
• Time to First Byte (TTFB): A diagnostic metric that measures server responsiveness. High TTFB almost always means high LCP.
• First Input Delay (FID): The former interactivity metric, now replaced by INP. Still reported in some tools for backward compatibility.

Google has stated that Core Web Vitals will continue evolving as new metrics and measurement capabilities emerge. Staying current requires monitoring both the official web.dev documentation and the Chrome Platform Status page for upcoming changes.

Key Takeaways

• Core Web Vitals measure three dimensions of user experience: loading (LCP ≤ 2.5s), interactivity (INP ≤ 200ms), and stability (CLS ≤ 0.1)
• All metrics are evaluated at the 75th percentile over a 28-day window of real-user data
• LCP is decomposed into four sub-parts — TTFB, resource load delay, resource load duration, and element render delay
• INP replaced FID and is significantly harder to pass because it measures all interactions end-to-end
• CLS uses session windows to prevent unfair penalization of long-lived pages
• Field data (CrUX, RUM) determines rankings; lab data (Lighthouse) is for debugging
• Optimize in order: CLS (quick wins) → LCP (infrastructure) → INP (JavaScript architecture)