How to fix a slow TTFB
A slow Time to First Byte is a server-side problem. These are the fixes that actually move it: caching, CDNs, database work, and hosting.
Start with caching
The fastest page a server can send is one it doesn't have to build. Full-page caching stores the generated HTML and serves it directly — on WordPress that's a caching plugin; on other stacks it's a reverse-proxy cache like Varnish or nginx's fastcgi cache.
Object caching (Redis, Memcached) helps when pages can't be cached whole: repeated database queries are answered from memory instead.
Put a CDN in front
A CDN with edge caching answers requests from a location near the visitor, cutting both network distance and origin load. For mostly-static pages this can cut TTFB dramatically for far-away visitors.
Fix slow application code
If the server itself is slow to generate pages, profile it: slow database queries, missing indexes, and heavyweight plugins or middleware are the usual suspects. TTFB measured on an empty static file tells you whether the problem is the application or the infrastructure.
When it's the hosting
If a cached static file still takes hundreds of milliseconds, the bottleneck is the hosting infrastructure itself — oversold shared servers, slow storage, or distant data centers. That's fixed by changing the hosting setup, not the site. Independent benchmarks of hosts' TTFB are worth consulting — measured response times differ meaningfully between providers.
Common questions
- Can images or JavaScript cause slow TTFB?
- No. TTFB completes before any assets load. If TTFB is slow, the cause is DNS, connection setup, or — most often — the server itself.
- How much can a CDN improve TTFB?
- For cacheable pages, a CDN can serve responses from an edge location near the visitor, often cutting hundreds of milliseconds for geographically distant visitors.
Measure how fast your server responds, before any page code runs.
Measure your TTFB →