View contents
Core Web Vitals Technical Guide: LCP, CLS, and INP Broken Down
Introduction
Knowing that the LCP threshold is 2.5 seconds doesn't tell you what to fix when your page exceeds it. This guide breaks each Core Web Vital down into its measurable technical sub-components—the same ones Chrome DevTools and the Lighthouse report use—so you can diagnose the root cause instead of guessing. The UXR SEO Analyzer reports these three metrics in its "Performance" tab, but this technical breakdown is what lets you decide which guide in our Performance Technical Hub to apply first.
Each Core Web Vital is measured differently—LCP and INP are timing metrics, CLS is a unitless movement score—so a single generic fix rarely improves all three at once. Treating each subpart as its own diagnostic question is what separates targeted optimization from guesswork.
LCP: Four Measurable Subparts
According to Chrome's performance insights documentation, total Largest Contentful Paint time breaks down into four subparts. Ideally, most of the LCP time should be spent loading resources, not sitting in delays:
| Subpart | What it measures |
|---|---|
| TTFB | From when the user initiates loading until the browser receives the first byte of the HTML |
| Resource load delay | The time between TTFB and when the browser starts loading the LCP resource (0 if the element doesn't require a resource, e.g. a text node with a system font) |
| Resource load duration | How long the LCP resource itself takes to load (0 if it doesn't require a resource load) |
| Element render delay | The time between the resource finishing its load and the LCP element rendering fully |
The target is an LCP of 2.5 seconds or better, reducing each phase—especially the delay phases, which add no value for the user. A slow LCP with high TTFB points at the server; a high load delay usually means the resource wasn't discovered early (a missing <link rel="preload">, or the resource hidden behind JavaScript).
CLS: The Layout Shift Formula
Unlike LCP and INP, CLS doesn't measure time—it measures visual movement. Each layout shift score is calculated as:
Layout Shift Score = Impact Fraction × Distance Fraction
Impact Fraction: percentage of the viewport affected by the shift
Distance Fraction: how far elements moved (as % of the viewport)
Example: an element covering 50% of the viewport (impact fraction = 0.5) that moves 25% of the viewport height (distance fraction = 0.25) produces a score of 0.5 × 0.25 = 0.125.
Layout shifts caused by user interaction, or occurring within 500ms of a user input, don't count toward CLS. CSS transform animations also don't trigger a layout shift, since they don't affect document flow.
INP: Three Interaction Subparts
INP also breaks down into three subparts, measured on the page's slowest interaction:
| Subpart | What it indicates when high |
|---|---|
| Input delay | The interaction was delayed by other main thread work—the interaction itself may not be the direct cause |
| Processing duration | The interaction's event handler was the direct cause of the slow INP |
| Presentation delay | There was a rendering delay in displaying the result of the interaction after the event handler finished running |
Chrome DevTools recommends focusing on reducing the slowest phase, and trying several different interactions while recording a trace to understand what contributes most to a page's INP. Enabling CPU throttling in DevTools helps diagnose slow interactions as they would appear on less powerful devices.
Common Diagnosis Mistakes
These are the most frequent mistakes when interpreting a Core Web Vitals breakdown:
Optimizing the wrong LCP phase
It's common to spend hours compressing an image (reducing resource load duration) when the real problem is render delay—for example, because the LCP element is hidden behind a web font that hasn't loaded yet, or because JavaScript must run before the browser can paint the element.
Confusing cumulative CLS with a single event
The CLS score a tool reports is the sum of all qualifying layout shifts during the page session (grouped into session windows), not a single event. A high score can come from many small shifts rather than one large one.
Optimizing INP by looking only at the average
INP is calculated on the slowest interaction of the user's session (or close to the highest percentile in field aggregates), not the average of all interactions. A single slow interaction—like opening a menu with a heavy listener—can define the whole page's INP even if everything else responds instantly.
Lab Data vs. Field Data
The LCP and INP breakdowns shown in Chrome DevTools' Performance panel come from lab data: a single page load under controlled conditions. Field data—reported by CrUX and Search Console—aggregates thousands of real sessions across varied devices and networks. A lab breakdown is ideal for debugging a specific cause; field data is what determines whether your page meets the "Good" threshold for 75% of real users, which is the criterion Google uses for ranking.
How These Breakdowns Connect to Our Guides
- High TTFB in LCP → see the Server Response Guide
- High load delay or render delay in LCP → see Render-Blocking Resources Explained and the Critical CSS Guide
- High processing duration in INP → see the JavaScript Performance Guide
Reference Thresholds
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5s - 4.0s | > 4.0s |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
| INP | ≤ 200ms | 200ms - 500ms | > 500ms |
A Practical Diagnosis Example
Suppose a product page reports an LCP of 4.2 seconds—in the "Poor" zone. The breakdown shows: TTFB 300ms, resource load delay 2100ms, load duration 900ms, render delay 900ms. TTFB is fine; the obvious problem is the 2.1-second load delay, nearly half the total time.
That pattern almost always means the browser didn't discover the product image until late—typically because it's loaded via JavaScript after hydration, or because a blocking web font delayed parsing of the CSS that references it. The fix isn't compressing the image (that would only shrink the 900ms load duration); it's moving discovery earlier with a <link rel="preload"> in the <head>, or rendering the image in the initial HTML instead of injecting it with JavaScript.
How to Measure Each Breakdown
Chrome DevTools' Performance panel shows the LCP and INP breakdown directly on the timeline marker when you record a trace. The web-vitals JavaScript library exposes these same sub-components in production through its attribution API, letting you send the breakdown to your analytics system instead of just the final number.
Frequently Asked Questions
Why is my LCP slow if the resource downloads quickly?
Check the load delay and render delay. A resource that downloads quickly but is discovered late—because it's hidden behind JavaScript or missing a preload—still produces a slow LCP.
Can CLS be negative?
No. The score is always positive or zero; it accumulates over the page's lifetime within the session windows defined by the CLS algorithm.
How do I know if my slow INP is a JavaScript problem or a rendering problem?
The breakdown tells you directly: high processing duration points at your code; high presentation delay points at the rendering work that follows (style, layout, paint).
Do these breakdowns apply the same way on mobile and desktop?
The subparts are the same, but the numbers usually aren't. Mobile devices typically show higher input delay and processing duration because of slower CPUs, and higher TTFB on cellular networks. Always diagnose and test on the device class your real users use most, not just desktop.
Related Guides
References
- Chrome Developers - LCP breakdown
- Chrome Developers - INP breakdown
- web.dev - Cumulative Layout Shift (CLS)
- Chrome Developers - CrUX methodology: metrics