Reference guide · performance · Published 2026-08-16 · 3 min read
TTFB vs FCP explained
TTFB vs FCP: how server time becomes render time, why fast TTFB is not fast FCP, and the fix route for each leg.
- ·The two clocks
- ·Fast TTFB slow FCP
- ·Which to fix
The two clocks
TTFB (Time To First Byte) measures the gap until the browser receives the first byte of the HTML response: DNS, connection, the server processing, and the first response byte. FCP (First Contentful Paint) measures when the browser paints the first content (text, image, or canvas) after that byte arrives.
| Metric | Measures | What happens in the gap |
|---|---|---|
| TTFB | Request to first HTML byte | DNS, connect, server work, CDN |
| FCP | Request to first content paint | All of TTFB, plus HTML parse, CSS, render-blocking resources, first paint |
So FCP is built on top of TTFB: a slow first byte pushes every downstream metric out, but a fast TTFB guarantees nothing about FCP because the browser still has to parse, fetch blocking CSS, and paint.
Why fast TTFB still means slow FCP
Four real situations where TTFB is quick and FCP stays slow:
| TTFB | FCP | Cause |
|---|---|---|
| 80 ms | 1.8 s | A render-blocking stylesheet (style.css) sits between the first byte and first paint |
| 80 ms | 3 s | A large un-bundled JS file parses and runs before FCP |
| 120 ms | 1.5 s | The HTML is small but the font or CSS is big |
| 40 ms | 900 ms | A remote Web Font or third-party blocks first paint |
The browser does not paint until the render-blocking CSS is fetched and the script that would unblock it has run. Remove the blocking CSS from the critical path (inline critical CSS, defer external styles) and FCP drops even when TTFB never changes.
Which metric to fix first
Start with TTFB if the raw number is high, because it caps everything: TTFB optimisation works the server and database cache leg. Once TTFB is under, say, 200 ms for a dynamic page, FCP is determined by the render path, which is where the critical rendering path and the render-blocking resources articles take over.
| Fix target | Symptom | Focus |
|---|---|---|
| TTFB | The network tab waits on the origin for every page | Server response time, DB, page cache, CDN |
| FCP | First byte is fast but white screen / spinner persists | Critical CSS, script order, render-blocking JS |
Lighthouse splits these for you: the "Reduce server response times" audit is TTFB, and the "Eliminate render-blocking resources" audit is the FCP side. When the field data says LCP is poor, trace the FCP leg first, because LCP includes FCP and the largest-element paint depends on the first paint path.
The mental model
TTFB is the door; FCP is the first visible room. If the door opens late, nothing else can start; if it opens on time but the first paint waits on a stylesheet, the room is empty while the wall is being built. Fix the door (server) when the door is slow, fix the rendering (CSS/JS) when the room is empty. An LCP of 3 seconds with a 40 ms TTFB is a render problem, not a server problem, which is the whole point of splitting the number.
The LCP optimisation guide treats the whole timeline as legs and the TTFB optimisation article dives into the server side, so the two readings plus the core web vitals framework keep the divide honest.