Content Marketing Glossary

  • What is Time to First Byte (TTFB)?

What is Time to First Byte (TTFB)?

Time to First Byte (TTFB)

Time to First Byte (TTFB) is a web-performance metric measuring how long the browser waits between making an HTTP request and receiving the first byte of response from the server. TTFB isn’t itself a Core Web Vital, but it’s a foundational metric: slow TTFB delays every subsequent metric (LCP, INP, render start), so Core Web Vitals almost always depend on healthy TTFB. Target is under 800 milliseconds; anything over 1.8 seconds is considered poor.

What TTFB actually measures

TTFB captures the time for:

DNS resolution. Browser resolves the domain to an IP address.

TCP handshake. Connection establishment.

TLS negotiation. For HTTPS, the secure handshake.

Request sent, server processing. Server-side work: database queries, API calls, application logic.

First byte received. Server sends initial response.

All of this before any rendering can start. Slow TTFB makes every Core Web Vital harder to hit.

What causes slow TTFB

Six common causes:

Slow server-side rendering. Apps that compute pages from scratch on every request rather than caching.

Slow database queries. Unindexed queries, N+1 query patterns, overly-complex joins.

Server geography far from user. User in Australia hitting a server in the US. Physics bounds what’s possible.

CDN misses. Pages that should be CDN-cached but aren’t.

Origin server under load. Traffic spikes overwhelming compute capacity.

Third-party API dependencies. Pages that wait for external API responses before sending HTML.

How to improve TTFB

Six standard approaches:

Static or edge-rendered pages. Pre-render pages at build time or on the edge. The server sends pre-computed HTML with minimal processing.

CDN for HTML. Content pages served from CDN edges close to users.

Database optimisation. Indexes, query plans, caching layers. The unsexy but highest-impact server-side work.

Application-level caching. Redis, memcached, or equivalent for computed data.

Reduce third-party dependencies. Don’t block page rendering on external API calls.

Use HTTP/2 or HTTP/3. Multiplexed, faster connections reduce the transport-layer component of TTFB.

Measuring TTFB

Four diagnostic tools:

Chrome DevTools Network panel. Per-request TTFB breakdown.

PageSpeed Insights. Reports TTFB alongside Core Web Vitals.

WebPageTest. Detailed TTFB from multiple geographies.

Server logs and APM tools. Server-side TTFB from production (Datadog, New Relic, similar).

TTFB and modern architectures

Three modern patterns that optimise TTFB:

Static Site Generators (Next.js, Astro, Hugo). Pages pre-built at deploy time. TTFB becomes CDN latency plus trivial server time.

Edge rendering (Cloudflare Workers, Vercel Edge Functions). Pages computed at the edge, close to the user. Combines dynamic rendering with CDN-like latency.

ISR (Incremental Static Regeneration). Next.js pattern where static pages regenerate periodically rather than on every request. Best of static and dynamic.

Why TTFB matters for AI search

Two reasons beyond classical SEO:

AI crawlers and users hit slow pages less often. Pages that time out or take too long to respond get retrieved less often by AI-search systems. Poor TTFB reduces AI-citation eligibility.

Live retrieval during AI-search affects latency. Products like Perplexity may fetch pages in real-time during answer generation. Slow pages risk being skipped.

Penfriend’s TTFB posture

Penfriend doesn’t control the host site’s server performance, but the generated content is pure static HTML that serves perfectly from CDN. Sites hosting Penfriend pages on static-first platforms (Vercel, Netlify, Cloudflare Pages, WordPress with full-page caching) see sub-200ms TTFB on the content consistently. The performance bottleneck is almost always the site’s overall architecture, not the content itself.

Related terms