How to Improve TTFB — Diagnosing the Root Cause Before You Fix It

Most page speed advice skips straight to recommendations: enable compression, lazy-load images, use a CDN. These are valid fixes — but they're fixes for rendering performance, not TTFB. If your server takes 900ms to respond, no amount of image optimisation will bring your LCP under 2.5 seconds. You have to fix TTFB first, and that means knowing which of the five components is actually slow.

What TTFB Actually Measures

TTFB is the time between sending an HTTP request and receiving the first byte of the response. It's composed of five sequential phases:

1. DNS lookup — resolving the domain to an IP address. Usually 10–100ms. Cached after the first request per session.
2. TCP handshake — establishing the connection. One round trip. ~20–100ms depending on geography.
3. TLS negotiation — for HTTPS, adds one or two more round trips. ~50–200ms. TLS 1.3 reduces this to one round trip.
4. Server processing — the server receives the request, runs code, queries the database, and generates the response. This is the part you control.
5. Network return trip — the first byte of the response travelling back to the client. Pure geography — nothing to fix except moving the server or adding a CDN edge node.

Example: a site with TLS on a server 50ms away from the user:

• DNS: 20ms (first request)
• TCP: 50ms
• TLS: 100ms
• Server processing: 400ms (database query)
• Network return: 50ms

TTFB: ~620ms — just over the threshold, and almost entirely server processing. Adding a CDN here saves ~30ms on the network return. Fixing the database query saves ~350ms.

Good vs Bad TTFB Numbers

Google uses P75 field data (75th percentile of real user TTFBs) for Core Web Vitals assessment. Your fastest users don't matter — the slowest 25% determine your rating. A sub-600ms median TTFB can still fail CWV if the P75 is over 800ms.

How to Measure TTFB Accurately

Chrome DevTools (Network tab) — open DevTools → Network → reload the page → click the HTML document → Timing tab. Look for "Waiting for server response." Caveat: DevTools reuses an existing connection on reload, skipping DNS and TCP. For true cold-start TTFB, open an Incognito window or use a server-side tool.

curl — returns actual cold-connection TTFB from your machine:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://your-site.com/

Run 3–5 times and take the average. The first run includes DNS and TCP cold-start; subsequent runs reuse the connection.

ByteWaveNetwork Page Speed Inspector — opens a fresh TCP connection from the server side, performs a real DNS lookup and TLS handshake, and reports DNS, TCP, TLS, TTFB, and download time as separate values. Unlike DevTools, this always measures cold-start and isn't affected by your browser's connection pool or local DNS cache. Use it to get an objective baseline.

Diagnosing the Root Cause

Before reaching for a fix, isolate which component is slow. The Page Speed Inspector's breakdown tells you exactly:

Is DNS slow? DNS above 100ms on first visit. Fix: switch to a fast authoritative DNS provider (Cloudflare Registrar DNS, AWS Route 53). Consider enabling Cloudflare proxying — it moves DNS resolution to Cloudflare's anycast network.

Is TCP/TLS slow? High round-trip time driven by server geography. Fix: add a CDN with edge nodes closer to your users, or migrate your origin to a region nearer the majority of your traffic. For TLS specifically, upgrading to TLS 1.3 removes one round trip from the negotiation.

Is server processing slow? TTFB is high even when TCP+TLS are fast. This is the most impactful component to fix — see the next section.

Fixing Slow Server Processing

No page caching is the most common culprit on dynamic sites. Every request regenerates the response from scratch — running application code, hitting the database, rendering HTML. Page caching serves a pre-built response in milliseconds for subsequent requests.

• WordPress: WP Rocket, W3 Total Cache, or LiteSpeed Cache
• Node.js/Express: Redis-backed response caching, or a Varnish HTTP cache in front of the app
• Next.js: ensure pages use generateStaticParams (SSG) or ISR where content allows — these are served directly from CDN or file cache, bypassing the server entirely

After enabling page caching, TTFB for cached responses typically drops from 500ms+ to 10–50ms.

Slow database queries — page caching is the first fix (cache misses still hit the database, but far less frequently). Beyond that: add missing indexes, eliminate N+1 queries, use query caching with Redis or Memcached. Enable slow query logging (MySQL: slow_query_log=1, threshold 100ms) to find the offenders without guesswork.

Blocking synchronous operations in Node.js — synchronous I/O on the request path blocks the event loop for all concurrent requests. Any fs.readFileSync, JSON.parse on a large payload, or CPU-bound work in the request handler will stall all pending requests. Use async equivalents everywhere; move CPU-intensive work (image processing, encryption at scale) to worker threads or background queues.

PHP without OPcache — PHP re-parses and recompiles every file on each request without OPcache. Enable it in php.ini: opcache.enable=1. This alone can cut TTFB in half for PHP applications. Verify it's active: php -i | grep opcache.enable.

CDN Impact on TTFB

A CDN reduces TTFB by serving cached responses from edge nodes close to the user — instead of a round trip to your origin server, the user connects to an edge node 5–20ms away that returns a cached response.

CDNs help TTFB for:

• Static pages (HTML that doesn't change per user)
• Assets (images, CSS, JS)
• ISR/SSG Next.js pages cached at the CDN edge

CDNs do not help TTFB for:

• Authenticated or personalised pages that can't be cached at the edge
• API responses with user-specific data
• Uncacheable dynamic content

If your slow TTFB is on logged-in pages or API endpoints, a CDN won't fix it. You need to optimise the origin or move it geographically closer to your users.

After the Fix — Verifying Improvement

1. Run the Page Speed Inspector before and after to compare TTFB with isolated DNS/TCP/TLS breakdown — confirms which component improved
2. Run curl five times from a consistent location; compare medians not single samples
3. Check PageSpeed Insights field data at P75 — real-user TTFB improvement takes 2–4 weeks to surface in CrUX data as user traffic accumulates

Once TTFB is under 600ms, the next priorities are LCP optimisation and TBT reduction. See our page speed score guide for how Lighthouse weights these metrics and which fixes have the highest scoring impact.

Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.