When a page feels slow, every measurement tool shows the same single value: the Largest Contentful Paint, or LCP. It tells you when the largest visible element has loaded and rendered -- but as a bare number it does not say why it takes so long. This is exactly where many optimizations go wrong: they treat LCP as a single brake and try measures at random, from image compression through preloading to server tuning, without knowing which step is the actual bottleneck. Yet LCP breaks down into four clearly separated subparts: time to first byte (TTFB), load delay, load time and render delay (web.dev). Anyone who measures these four phases individually sees at once where the time really goes -- and optimizes deliberately instead of across the board. This article takes LCP apart step by step, assigns each phase its budget share and shows how the subpart analysis turns into a prioritized action list. In our Core Web Vitals optimization this breakdown always comes first, before we change a single line.
Why a Single LCP Value Misleads You
LCP is the most demanding of the three Core Web Vitals. While responsiveness and visual stability sit in the green on many sites, only 62 percent (Web Almanac 2025) of mobile websites reach a good LCP under 2.5 seconds. The reason is that LCP depends on a whole chain of technical steps -- from the first network contact to the fully painted element. Two pages can show the same value of about 3.2 seconds and still have completely different causes: on one, the slow server response costs most of the time; on the other, a late-discovered, huge background image. Whoever knows only the total value is left in the dark when hunting for the cause.
That is why the Chrome team established a model that splits LCP into four consecutive phases (web.dev). Each phase begins where the previous one ends, and together they add up to exactly the measured LCP value. On a timeline from navigation to the visible element they follow strictly one after another: first the server time, then the wait until the download starts, then the download itself, and finally the time until display. This split is not theory but can be read directly in common diagnostic tools. Once the four numbers are in front of you, the most important question is answered: which phase eats the largest share -- and therefore deserves the first action?
The Four LCP Subparts at a Glance
Subpart 1: TTFB -- the Server Time to the First Byte
The first phase is time to first byte, or TTFB. It covers everything that happens before the browser receives the first byte of the HTML document: DNS resolution, connection setup including the TLS handshake, any redirects and, above all, the server's think time until it has produced the response. As a guideline, TTFB should not exceed about 40 percent (web.dev) of the entire LCP budget. With a target of 2.5 seconds that means, roughly, a TTFB of about one second or less. If the server response is slow, everything after it shifts back -- no image, however small, can then rescue a good LCP, because the resource can only be requested after the first byte arrives.
Common causes of a high TTFB are uncached, dynamically generated pages, slow database queries, overloaded hosting environments and unnecessary redirect chains. The latter in particular are often underestimated: every additional hop -- from HTTP to HTTPS, from non-www to www, from an old slug to a new one -- costs a full round trip before the actual loading begins. How to reduce such redirect chains as a hidden load brake to a single hop is covered separately. The fundamental server levers -- caching, faster hosting, lean backends -- we summarize in the article on server response time and TTFB and offer as a service under server optimization.
Subpart 2: the Resource Load Delay
The second phase is the most treacherous because nothing productive happens in it. The load delay is the span between the arrival of the first byte and the moment the browser actually begins downloading the LCP resource. Ideally this span is near zero; the budget is under 10 percent (web.dev) of LCP. In practice, however, it is often alarmingly large, because the browser discovers the most important resource late or rates it too low. Every millisecond here is wasted time in which the line would be free but stays unused.
The typical reasons: the LCP image is loaded as a CSS background and therefore does not appear in the HTML, so the browser finds it only after processing the stylesheet. Or it is present as an image in the markup but is treated at low priority by default and queued behind scripts. The remedies are well documented and inexpensive: announce the resource early via preload, give it high priority with a priority hint, and keep the LCP element out of lazy loading. Because this is pure waiting time, these very steps often deliver the fastest wins of the entire frontend optimization.
The Delays Are Wasted Time
Subpart 3: the Pure Resource Load Time
The third phase is the only one in which the LCP resource actually travels over the line: the load time. It measures how long the download takes from the first to the last byte of the resource. The guideline here -- as with TTFB -- is about 40 percent (web.dev) of the LCP budget. Together, TTFB and load time therefore share roughly 80 percent (web.dev) of the time; they are the two productive phases in which data actually flows. Load time depends directly on file size, image format, compression and available bandwidth -- and on whether other downloads compete for the same line at the same time.
The most effective lever is almost always the size of the resource. A modern format such as AVIF or WebP, a resolution matched to the actual display size via srcset, and appropriate compression often cut the weight several times over without visible loss of quality. In addition, a CDN ensures the bytes come from geographic proximity and the line is not clogged by incidental downloads. For returning visitors the load time can even be cut to almost zero when the resource is already available locally through a service worker and precaching. The order still matters: only once load delay and render delay are small does fine-tuning the load time pay off -- otherwise you optimize a phase that is not the bottleneck at all.
Modern Image Format
AVIF and WebP deliver noticeably smaller files at comparable quality than older formats. For the LCP image, switching is one of the biggest levers on load time.
Responsive Resolution
Through srcset and sizes each device gets exactly the image size it displays. A smartphone thus does not load a desktop image -- fewer bytes, shorter load time.
Delivery via a CDN
A content delivery network shortens the paths, spreads the load and keeps the line free. The LCP resource therefore arrives earlier and without competition.
Subpart 4: the Render Delay to Display
The fourth phase begins as soon as the LCP resource is fully loaded and ends when the element actually appears on screen. This render delay should be small -- under 10 percent (web.dev) of the budget. If it is large, the browser has the resource in hand but cannot paint it because it is blocked elsewhere. Typical causes are render-blocking CSS and JavaScript in the document head, long tasks on the main thread that keep the browser busy, and fonts or hydration in client-side rendered applications.
If the LCP element is plain text rather than an image, load delay and load time disappear entirely -- then LCP consists only of TTFB and render delay, and the latter becomes the decisive lever. Often a custom web font blocks display, or a bulky script keeps the main thread occupied. The remedies: inline critical CSS in the head, defer non-essential JavaScript, and break long tasks into smaller chunks. Which findings in the diagnostic report point to such a rendering problem and how to sort them is shown in our article on reading the Lighthouse report.
The Budget: 40 to 40 to Under 20
From the four guidelines a simple rule of thumb for a good LCP emerges: about 40 percent (web.dev) for TTFB, about 40 percent (web.dev) for load time, and together at most 20 percent (web.dev) for the two delays. Put differently: roughly four fifths of the time should flow into the two productive phases in which the server responds and the resource loads. The rest -- the pure waiting times -- should be kept as small as possible. This distribution is not a law of nature but a target corridor: it says where you want to land and makes it immediately visible which phase falls out of frame.
| Subpart | Budget share | Typical cause when exceeded | Most important lever |
|---|---|---|---|
| TTFB (server time) | about 40 % | Uncached pages, slow database, redirect chains | Caching, hosting, lean backend |
| Load delay | under 10 % | Late-discovered or low-priority resource | Preload, priority hint, no lazy loading |
| Load time | about 40 % | Oversized file, old format, no compression | Modern format, srcset, CDN |
| Render delay | under 10 % | Render-blocking CSS/JS, long main-thread tasks | Critical CSS, defer JavaScript |
The Core in One Sentence
How to Measure the Four Phases Concretely
The subpart split can be read with freely available tools. The Lighthouse diagnostic report already breaks LCP down by the four phases, including the share in milliseconds. In the performance panel of the Chrome developer tools, the network waterfall shows when the server responds, when the LCP resource starts and when it finishes loading. The open-source web-vitals library, in its attribution build, provides the same breakdown even from real user sessions. It is important to measure in the lab with realistic throttling: a fast office network hides exactly the delays that hurt most on mobile devices.
- Determine the LCP element -- via lab test and field data, not by guessing
- Break LCP into the four subparts (Lighthouse or web-vitals attribution)
- Identify the phase with the largest time share -- that is the bottleneck
- Check the two delays first: are they larger than 20 percent together?
- Choose the matching lever and optimize only that one phase deliberately
- Measure again after the change -- ideally in the field data of real users
Lab and field data complement each other here. A lab test shows reproducibly how a change takes effect; the field data show what real users experience on their devices and networks. Because the LCP element can differ by screen size, the look into the field is indispensable -- how RUM, CrUX and performance budgets sensibly combine is explored separately. As a rule: only once the same phase appears as the bottleneck in both lab and field is the measure safely prioritized.
From Measured Value to a Prioritized Action List
The real value of the subpart analysis lies in prioritization. Instead of a long list of well-meant recommendations, a ranking emerges: at the top stands the phase with the largest time share, below it the second largest, and measures on already lean phases drop out entirely. If TTFB eats 60 percent of LCP, compressing an already small image is wasted effort -- the lever is the server. Conversely, if the server time is good but the load time is high, no backend, however fast, helps; only a lighter resource does. This clarity saves effort and delivers visible results faster.
The subpart analysis turns a vague hunch into a solid ranking. We do not optimize everything a little, but the one phase that truly drives the value up -- and then measure whether the bottleneck has shifted.
This is exactly how we proceed in a structured performance audit: measure LCP, split it into the four phases, name the bottleneck and build an action list sorted by impact -- instead of an expensive sweep across everything. The bottleneck often shifts after the first change, because a different phase then dominates; the analysis is therefore repeated until all four subparts sit within the target corridor. Which services this includes and how such an audit runs is shown in our overview of performance services. Anyone who wants to understand the three Core Web Vitals in context will find the classification in the article on Core Web Vitals 2026.