TTFB and FCP: Loading Performance Metrics Explained

Time to First Byte and First Contentful Paint are sequential loading metrics that precede Core Web Vitals. What they measure, why they degrade, and what their thresholds indicate.

Last updated 02/08/2026

Time to First Byte (TTFB) and First Contentful Paint (FCP) are sequential loading metrics that measure the earliest phases of page delivery. TTFB captures how long the browser waits for the server's first response byte after a request. FCP captures when the browser renders the first visible content — text, image, or SVG — to the screen. Both precede Core Web Vitals in the loading timeline and serve as diagnostic signals rather than direct ranking factors.

What TTFB and FCP measure

TTFB measures the total time from the browser initiating a navigation request to receiving the first byte of the response. This includes DNS resolution, TCP connection, TLS negotiation, and server processing time. It reflects infrastructure latency — the combined cost of network path and server work before the browser has anything to render. FCP measures the time from navigation start to the first contentful element appearing on screen. This includes TTFB plus the time the browser spends parsing HTML, loading render-blocking resources, and painting the first text or image. FCP is the user's first visual confirmation that the page is responding.

The loading timeline sequence

Every page load follows a fixed sequence: DNS lookup resolves the domain to an IP address. TCP handshake establishes the connection. TLS negotiation (on HTTPS) secures it. The server processes the request and sends back the response — the moment the first byte arrives is TTFB. The browser then parses HTML, discovers and fetches critical resources, constructs the render tree, and paints the first visible content — that moment is FCP. This sequence is strictly ordered. A slow TTFB delays everything downstream. FCP cannot occur before TTFB completes. And the largest visible element — measured by LCP, a Core Web Vital — cannot appear before FCP. Degradation at any point in the chain compounds forward. The timeline is DNS → TCP → TLS → TTFB → FCP → LCP.

Where teams encounter these metrics

Teams typically encounter TTFB and FCP when investigating why pages feel slow despite acceptable Lighthouse scores. Synthetic lab tests often run on fast connections against warm caches, masking latency that field users experience. A page may score well in a lab while real users in distant regions see TTFB values three or four times higher due to geographic distance from the origin server.

The hidden failure mode

TTFB is affected by factors outside application code: server configuration, CDN cache hit rates, database query time, geographic distribution of users, and network conditions. A site can have clean, optimized front-end code and still deliver slow TTFB because the origin server is under load or the CDN is not caching the response. FCP degrades when render-blocking resources accumulate. Each synchronous stylesheet, font file, or script in the document head adds time between receiving HTML and painting content. Teams add these resources incrementally — a font here, an analytics script there — and FCP drifts upward without any single change appearing responsible.

What the thresholds indicate

Google defines TTFB as good below 800 milliseconds and FCP as good below 1.8 seconds. These are measured at the 75th percentile of field data, meaning 75% of real user experiences should fall within the threshold. These are diagnostic thresholds, not direct ranking signals. Unlike Core Web Vitals (LCP, INP, CLS), TTFB and FCP do not independently affect search ranking. They exist as upstream indicators. A poor TTFB almost always contributes to a poor LCP. A slow FCP signals that the browser is blocked from rendering content the user requested. The thresholds help locate where in the delivery chain the delay originates.

Why these metrics matter

TTFB and FCP are the earliest signals of delivery health. When TTFB is slow, no amount of front-end optimization compensates — the browser simply has nothing to work with yet. When FCP is slow, the user stares at a blank screen while the browser resolves render-blocking dependencies. Both metrics correlate with bounce behavior. Users do not diagnose loading phases. They perceive delay as a single experience. Whether the bottleneck is server processing or render-blocking CSS, the result is the same: the page appears unresponsive, and a portion of visitors leave before content appears.

The correct change

For TTFB: reduce server processing time, ensure CDN coverage for cacheable responses, minimize redirect chains, and evaluate geographic proximity between users and the serving edge. The goal is not a specific number but consistent delivery speed across the majority of real user sessions. For FCP: identify and eliminate render-blocking resources. Inline critical CSS, defer non-essential scripts, preload key fonts, and avoid synchronous third-party scripts in the document head. The goal is to let the browser paint content as soon as it has parsed enough HTML to do so.

Scope

TTFB is a page-level metric but is heavily influenced by infrastructure shared across the entire site. A slow origin server affects all pages. CDN configuration applies globally or per route. FCP varies more by page template — pages with different render-blocking resources will have different FCP values even on the same infrastructure.

How to verify

TTFB is visible in browser DevTools under the Network tab as the "Waiting (TTFB)" value for the document request. FCP appears in the Performance tab or via the PerformanceObserver API. Field data from Chrome User Experience Report (CrUX) provides 75th percentile values across real sessions. Compare lab measurements against field data — significant discrepancies usually indicate that synthetic tests are not representative of actual user conditions.

What becomes clearer once loading metrics are tracked

Whether delivery delays originate from infrastructure or front-end dependencies
Which pages carry render-blocking resources that delay first paint
How CDN cache hit rates affect real-user TTFB across regions
Where in the loading timeline the bottleneck actually occurs
Whether lab-based performance scores reflect field conditions

Common questions teams ask

Is TTFB the same as server response time?

Not exactly. TTFB includes server processing time plus network latency — DNS, TCP, and TLS negotiation. A fast server can still produce slow TTFB if the user is geographically distant or the network path is congested.

Does improving TTFB automatically improve FCP?

It removes one bottleneck. FCP also depends on render-blocking resources. A fast TTFB followed by heavy synchronous CSS and JavaScript will still produce a delayed FCP.

Are TTFB and FCP ranking factors?

Not directly. Core Web Vitals (LCP, INP, CLS) are the ranking signals. TTFB and FCP are diagnostic metrics that help explain why Core Web Vitals may be degraded. A slow TTFB is often the root cause of a slow LCP.

Why does my TTFB differ between lab and field?

Lab tests typically use fast, local connections. Field data reflects real users on varied networks and geographic locations. The gap reveals how much of TTFB is network-dependent versus server-dependent.

Can a CDN fix slow TTFB?

For cacheable responses, yes — a CDN serves content from edge locations closer to users. For dynamic pages that require origin processing, the CDN reduces network latency but cannot eliminate server processing time.

What is the relationship between FCP and LCP?

FCP measures the first visible content; LCP measures the largest visible content. FCP always occurs before or simultaneously with LCP. If FCP is slow, LCP cannot be fast. They are sequential points on the same rendering timeline.