If you’ve run your WordPress site through Google PageSpeed Insights and seen a warning about server response time, you’ve encountered TTFB — Time to First Byte. It’s the measurement of how long it takes from when a browser requests your page to when it receives the very first byte of data back. A slow TTFB means every other element on the page is delayed before it even starts loading.
TTFB became a standalone metric in Google’s Core Web Vitals assessment. Google’s target is under 800ms, with under 200ms considered good. Most default WordPress installations on shared hosting sit well above that threshold — often between 600ms and 1,500ms — not because of bad code, but because of how WordPress generates pages and where they’re hosted.
The good news is that most TTFB problems in WordPress have straightforward fixes. This guide covers the most effective ones in order of impact, so you can work through them until your numbers are where they need to be.
Quick Answer
The biggest single improvement to TTFB comes from enabling full-page caching. When caching is on, WordPress serves pre-built HTML files instead of generating each page from scratch on every request. That alone typically brings TTFB from 600–1,500ms down to 100–300ms. After caching, the next most impactful fixes are database optimisation, upgrading your hosting plan, and using a CDN to reduce network latency.
Why TTFB Matters for Your WordPress Site
TTFB affects every other performance metric because nothing else can load until that first byte arrives. A slow TTFB delays Largest Contentful Paint (LCP), pushes up your total page load time, and contributes to poor Core Web Vitals scores — all of which Google factors into how it evaluates your pages.
Beyond search ranking, it affects real users. A visitor on a slow connection who waits more than a second before anything loads is more likely to leave before the page finishes rendering. For pages where you want people to read, click, or buy, that delay has a measurable cost.
You can check your TTFB using PageSpeed Insights (look under Server response times (TTFB) in the Diagnostics section) or in Chrome DevTools under the Network tab by clicking on the first document request and looking at Waiting for server response.
How to Reduce TTFB in WordPress
Step 1 — Enable Full-Page Caching
This is the most impactful fix for most WordPress sites. Without caching, every page request triggers WordPress to run PHP, query the database, and assemble the HTML response before sending anything back. With a WordPress caching plugin enabled, it serves a static HTML file instead — far faster.
LiteSpeed Cache works at the server level if your host runs LiteSpeed (many shared hosts do). WP Rocket and W3 Total Cache are the most common alternatives on other server types. After installing and enabling full-page caching, test a page in PageSpeed Insights before and after — the TTFB improvement is usually immediate and significant.
One thing to verify: make sure caching is actually being served to visitors. Some configurations exclude logged-in users, which is intentional. Test from an incognito browser or log out before benchmarking.
Step 2 — Optimise Your WordPress Database
WordPress accumulates overhead in its database over time — post revisions, expired transients, orphaned metadata, spam comments, and auto-draft posts. Each query WordPress runs has to search through that clutter, adding processing time before the page can begin building.
Clean the database using a plugin like WP-Optimize or through your hosting control panel’s phpMyAdmin. The key tables to target are wp_posts (remove revisions and drafts), wp_options (remove autoloaded transients), and wp_commentmeta (remove spam and trash). In most caching plugins, there’s also a built-in database cleanup option — check the plugin’s tools section before installing a separate plugin for this.
Step 3 — Use a CDN to Reduce Network Latency
TTFB includes network latency — the time for the request to travel from the visitor’s device to your server and back. If your server is in the US and a visitor is in Australia, that round trip adds meaningful time regardless of how fast your server responds.
A CDN (Content Delivery Network) routes visitors to the nearest edge node, which either serves the cached response directly or forwards the request to your origin server over an optimised connection. Either way, the round-trip time drops. Many hosting plans include CDN features, and standalone options are available at various price points. Look for one that supports HTML caching (full-page CDN), not just static assets — that’s what reduces TTFB rather than just image load times.
Step 4 — Reduce PHP Processing Time
Even with caching, uncached requests (admin pages, cart pages, checkout pages) still depend on PHP execution speed. Two things directly affect this: the PHP version running on your server and the number of active plugins.
Check your PHP version in your hosting control panel or under WordPress Tools > Site Health. PHP 8.1 and 8.2 are significantly faster than PHP 7.4, which many older WordPress installations still run. If you’re on 7.x, upgrading PHP is a quick win that doesn’t require touching any plugin or theme settings.
For plugins, deactivate anything you’re not actively using. Every active plugin adds to WordPress’s initialisation overhead, even if the plugin isn’t used on the specific page being loaded. It adds up. A site with 30 active plugins that could work with 12 is doing unnecessary work on every uncached request.
Step 5 — Upgrade Your Hosting If Needed
Shared hosting puts multiple websites on the same server, which means your site’s TTFB is affected by what other sites on that server are doing. In my experience, shared hosting TTFB sits between 600ms and 1,200ms under typical conditions — workable with aggressive caching, but with a ceiling that can’t be optimised past.
If you’ve enabled caching, optimised your database, and upgraded PHP, and you’re still seeing TTFB above 400ms in PageSpeed Insights, the hosting plan itself is likely the constraint. Moving to a managed WordPress host or a VPS typically brings baseline uncached TTFB down to 100–250ms, at which point caching keeps the served TTFB well within Google’s recommended range. For improving your Core Web Vitals scores overall, better hosting is often the highest-leverage change you can make.
Practical Tips
Measure in the right place. PageSpeed Insights shows lab TTFB (a controlled test), while Google Search Console’s Core Web Vitals report shows real-user TTFB across actual visits. Both are useful, but the Search Console data is what Google uses when assessing your site. If your lab number looks good but Search Console still shows poor TTFB, it often means real visitors are hitting uncached or dynamic pages more often than you expect.
TTFB has two parts. The total TTFB includes DNS lookup, TCP connection, and TLS handshake time in addition to the actual server processing time. If your TTFB is high but your server itself is fast, the issue may be DNS or connection setup. A CDN resolves this by maintaining persistent connections at the edge.
Benchmark consistently. Run PageSpeed Insights three times and average the results — it varies by run. Test from the same region each time if you’re using the API or a tool that lets you choose a test location.
Common Mistakes
Optimising images and CSS first. These affect Largest Contentful Paint and load time but do nothing for TTFB. If your PageSpeed report flags server response time, that’s what needs addressing — start there, not with compression tools.
Not testing before and after. Making multiple changes at once makes it impossible to know which one improved your score. Apply each fix, test, record the result, then move to the next one.
Installing a cache plugin but leaving it on default settings. Most caching plugins require you to turn on full-page caching explicitly — it’s often not the default. Check that page caching is actually enabled after installation, not just the plugin itself.
When to Optimise vs When to Upgrade
Optimisation (caching, database cleanup, PHP version, plugin reduction) can get most shared hosting TTFB to an acceptable range if the baseline server is reasonable. If your hosting is reasonable quality, those fixes are worth doing before spending money on a plan upgrade.
Upgrading hosting makes sense when: you’ve done all the above and TTFB is still consistently above 600ms on cached pages, your site has grown in traffic and the shared environment is showing strain, or you need reliable low TTFB for WooCommerce checkout pages (which can’t be cached and always run as live PHP requests).
Conclusion
Enable full-page caching first — it’s the single biggest lever for TTFB on almost every WordPress site. Run PageSpeed Insights before and after to confirm the improvement, then decide whether further steps are needed based on what the numbers actually show rather than chasing marginal gains before you know where the real problem is.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.