Static Site Generators in Production

Measuring LCP Subparts with DevTools

Largest Contentful Paint is one number, but it is made of four very different parts. A 3-second LCP might be a slow server, an image that was discovered late, a large image that took long to download, or an image that downloaded quickly but waited for a script before it could paint. Each needs a different fix, and optimising the wrong one wastes a sprint. Splitting LCP into its subparts turns "LCP is slow" into "the hero waited 900 milliseconds to start downloading", which has an obvious remedy.

This guide shows where to read the subparts in Chrome DevTools and Lighthouse, how to collect them from real users, and what each pattern usually means on a static site. It is part of Largest Contentful Paint Optimization for Static Sites.

Prerequisites

  • Chrome 129 or later for the LCP breakdown in the Performance panel.
  • A page whose LCP you want to improve, ideally with field data showing it is slow.
  • Optional: the web-vitals library installed for field measurement.

The Four Subparts

LCP is measured from navigation start to the moment the largest element in the viewport is painted. That span divides cleanly into four consecutive phases:

The four subparts of Largest Contentful Paint A horizontal bar from navigation start to LCP split into four segments: time to first byte until the HTML's first byte arrives, resource load delay until the LCP image request starts, resource load duration until the image finishes downloading, and element render delay until it is painted. LCP = TTFB + load delay + load duration + render delay TTFB load delay load duration render delay server, CDN, redirects late discovery, lazy, low priority file size, format, bandwidth contention blocking CSS/JS, fonts, animations navigation start LCP painted healthy target: TTFB ≈ 40%, load duration ≈ 40%, each delay under 10%
The two delays are waste; the other two are real work that can only be made smaller.
  1. Time to first byte (TTFB). From navigation start until the first byte of HTML arrives. Includes redirects, DNS, connection setup and server or CDN response time.
  2. Resource load delay. From TTFB until the browser starts requesting the LCP resource. Zero for text elements.
  3. Resource load duration. How long the LCP image or video poster takes to download. Zero for text elements.
  4. Element render delay. From the end of the download (or TTFB, for text) until the element is painted.

The two delays are waiting time: nothing useful happens for the LCP element during them. TTFB and load duration are real work that can be made faster but never removed.

Reading the Breakdown in DevTools

Open the Performance panel. The live metrics view shows LCP for the current page along with the element; interact with nothing and reload. Then click record, reload, and stop once the page settles. In the Insights sidebar, open LCP breakdown. It lists the four phases with durations and highlights the LCP element in the trace.

Emulate a realistic device first. The default desktop profile hides most problems, so choose a mobile device, set CPU throttling to 4× and network to "Fast 4G", or use the field data calibration that the live metrics view suggests when CrUX data is available for your origin.

Lighthouse reports the same breakdown under the Largest Contentful Paint element audit, with a table of the four phases. It is useful in CI, where you can track each phase over time rather than only the total; see Setting Up Lighthouse CI for a Static Site.

Common Patterns on Static Sites

Once you have the four numbers, the dominant phase usually points straight at the cause.

Four LCP breakdowns and what they indicate Four stacked bars. A slow TTFB bar with a large first segment indicates a CDN miss or redirects. A large load delay bar indicates a lazy or CSS background hero. A large load duration bar indicates an oversized image. A large render delay bar indicates render-blocking CSS, a font or a client-rendered hero. Which subpart dominates, and the usual cause CDN miss, redirect chain lazy or background-image hero oversized image blocking CSS, font, JS render segment order: TTFB, load delay, load duration, render delay
Each shape has a different fix; the breakdown tells you which one to reach for.

Long TTFB. On a static site, the HTML should come from a CDN edge in well under 200 milliseconds. Long TTFB usually means the HTML is not cached at the edge, there are redirects (such as http to https to www to a trailing slash), or the cache is being bypassed by query strings. See CDN Caching Rules for SSGs.

Long resource load delay. The browser found the image late. Causes: loading="lazy" on the hero, the hero set as a CSS background-image, the image inserted by JavaScript, or a low fetch priority behind other images. Fixes: an eager <img> in the HTML with fetchpriority="high", or a preload for background images. See Lazy-Loading Images Without Hurting LCP.

Long resource load duration. The file is too big for the connection, or it shares bandwidth with many other early requests. Fixes: responsive widths, AVIF or WebP, and fewer competing requests early in the load.

Long render delay. The image arrived but could not paint. Causes: render-blocking stylesheets still downloading, a web font blocking text for text LCP elements, a hero that fades in from zero opacity, or client-side rendering that inserts the element after hydration. See Eliminating Render-Blocking CSS on Static Sites.

Collecting Subparts From Real Users

Lab traces show one device on one connection. Field data shows which subpart dominates for your actual readers, and it can differ. The attribution build of web-vitals reports all four values:

import { onLCP } from 'web-vitals/attribution';

onLCP(({ value, attribution }) => {
  navigator.sendBeacon('/rum', JSON.stringify({
    metric: 'LCP',
    value,
    page: location.pathname,
    element: attribution.target,
    ttfb: attribution.timeToFirstByte,
    loadDelay: attribution.resourceLoadDelay,
    loadDuration: attribution.resourceLoadDuration,
    renderDelay: attribution.elementRenderDelay,
  }));
});

Aggregate by template and look at the 75th percentile of each subpart for pages whose LCP is poor. That tells you which fix will move the needle for the pages that matter. The dashboard side is covered in Building a Core Web Vitals Dashboard from RUM Data.

Worked Example

A product documentation site had a mobile LCP p75 of 3.2 seconds on its landing pages. The lab breakdown on a throttled phone showed TTFB 310 ms, load delay 1,080 ms, load duration 620 ms and render delay 140 ms. Load delay dominated, so the team looked for late discovery and found the hero set as a CSS background-image on a section element. The browser could only find it after downloading and parsing the stylesheet.

Replacing the background with an <img> carrying fetchpriority="high" cut the load delay to 60 ms. Nothing else on the page changed, which is what made the breakdown useful: the total improved by almost exactly the amount the one subpart shrank, confirming the diagnosis.

Lab LCP breakdown before and after moving the hero out of CSS Before: TTFB 310 milliseconds, load delay 1080, load duration 620, render delay 140, total 2150. After: TTFB 310, load delay 60, load duration 620, render delay 140, total 1130. Lab breakdown, throttled phone (ms) before 2,150 load delay 1,080 after 1,130 TTFB 310 · load duration 620 · render delay 140 unchanged in both runs
Only one subpart moved, and the total moved with it.

The lab result was a prediction; the field was the test. Because field LCP includes slower phones, worse networks and CDN misses, the team expected a smaller gain in the field than in the lab, and tracked the load delay subpart in their RUM data to confirm the change reached real readers.

Field data four weeks later showed LCP p75 of 2.1 seconds, with the remaining time split roughly evenly between TTFB and load duration — the healthy shape. A second round of work on image sizes then took it to 1.8 seconds.

Pitfalls & Rollback

  • Measuring on desktop only. Subparts shift dramatically under throttling; always check a mobile profile.
  • Changing LCP elements. If a fix changes which element is largest, the breakdown now describes a different element; re-check which one it is.
  • Ignoring text LCP. On text-heavy pages, all time after TTFB is render delay; fonts and CSS are the levers, not images. See Fixing LCP on Text-Heavy Documentation Pages.
  • Cached repeat views. Test cold loads; warm caches hide load delay and duration.
  • Rollback: measurement changes nothing on the page; remove the RUM snippet if it is no longer needed.

Conclusion

LCP subparts turn a single slow number into a diagnosis. Read them in the DevTools Performance panel or Lighthouse for a quick lab view, collect them with the web-vitals attribution build for the real picture, and fix the phase that dominates: caching and redirects for TTFB, discovery and priority for load delay, file size for load duration, and blocking resources for render delay. The goal is a breakdown with almost no waiting time in it.

FAQ

What are the four LCP subparts?

Time to first byte, resource load delay, resource load duration and element render delay. They add up to the full LCP time. For text LCP elements with no resource to load, the two resource phases are zero and the time after TTFB is all render delay.

Where do I see LCP subparts in Chrome DevTools?

In the Performance panel, the live metrics view and a recorded trace both show an LCP breakdown insight with the four phases for the current LCP element. The same breakdown appears in Lighthouse under the Largest Contentful Paint element audit.

What is a good split between the subparts?

As a rough guide, TTFB and load duration should each take about 40 percent of LCP, and load delay and render delay should each be under 10 percent. Large load delay or render delay usually point to fixable problems in the page rather than the network.

How do I collect LCP subparts from real users?

Use the attribution build of the web-vitals library. Its onLCP callback reports timeToFirstByte, resourceLoadDelay, resourceLoadDuration and elementRenderDelay along with the LCP element selector, which you can send to your analytics endpoint.