LCP Subparts: Where Your Load Time Actually Goes

LCP is a sum, not a measurement

The threshold is well known: sites should strive for an LCP of 2.5 seconds or less for at least 75% of page visits (web.dev, Optimize Largest Contentful Paint). Around 40% of sites in the Chrome UX Report miss this recommended threshold (web.dev, The most effective ways to improve Core Web Vitals). What the target keeps quiet about is the composition. Two pages with an identical LCP of 3.8 seconds can have completely different problems and therefore need completely different measures.

The device split shows how widespread the issue is: in the 2025 Web Almanac, 74% of desktop pages and 62% of mobile pages achieve a good LCP, while poor values occur on mobile at 13% — nearly double the desktop rate of 7% (HTTP Archive, Web Almanac 2025, Performance). That distribution only tells you how many pages have a problem, though, not which one.

The specification supplies the building blocks for the answer. The LargestContentfulPaint interface exposes loadTime, renderTime, size, url and element, among others (W3C, Largest Contentful Paint, Working Draft of 13 July 2026). Combined with navigation and resource timing data, these timestamps let you reconstruct when the browser received the first byte of the document, when it requested the LCP resource, when that download finished and when the element finally rendered.

Chrome explicitly names these four sections LCP breakdown in its performance insights and states the rule concisely: reduce the time of each phase as much as possible, especially the delay phases; most of the LCP time should be spent loading resources, not sitting in delays (Chrome for Developers, LCP breakdown). That rule is the core of the whole topic.

The four subparts in detail

The four sections run back to back: each begins where the previous one ends, and their sum makes up the LCP value. The definitions below come from Google's documentation (web.dev, Optimize Largest Contentful Paint; Chrome for Developers, LCP breakdown).

Two of these four sections are waiting time (resource load delay, element render delay), two are work (TTFB, resource load duration). This distinction carries the entire prioritisation: waiting time is waste and can in principle be pushed to near zero. Work can be accelerated, but not abolished.

The target split: 40 / under 10 / 40 / under 10

Google gives concrete target shares of total LCP for the four subparts (web.dev, Optimize Largest Contentful Paint). Converted to the 2,500-millisecond budget, these produce absolute guide values:

Both delay shares combined should therefore stay under 20% of LCP — around 500 milliseconds for both waiting periods together on a 2.5-second budget. Google puts it plainly: the vast majority of the LCP time should be spent loading the HTML document and the LCP source (web.dev, Optimize Largest Contentful Paint). One qualification comes straight from Google itself: these time breakdowns are guidelines, not strict rules (web.dev).

What field data shows instead

Google analysed the four subparts across the Chrome UX Report and grouped origins by their LCP rating. The values below are the median across all origins in a group, taken from the 75th percentile of each individual subpart per origin (web.dev, Common misconceptions about how to optimize LCP).

Work out the shares and the picture flips against the target split. For origins with poor LCP, around 53% falls on TTFB and around 30% on resource load delay — but only around 8% on downloading the LCP resource, which is precisely where most optimisation projects begin (own calculation based on web.dev, Common misconceptions about how to optimize LCP). Google confirms the order of magnitude directly: the majority of origins with poor LCP spend less than 10% of their p75 LCP time downloading the LCP image (web.dev).

A methodological note belongs here: the sum of the four median values is an approximation, not the exact p75 LCP of any page that actually exists. Medians of individual subparts do not add up cleanly to the median of the sum. For the proportions — which is all this article uses them for — the calculation still holds, because the gaps between the subparts are substantial.

The median site with poor LCP spends almost four times as long waiting to start downloading the LCP image as it does actually downloading it, waiting 1.3 seconds between TTFB and the image request.

— web.dev, Common misconceptions about how to optimize LCP (Google)

Why "make the image smaller" is the wrong answer

The reflex is understandable. The LCP element is an image on 76% of mobile pages and 85.3% of desktop pages (HTTP Archive, Web Almanac 2025, Performance). If an image determines the metric, working on the image seems obvious. The subpart arithmetic shows that this conclusion does not hold.

Take the median values of a page with poor LCP — around 4,270 milliseconds — and run four scenarios. For context: an LCP is good up to 2,500 milliseconds, needs improvement up to 4,000 milliseconds, and counts as poor above that (web.dev, Optimize Largest Contentful Paint).

1. Halve the image size. Resource load duration drops from 350 to 175 milliseconds. New LCP: around 4,095 milliseconds. The value stays in the "poor" category and the improvement amounts to roughly 4%.
2. Remove the image entirely. Even if the download vanished completely, LCP would only fall to around 3,920 milliseconds — barely out of the "poor" category, but still around 1.4 seconds above the target. The theoretical maximum gain from all image optimisation combined is 350 milliseconds.
3. Eliminate resource load delay. If the wait before the download disappears, LCP drops from 4,270 to around 2,980 milliseconds — a jump from "poor" to "needs improvement" through one architectural change, without altering a single byte of the image.
4. Both together. Delay eliminated and image halved: around 2,805 milliseconds. Even that is not enough for a good LCP — because the largest item remains untouched. With TTFB at 2,270 milliseconds, only 230 milliseconds of the 2,500-millisecond budget would be left for everything else.

The calculation is deliberately rough, because the median values come from different distributions. The ranking of the levers does not change because of it, though: for pages with poor LCP, downloading the LCP resource is the smallest of the four items. Optimising there improves precisely the section that already matches the target picture.

Resource load delay: the subpart that can disappear

This subpart deserves the most attention because it is structurally different from the other three. Google puts the difference precisely: TTFB can be improved, but any improvements are bound by physics — resource load delay, by contrast, can potentially be eliminated and is in practice only bound by your serving architecture (web.dev, Common misconceptions about how to optimize LCP).

Resource load delay is the time during which the browser could be loading the LCP image but is not — because it does not yet know the image exists, or because it has been told the image is unimportant. Both are decisions made by the site, not properties of the network. The typical causes are well measured:

• The image is not in the HTML. 35% of LCP images have source URLs that are not discoverable in the initial HTML response (web.dev, The most effective ways to improve Core Web Vitals, based on the Web Almanac). The browser's preload scanner cannot request what it cannot see — the image waits until JavaScript or CSS supplies it.
• The image hides behind data-src. Around 5.9% of mobile pages obscure their LCP image source behind a data-src attribute (HTTP Archive, Web Almanac 2025, Performance). This couples the download inescapably to JavaScript execution.
• The LCP element is lazy-loaded. 16% to 17% of pages lazy-load their LCP image — a share that has held steady since 2024 (HTTP Archive, Web Almanac 2025, Performance). Google is unusually direct here: the LCP image should not be loaded with loading="lazy", because doing so creates unnecessary resource load delay (web.dev, Optimize Largest Contentful Paint).
• The image has no priority. fetchpriority="high" is used on 17% of mobile pages with an LCP image, up from 15% the previous year (HTTP Archive, Web Almanac 2025, Performance). Without that hint the browser initially assigns the image a low priority and queues it behind stylesheets and scripts.
• The image hangs off a request chain. Median LCP rises from 2,150 milliseconds with no upstream dependency to 2,850 milliseconds with two dependencies (web.dev, based on HTTP Archive data). Every link in the chain is waiting time.

The countermeasures are comparatively cheap and carry none of the trade-offs of a server migration: serve the LCP resource as a regular img element with a discoverable src in the HTML, keep loading="lazy" off the LCP element, set fetchpriority="high" on the likely LCP image and — where the image originates in CSS or JavaScript and cannot move into the HTML — pull it forward with link rel="preload" (web.dev, Optimize Largest Contentful Paint). Preload is currently used on just 2.1% to 2.2% of pages (HTTP Archive, Web Almanac 2025, Performance), even though it exists for exactly this case.

Where a plugin or theme sets these attributes, the route runs through its configuration — and that assumes the components in use are known along with their versions. The same inventory list needed for prioritising vulnerability feeds such as EUVD and CVE pays off a second time here.

TTFB: the largest item with the hardest limit

For origins with poor LCP, TTFB at 2,270 milliseconds is by far the largest single item, around 53% of the total (web.dev, Common misconceptions about how to optimize LCP; own calculation). For origins with good LCP it is 600 milliseconds (web.dev). The gap between the two groups is 1,670 milliseconds — more than the gap across all three remaining subparts combined, which comes to 1,260 milliseconds (own calculation based on web.dev).

That makes TTFB the most important item and simultaneously the most awkward. It contains portions that cannot be optimised away: signal travel time between user and data centre is bounded by the speed of light, the TLS handshake needs round trips, DNS resolution needs at least one query. What can be moved is server processing time, the number of redirects, caching behaviour and geographic distance. The article on systematically reducing server response time covers these levers in detail; the effect of a CDN on delivery distance is frequently the single biggest one.

Element render delay: the remainder nobody measures

The fourth subpart is the least conspicuous and surprisingly stable in field data: 230 milliseconds with good LCP, 310 with needs improvement and 360 milliseconds with poor LCP (web.dev, Common misconceptions about how to optimize LCP). The gap between the best and worst group is only 130 milliseconds — the narrowest spread of all four sections.

On average that makes render delay the smallest lever, but not an irrelevant one. With a text LCP — 23.7% of mobile and 14.4% of desktop pages (HTTP Archive, Web Almanac 2025, Performance) — resource load delay and resource load duration drop out entirely, because no resource needs loading (Chrome for Developers, LCP breakdown). LCP then consists only of TTFB and render delay, and the whole image optimisation debate misses the point. The typical culprits:

• Render-blocking stylesheets and scripts. As long as a blocking asset is loading, the browser renders nothing — not even the LCP image that finished downloading long ago.
• Late web fonts. With a text LCP, a font that has not loaded yet delays the rendering of the text directly.
• Client-side rendering and hydration. If the content only comes into existence through JavaScript, rendering moves behind the execution of the bundle. If the bundle breaks, the content does not render at all — a case for frontend error monitoring. With single-page applications there is the added wrinkle that soft navigations change the measurement itself.
• A blocked main thread. Long tasks delay rendering in the same way they delay interactions and therefore INP — both metrics share the cause here.

Field data instead of a single lab run

This article's entire argument stands or falls with data quality. A single lab measurement on a developer machine with a fibre connection also produces four subparts — but those of one person, not those of your customers. Holding the target split against such a single value leads systematically to the wrong priorities, because lab measurements do not reflect the TTFB reality of poor networks or the cache states of genuine returning visitors.

The Chrome UX Report illustrates well why field data is structurally different — and where its limits lie. Only users who have enabled usage statistic reporting, sync their browser history, have no sync passphrase set and use a supported platform are included; Chrome on iOS, Android WebView and other Chromium browsers are excluded (Google, Chrome UX Report documentation). In addition, origins and individual pages need a minimum number of visits to be included at all (Google, Chrome UX Report documentation).

Both data sources have their place, and the differences are covered in depth in the article comparing field and lab data. For subpart prioritisation, though, the order is clear: the decision about which subpart to work on belongs with field data. The check on whether a change worked belongs additionally in the lab. The Lighthouse score alone does not carry that decision, because it rests on a simulated single run.

That is why Web Vitals collection in XICTRAQ starts at the real visit: the tracker measures LCP, CLS and INP in your visitors' browsers, cookieless and without third parties, on the devices and connections that actually occur. Unlike the Chrome UX Report, the distribution comes from your own traffic — with no minimum visitor count and without excluding entire browser populations. How the values come together in the performance tab is visible in the live demo of the dashboard; how to build performance budgets with alerting from them is a topic of its own.

Limits of subpart analysis

The breakdown is a prioritisation tool, not an oracle. Four caveats belong with it honestly:

• The LCP element changes. The specification provides that whenever a new largest content is found, a new entry is created for it, and the algorithm terminates as soon as scroll or input events occur (W3C, Largest Contentful Paint, Working Draft of 13 July 2026). Which element ends up counting can vary with viewport, consent banner and scrolling behaviour — and so can the composition of the subparts.
• The subparts are not independent. A high TTFB shifts every subsequent section along the timeline. Reducing TTFB also changes when the preload scanner runs and how priorities play out in the network stack. The four values can be measured separately, but not optimised separately.
• Aggregated values hide segments. The median across origins describes no real customer. A good overall value can contain a poor mobile cohort. Conversely, for origins with poor LCP the image load duration is only around 20% slower on mobile than on desktop (web.dev, Common misconceptions about how to optimize LCP) — so the large difference between device groups originates elsewhere.
• The target split is a guideline. Google says so explicitly (web.dev, Optimize Largest Contentful Paint). A page with a 1,200-millisecond LCP, 70% of which falls on TTFB, violates the split and still has a good LCP. The split only becomes interesting once the overall value breaches the threshold.

Bringing the subparts into prioritisation

The practical order follows directly from the numbers and can be summarised as a working pattern:

1. Get the subparts from field data, not from a single run. Without the split, every measure is guesswork. That holds even when the overall value is green — a subpart close to its limit is the next regression.
2. Add up the delay shares. If resource load delay and element render delay together exceed 20% of LCP, that is where the first lever sits — regardless of how large the image is. For origins with poor LCP this share sits at around 39% (own calculation based on web.dev, Common misconceptions about how to optimize LCP).
3. Tackle resource load delay first. In our experience this subpart offers the best effort-to-effect ratio, because it is architectural: make the LCP resource discoverable in the HTML, take lazy loading off the LCP element, set fetchpriority, break up request chains.
4. Only then TTFB. The largest item, but the most expensive rebuild. The work is still worth it once TTFB consumes more than half the budget — at that point there is usually no other route to the target.
5. Resource load duration last — unless the measurement says otherwise. If this subpart genuinely accounts for around 40% or more, image optimisation is exactly right. In the field data of poor origins, at around 8%, it is not (web.dev, Common misconceptions about how to optimize LCP; own calculation).

Above all, the breakdown prevents one thing: months of work that measurably moves nothing. Optimising 350 milliseconds of download while 1,290 milliseconds of waiting time stay untouched means working carefully on the smallest item. The four subparts are the cheapest information available about where that work should go instead — and they cost nothing beyond the willingness to measure before optimising.