LCP vs FCP vs TTFB: What Each Metric Measures and When to Fix Which
Understand the difference between LCP, FCP, and TTFB in web performance. Learn what each metric measures, how they relate, and which to prioritize when debugging slow page loads.
You open PageSpeed Insights and see three different timing values — TTFB at 900ms, FCP at 1.8s, LCP at 3.4s. All three are elevated. All three sound like they should be fixed. But they are measuring different things, caused by different problems, and fixed in different places. Treating them as interchangeable wastes time and can lead you to optimise the wrong layer. This comparison explains what each metric actually measures, how the three relate to each other, and how to decide where to focus.
The Metrics Defined
Time to First Byte (TTFB)
TTFB measures the time from when the browser sends an HTTP request to when it receives the first byte of the response body. It captures everything that happens on the network and server before the response starts arriving: DNS resolution, TCP handshake, TLS negotiation, server processing time, and queuing.
TTFB is an infrastructure metric, not a rendering metric. A high TTFB means something is slow before the browser has received any content to work with.
Good: under 800ms. Target: under 200ms.
First Contentful Paint (FCP)
FCP marks when the browser renders the first piece of DOM content — any content: text, an image, a canvas element, a non-white background. It is not a Core Web Vital (Google removed it from ranking signals), but it is a useful diagnostic signal for perceived load speed and the gap between server response and first render.
The gap between TTFB and FCP represents time spent downloading HTML and render-blocking resources (CSS, synchronous scripts) and browser render processing.
Good: under 1.8 seconds. Target: under 1.0 second.
Largest Contentful Paint (LCP)
LCP marks when the largest visible content element in the viewport finishes rendering. It is a Core Web Vital and a direct ranking signal. LCP is the metric that most closely correlates with how fast users perceive a page to load — because it measures when the main content is ready, not just when the first pixel appears.
Good: 2.5 seconds or under. Poor: above 4.0 seconds.
How LCP, FCP, and TTFB Relate to Each Other
They are sequential: TTFB happens before FCP, and FCP happens before LCP. But they are not additive in a simple way. Each has its own contributing factors.
A useful mental model: TTFB is the server side. FCP is the download-and-parse side. LCP is the resource-load side.
If TTFB is 900ms, FCP cannot be under 900ms. LCP cannot be under FCP. A high TTFB creates a floor that every other metric has to climb above. This is why TTFB reduction has an outsized impact — every improvement ripples through to FCP and LCP.
But if TTFB is 100ms and LCP is still 3.5s, fixing TTFB further will not help. The bottleneck has moved downstream — probably to the LCP resource itself: a large image, a render-blocking script, a late-discovered font.
When to Fix Which
Start with TTFB if it is above 800ms
TTFB above 800ms indicates a server or network problem that everything else depends on. Common causes:
- Server in a single region with users in another region — use a CDN
- No caching on dynamic pages — add CDN caching with short TTL
- Server-side computation on the critical path — move to edge workers or cache the result
- Slow database queries blocking the response — profile and optimise
Fixing TTFB typically requires CDN configuration, server-side caching, or infrastructure changes. It does not require touching your CSS or JavaScript.
Look at the FCP gap if FCP is much higher than TTFB
If TTFB is 200ms but FCP is 2.5s, the gap is 2.3s. That time is spent downloading the HTML, parsing it, downloading render-blocking CSS and scripts, and then first-painting.
Causes of large TTFB-to-FCP gaps:
- Large HTML document (over 100KB uncompressed)
- Render-blocking stylesheets loaded from external origins
- Synchronous JavaScript in the head that blocks the parser
- Large CSS bundles that take time to download and parse
Fixes: inline critical CSS, defer or async scripts, eliminate render-blocking third-party resources, enable Gzip/Brotli compression on HTML responses.
Focus on the LCP resource if LCP is much higher than FCP
If FCP is 1.2s and LCP is 4.0s, the 2.8s gap is almost certainly the time it takes to download and render the LCP element itself — typically a hero image.
This is image optimisation territory: format (WebP or AVIF), size (serve at actual display dimensions), priority (fetchpriority="high" on the LCP image, preload link in the head), and delivery (CDN, not origin).
LCP vs FCP vs TTFB: Comparison Summary
| Metric | What it measures | Who causes it | Fix category |
|---|---|---|---|
| TTFB | Server and network time before first byte | Infrastructure, server code | CDN, caching, server optimisation |
| FCP | Time to first visual content | Render-blocking resources, HTML parsing | Critical CSS, script deferral, compression |
| LCP | Time to largest visible content | LCP resource (usually an image) | Image format, size, priority, CDN delivery |
They are different problems at different layers of the stack.
Using the Metrics to Diagnose in Practice
Open WebPageTest and run a test on your production URL. Look at the waterfall:
- Find the first server response — that is TTFB.
- Find the first render event — that is FCP.
- Find the LCP element in the test results. Find when its resource finishes downloading and rendering — that is LCP.
Measure the gap between each. The largest gap points to your primary bottleneck.
Then check PageSpeed Insights field data. If your lab waterfall shows good LCP but field LCP is poor, the problem is device- or network-specific. Run WebPageTest with a mobile device emulation at a throttled connection to reproduce field conditions.
Which Metric Matters Most for SEO
All three affect user experience. Only LCP, INP, and CLS are Core Web Vitals and direct Google ranking signals. FCP and TTFB are not ranking signals directly — but they are causes that lead to bad LCP scores, which are ranking signals.
Optimise for LCP as the outcome. Use FCP and TTFB as diagnostic inputs to find the cause.
If you need help interpreting your specific PageSpeed or WebPageTest results and turning them into a concrete fix plan, Clixo runs web performance audits for product teams that want measurable improvements, not slide decks.