TTFB: The Hidden Performance Killer Most Developers Ignore
You've optimized images, minified JavaScript, and enabled compression. Your site still feels slow. The culprit is almost certainly TTFB — and the fix isn't anywhere in your frontend code.
Time to First Byte is the most neglected performance metric in web development. Performance guides obsess over image compression, JS bundling, and CSS minification while treating TTFB as a footnote. This is backwards. TTFB is overhead added before any frontend work begins — you cannot fix LCP or FID on top of a slow TTFB.
What Makes Up Your TTFB
TTFB is the sum of several phases, each with different causes and fixes:
- DNS lookup: Resolving your domain to an IP. Usually 10–50ms with a warm cache, but 100–300ms on first lookup. A CDN with anycast DNS handles this better than most origin nameservers.
- TCP connection: Establishing the network connection. Determined by physical distance — the speed of light sets the floor. A server 150ms round-trip away cannot have a TCP handshake faster than 150ms.
- TLS handshake: Negotiating encryption. Adds 0–2 additional round trips. TLS 1.3 reduces this significantly vs TLS 1.2.
- Server processing: Time from the server receiving the request to sending the first response byte. The part you fully control — and usually the biggest problem.
⏱️ TTFB Speed Tester
Measure your server response time in isolation. Pinpoint exactly where time is lost.
The Most Common TTFB Killers
Shared hosting resource contention. Your site shares CPU, RAM, and I/O with potentially hundreds of others. When a noisy neighbour spikes CPU, your TTFB spikes too. This is the most common reason a site that was fast six months ago has gotten slower — more tenants were added to the server.
WordPress without page caching. Default WordPress with several active plugins can take 500–1500ms of pure server time to generate each page response. Every visitor triggers PHP execution, dozens of database queries, plugin loading, and template rendering from scratch.
Missing database indexes. A single missing index on a large table can turn a 5ms query into a 2000ms query. As data grows, previously fast queries slow down progressively as the planner scans more rows.
Synchronous external API calls. If your server calls a third-party API during page generation, your TTFB includes that API's latency. One 300ms external call affects every page load for every visitor.
Geographic distance. A server in Frankfurt serving Sydney visitors adds ~170ms of pure network latency before any server processing runs. This is physics — the only fix is a CDN or deploying closer to your audience.
Fixes in Order of Impact
- Add full-page caching. TTFB drops from 500ms+ to under 50ms for cached pages. Highest leverage change available on a database-backed site.
- Upgrade hosting. Move from shared to VPS or managed cloud. Eliminates resource contention and gives predictable, consistent performance.
- Add a CDN. Serves content from edge nodes near users, eliminating geographic latency.
- Optimise slow database queries. Profile, find slowest queries, add indexes, fix N+1 patterns.
- Upgrade PHP to 8.x. JIT compiler can improve execution speed by 30–50% for compute-intensive operations.
- Enable HTTP/2 or HTTP/3. Better multiplexing reduces TLS overhead on subsequent requests.