Two pages both report a field LCP of about 4 seconds. On page A, TTFB is 2.6s and FCP is 2.9s. On page B, TTFB is 0.2s and FCP is 0.5s. What does each profile tell you about where the time is going, and how do the investigations differ?
answer
- two landmarks split one interval
- how much elapsed before any byte
- gap between first byte and first paint
- whatever remains belongs to one element
- narrow first, open the waterfall second
basics
~20 sOn page A almost all of the 4 seconds is spent before anything renders, so the problem is the server or the network and no front-end change will help. On page B the browser painted in half a second and then waited 3.5 seconds, so the largest element itself is the problem.
solid answer
~60 sThe two supporting metrics act as landmarks that cut the LCP interval into segments. On **page A**, 2.6s of the 4s is gone before a single byte arrives and the first paint follows almost immediately after — so the browser is efficient and the wait is redirects, connection setup or server work. Optimizing images or scripts there is wasted effort; you go look at redirect chains, origin distance and backend response time. On **page B** the opposite: bytes arrive fast, something paints in 0.5s, and then 3.5 seconds pass with the largest element still missing. That gap is *discovery and delivery of that one element* — it is probably referenced from CSS or injected by JavaScript rather than present in the initial HTML, or it is competing for bandwidth, or it is simply enormous. The general method matters more than either case: compare LCP against TTFB and FCP first, and only then open a waterfall, because those two numbers tell you which third of the timeline to look at.
go deeper
Know the ordering: first byte, then first paint, then the largest element. Be able to say which one of them was slow when given the three numbers.
Explain what each segment between the landmarks contains, and name the usual causes of a long gap in each — connection and server cost, render-blocking work, and late discovery of the main element.
Demonstrate the method, not a checklist: narrow to a segment, state the negative result out loud when a popular fix would not help, predict the size of the improvement, and verify against the same population you diagnosed.
Be ready to route the work rather than do it — this decomposition often assigns the problem to a backend or platform team. Own how the organization decides ownership of a metric no single team fully controls.
## Why you compare before you profile A slow LCP on its own is a symptom with at least three unrelated causes: the response was late, the page was slow to render anything, or the specific largest element was late. Opening a network waterfall without narrowing first means reading every row. TTFB and FCP are cheap landmarks that split the interval into three segments, and the segment that dominates tells you which investigation to run. ``` navigation ──── TTFB ──── FCP ──────────────── LCP [ server+network ][ render-block ][ the element itself ] ``` Each boundary answers one question. TTFB: did the bytes arrive on time? FCP: once they arrived, did the browser render promptly? Whatever is left after FCP belongs to the largest element specifically. ## Profile A — the wait is before the browser TTFB 2.6s, FCP 2.9s, LCP ~4s. Two facts stand out. First, 65% of the total is spent before the document exists. Second, the gap between first byte and first paint is only 300ms, which means the rendering path is already lean — there is very little render-blocking work to reclaim. The investigation is therefore entirely upstream: - **Redirect chains.** Each hop is a full round trip charged before the real request. A scheme redirect plus a host redirect plus a locale redirect is trivially a second on a mobile connection. - **Connection cost versus server cost.** If the handshake phases dominate, the user is far from wherever connections terminate. If the server phase dominates, it is an application problem — an uncached query, a cold start, a slow upstream call. - **Is the HTML cacheable at all?** Fully dynamic, per-user HTML pays origin latency for every visitor by construction. The important discipline here is the negative result: on this page, converting images to a modern format, preloading the hero, or splitting the bundle will produce approximately zero improvement. The budget was already spent before the browser had anything to do. Saying that out loud is what an interviewer is listening for. ## Profile B — the wait is one element TTFB 0.2s, FCP 0.5s, LCP ~4s. The server is fast, something painted almost immediately, and then 3.5 seconds passed. Whatever the largest element is, it was not ready when everything else was. The usual causes, roughly in order of how often they turn out to be it: - **Late discovery.** The element is not in the initial HTML the browser receives. A hero image referenced as a CSS `background-image` cannot be found until the stylesheet is downloaded and parsed. An image injected by client-side JavaScript cannot be found until that bundle has downloaded, parsed and run. Either way the request starts seconds after it could have. - **Contention.** The element is discovered on time but queued behind other downloads, or fetched at a low priority while less important resources take the bandwidth. - **Weight.** The asset is genuinely large — an uncompressed original, or a desktop-sized file being sent to phones. - **Blocked rendering.** The bytes arrived but the browser could not paint the element yet: text held invisible waiting on a web font, or the main thread saturated so the frame could not be produced. Distinguishing those is where a waterfall finally earns its place — and now you know exactly what to look for in it: the request for one specific resource, when it started, how long it took, and how long after it completed the paint occurred. ## The third profile worth naming There is a case the two examples do not cover: TTFB fast, FCP *slow*, LCP slow. Here the browser had bytes early and still could not paint. That points at render-blocking work between the two — stylesheets and head scripts that must finish before the first frame, or a page whose content is drawn entirely by client-side JavaScript so nothing can render until a bundle executes. In that shape both FCP and LCP move together when the blocking work is removed, which is a useful prediction to state before making the change. ## Field versus a single run All of this reasoning must be done on the *same population*. Comparing a field LCP against a lab TTFB from your own laptop is meaningless — your laptop is not the 75th-percentile user. The comparison only localizes anything if all three numbers come from the same source and the same percentile. When field data is aggregated, look at the distribution too: an LCP that is fine at the median and dreadful at p75 is often a device or geography split rather than a page-wide defect, and averaging it away hides the actual cause. ## The summary an interviewer wants "I would look at TTFB and FCP before I look at anything else, because they tell me whether I am debugging a server, a rendering path, or one resource — and those are three different teams' work." The specific fixes matter less than demonstrating that you narrow before you dig.
- On page B, what single check would most quickly tell you whether the hero image was discovered late?Look at when its request started relative to the document. If the request begins hundreds of milliseconds after the HTML finished parsing, it was not discoverable in the markup — it is coming from a stylesheet or from JavaScript. An image present in the initial HTML is picked up by the browser's speculative parsing almost immediately, so a late start is the tell.
- You improve page A's TTFB from 2.6s to 0.6s. What do you predict happens to its LCP, and what would it mean if it did not move?LCP should fall by roughly the same two seconds, because everything downstream shifted earlier by that amount. If it barely moves, a second bottleneck was hidden behind the first — the largest element was already waiting on something else, and the server latency was merely masking it. That is a normal outcome and simply means you repeat the same decomposition.
- Why is comparing a field LCP against a TTFB measured on your own machine misleading?Because they describe different populations. Your machine is a fast device on a good connection in one location; the field value aggregates real users at the 75th percentile across devices and networks. Subtracting one from the other produces a segment size that corresponds to nobody. All three landmarks have to come from the same source and percentile for the arithmetic to mean anything.
- A page shows a fast TTFB, a slow FCP, and an LCP close behind the FCP. What does that shape suggest?That the browser had bytes early but could not paint. The suspects are render-blocking stylesheets and head scripts, or a page whose content is produced entirely by client-side JavaScript so nothing renders until a bundle executes. Because LCP trails FCP closely, both should improve together once the blocking work is removed — a prediction worth stating before you change anything.
saying these in an interview costs you the question
- Opens a waterfall before comparing the landmark metrics
- Proposes image optimization when the time is all server-side
- Mixes field metrics with lab numbers from a dev machine
- Assumes a slow LCP always means a heavy image
- Ignores that a hidden second bottleneck can absorb the win