To fix slow TTFB, reduce server processing time with full-page caching, optimise database queries, enable a CDN for HTML where appropriate, use HTTP/2 or HTTP/3, and upgrade hosting if the origin is overloaded. Target under ~200ms for cached pages. Re-scan after changes.
TTFB is the delay before the first byte arrives — DNS, connection, TLS, and server work. High TTFB caps how fast everything else can be. This guide targets the server and network layers that cause it.
Check your website
See how your site handles how to fix slow time to first byte (ttfb) — free, no account needed.
Business impact
Visitors stare at a blank screen during TTFB. Even perfect images and scripts cannot compensate for a server that takes two seconds to respond. Fixing TTFB makes the whole site feel instantly snappier.
Why this happens
High TTFB causes: uncached dynamic PHP/database on every request; slow hosting; no CDN; cold starts on serverless; geographic distance to origin; slow TLS handshake; and overloaded shared servers. Measure TTFB in DevTools (Waiting/TTFB) or WebPageTest. Fix caching first, then query optimisation, then infrastructure.
How to confirm the issue
Manually: DevTools → Network → click the document → Timing tab → look at "Waiting for server response".
With Plexa Trust: slow response findings often correlate with high TTFB; re-scan after caching and CDN changes.
Step-by-step fix
Enable full-page or object caching so most requests skip heavy server work.
Put a CDN in front of the site to serve from edge locations closer to users.
Optimise slow database queries and enable query caching (Redis/Memcached).
Enable HTTP/2 or HTTP/3 and TLS 1.3 on the server.
Upgrade hosting or scale resources if CPU/memory is saturated.
Re-scan and compare TTFB in DevTools.
Platform-specific fixes
WordPress
Enable page caching (LiteSpeed, WP Rocket, etc.).
Use object caching (Redis) for database-heavy sites.
Audit slow plugins with Query Monitor.
Cloudflare
Enable CDN proxy (orange cloud) on DNS records.
Use Cache Rules to cache HTML for static/marketing pages where safe.
Enable HTTP/3 and 0-RTT in Network settings.
Nginx / Apache
Enable FastCGI/proxy caching for dynamic apps.
Tune worker processes and keep-alive settings.
Enable Brotli/Gzip at the server level.
Vercel / serverless
Reduce cold starts by keeping functions warm or using edge rendering.
Cache at the edge with ISR or static generation where possible.
How to verify the fix
Cache HTML for pages that do not change every request.
Measure TTFB from regions where your users actually are.
Separate CDN improvements from origin optimisations when diagnosing.
Common mistakes
Optimising front-end assets while TTFB stays above 1 second.
Caching bypassed for all pages when many could be cached.
Ignoring database query time on dynamic CMS sites.
Frequently asked questions
What is a good TTFB?
Under ~200ms for cached responses is excellent; under ~600ms is acceptable for dynamic pages. Above 1s needs attention.
Is TTFB a Core Web Vital?
No, but it directly limits LCP — you cannot paint fast if the server is slow.
Does CDN reduce TTFB?
Yes, by serving from edge locations closer to the user and caching responses at the edge.
Can plugins cause slow TTFB?
Yes. Heavy WordPress plugins running database queries on every request are a common cause.
Should I cache HTML?
For marketing pages and posts that rarely change, yes. Not for personalised or cart pages.
What is serverless cold start?
Delay when a function wakes from idle — spikes TTFB. Mitigate with edge rendering or warm instances.
Does HTTP/3 help TTFB?
It can reduce connection setup time, especially on mobile networks.
How do I confirm it worked?
DevTools TTFB drops; Plexa Trust slow response findings improve on re-scan.
Think you've fixed it?
Run a free scan to verify the issue is resolved. Upgrade to Pro on Plexa Trust for the full audit, monitoring alerts, and score history.
Verify with a free scan