To reduce TTFB, enable full-page caching, optimize database queries, and use a host with fast hardware (NVMe + LiteSpeed/Nginx). With those three changes, most WordPress or PHP sites drop from 600 ms to under 200 ms without touching a single line of front-end code.
This guide covers exactly what TTFB is, why it spikes, and which actions to take — in order of impact — to bring it down.
What Is TTFB and Why Does It Matter?
Time to First Byte (TTFB) measures how many milliseconds it takes the browser to receive the first byte of response from the server after sending an HTTP request. It is the most direct measure of back-end performance.
Google recommends keeping it below 800 ms; optimal values are under 200 ms. A high TTFB damages the Largest Contentful Paint (LCP) because everything else — CSS, images, JavaScript — has to wait for that first byte to arrive.
How to measure it? Use any of these tools:
- Chrome DevTools → Network → HTML document (column "Waiting for server response")
- WebPageTest.org — shows TTFB by region and repeat view
- PageSpeed Insights — flags it if it exceeds 600 ms under "Reduce server response times"
Common Causes of High TTFB
Before applying fixes, identify the root cause:
- Slow or overloaded hosting — shared servers cramming hundreds of sites onto an HDD.
- Unoptimized database — slow queries, tables missing indexes, or too many queries per page load.
- PHP without OPcache — without OPcache, PHP recompiles every file on every request.
- Inefficient plugins or code — in WordPress, some plugins fire 50-100 SQL queries per visit.
- No full-page cache — the server regenerates HTML on every visit.
- No CDN — geographic distance between visitor and server adds pure network latency.
Step 1 — Enable Full-Page Caching
This is the highest-impact action. Instead of running PHP + MySQL on every request, the server returns a pre-built static HTML file in microseconds.
- WordPress: install WP Rocket, LiteSpeed Cache, or W3 Total Cache. With LiteSpeed Cache on a LiteSpeed server, TTFB can drop to 50-80 ms.
- Generic PHP / custom site: implement file-based static cache or use Redis / Memcached as an object cache.
- cPanel: enable OPcache under "MultiPHP INI Editor" → select PHP 8.x → set
opcache.enable = 1.
With OPcache active, the average gain in PHP is a 30-50% reduction in processing time.
Step 2 — Optimize Database Queries
If caching is on but TTFB is still high on dynamic pages (cart, user dashboard), the bottleneck is usually MySQL/MariaDB.
- Enable the slow query log:
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; - Analyze slow queries with
EXPLAIN SELECT ...and add missing indexes. - Enable MariaDB's query cache, or use Redis as a WordPress object cache via the Redis Object Cache plugin.
- Reduce query count: in WordPress, the Query Monitor plugin shows exactly how many queries each plugin fires.
Step 3 — Move to Faster Hosting If Hardware Is the Bottleneck
No code optimization compensates for a shared HDD server hosting 500 sites. If after enabling caching and OPcache your TTFB is still above 400-500 ms, the problem is the hosting plan itself.
| Hosting type | Typical TTFB (no cache) | Typical TTFB (with cache) |
|---|---|---|
| Shared HDD | 800 ms – 2 s | 200 – 400 ms |
| Shared NVMe + LiteSpeed | 300 – 600 ms | 50 – 150 ms |
| VPS NVMe (Nginx/LiteSpeed) | 100 – 300 ms | 20 – 80 ms |
| Cloud managed (Cloudways, Kinsta) | 80 – 200 ms | 15 – 60 ms |
If you need help choosing or migrating, the team at elenlace.com handles zero-downtime migrations with a full performance review included.
Step 4 — Use a CDN to Cut Geographic Latency
A CDN does not reduce server processing time, but it eliminates network latency when the visitor is far from your datacenter. Cloudflare's free plan caches static assets, and its APO (Automatic Platform Optimization) add-on for WordPress serves full HTML from the edge.
For a site with visitors in Latin America and a server in the US, a CDN with a local PoP can shave 80-120 ms of pure network latency. Explore more strategies in our web performance articles.
Key Takeaways
- The ideal TTFB is under 200 ms; above 800 ms it hurts LCP and Google rankings.
- Full-page caching (WP Rocket, LiteSpeed Cache) is the highest-impact, fastest fix to apply.
- OPcache must be active on any PHP server; without it, every visit recompiles all source files.
- Slow database queries are the second most common bottleneck; use Query Monitor and EXPLAIN.
- If hardware is the limit (shared HDD), no code optimization will save you: migrate to NVMe + LiteSpeed.
- A CDN complements everything above by eliminating geographic latency.
Ready to leave slow TTFB behind? The team at elenlace.com audits your server, pinpoints the exact bottleneck, and fixes it — reach out today and see results this week.
FAQ
What is a good TTFB value?
Google considers a TTFB below 800 ms "good," but competitive sites aim for under 200 ms. With caching enabled on an NVMe server, values of 50-100 ms are achievable.
Does TTFB directly affect SEO?
There is no ranking factor explicitly called "TTFB," but it directly impacts LCP, which is one of the Core Web Vitals that Google does use as a ranking signal. A high TTFB makes a good LCP score impossible.
Can I reduce TTFB without changing hosts?
Yes, in many cases. Enabling page caching, OPcache, and optimizing SQL queries can cut it in half without migrating. But if you are on a shared HDD server and have already done all that, the optimization ceiling is low — that is when migrating makes sense.
Does Cloudflare reduce TTFB?
Cloudflare reduces network latency (packet travel time) thanks to its global edge network. If you enable APO for WordPress, it also caches full HTML at the edge, which dramatically reduces perceived TTFB from any country.
Useful resources
Other providers and guides worth comparing:
