Time to First Byte (TTFB) measures how long it takes from a user's browser sending a request to receiving the first byte of the response from your server. It is the most fundamental performance metric because every other loading metric — First Contentful Paint, Largest Contentful Paint, fully loaded time — depends on it. You cannot have a fast website with a slow TTFB.
Google has made this explicit: TTFB is now a diagnostic metric in Core Web Vitals, and it directly influences Largest Contentful Paint (LCP), which is a ranking factor. A TTFB of 800ms means your LCP cannot possibly be under 800ms, and in practice it will be significantly higher once rendering time is added. Sites with TTFB under 200ms consistently outperform slower competitors in search rankings.
What Happens During TTFB
TTFB is not a single operation. It is the sum of several sequential steps, each of which can be a bottleneck:
- DNS Lookup (10–80ms): The browser resolves your domain name to an IP address. Using a premium DNS provider (Cloudflare, Route 53) reduces this to under 20ms.
- TCP Connection (10–100ms): The browser establishes a TCP connection to your server. Distance between the user and server adds latency — roughly 1ms per 100km.
- TLS Handshake (20–100ms): For HTTPS sites (which should be all sites), the browser and server negotiate encryption. TLS 1.3 reduces this to a single round trip. HTTP/3 with QUIC can eliminate this entirely for repeat visitors.
- Server Processing (50–2000ms+): This is where the real variation lives. The server receives the request, processes it (running PHP, querying the database, assembling the HTML), and begins sending the response. This step is what most people mean when they talk about "slow TTFB."
- Response Transmission: The first byte travels from the server to the user's browser. This depends on geographic distance and network quality.
What Causes Slow TTFB
1. Slow or Overloaded Hosting
This is the most common cause. Budget shared hosting packs hundreds of sites on a single server, competing for the same CPU, RAM, and disk I/O. When the server is busy processing requests for other sites, your request waits in a queue. There is no amount of WordPress optimization that can fix a server that is fundamentally overloaded.
| Hosting Type | Typical TTFB (uncached) | Typical TTFB (cached) |
|---|---|---|
| Budget Shared Hosting | 500–1200ms | 200–400ms |
| Premium Shared Hosting | 300–600ms | 100–200ms |
| Cloud Hosting (LiteSpeed) | 150–300ms | 15–50ms |
| VPS / Dedicated | 100–250ms | 10–40ms |
The difference between budget shared hosting and cloud hosting with proper caching can be a factor of 10x or more. If your uncached TTFB consistently exceeds 500ms, switching hosts will have a bigger impact than any other optimization.
2. No Page Caching
Without caching, every page request triggers a full PHP execution cycle: WordPress loads, queries the database dozens of times, assembles the page HTML, and sends it back. This process takes 200–800ms on a typical WordPress site, even on good hardware.
With page caching, the server stores the rendered HTML the first time a page is requested and serves that cached copy to subsequent visitors. This skips PHP execution entirely, reducing TTFB to single-digit milliseconds on well-configured servers.
Serverlys Tip: LiteSpeed Cache (included on all Serverlys hosting plans) operates at the server level, serving cached pages before PHP even loads. This produces TTFB under 20ms for cached pages — faster than most application-level caching plugins. See our web server comparison for benchmark details.
3. Slow Database Queries
WordPress sites accumulate database bloat over time: post revisions, transient data, orphaned metadata, spam comments, and unoptimized tables. A single slow database query can add hundreds of milliseconds to TTFB. Sites with thousands of products (WooCommerce) or thousands of posts are particularly susceptible.
4. Unoptimized PHP
Running an outdated PHP version is a surprisingly common performance killer. PHP 8.3 is roughly 3x faster than PHP 7.0 for typical WordPress workloads. Many sites still run on PHP 7.4 or older because their owners never updated. Upgrading PHP is often the single fastest TTFB improvement you can make (test on a staging site first).
5. Too Many Plugins
Each WordPress plugin that hooks into page rendering adds execution time. A site with 40 active plugins might spend 300–500ms just loading plugin code on every uncached request. Most sites can achieve the same functionality with 15–20 well-chosen plugins instead of 40 mediocre ones.
6. No Object Caching
Object caching (Redis or Memcached) stores frequently queried database results in memory, eliminating repeated database calls. For WooCommerce stores and membership sites that cannot use full-page caching on every page (logged-in users, cart pages, dynamic content), object caching reduces TTFB by 40–60%.
7. Geographic Distance
If your server is in New York and your visitors are in Sydney, every request adds 200–250ms of network latency before your server even begins processing. A CDN solves this for static assets, but for the initial HTML document, you need either a server close to your audience or a full-page CDN that caches HTML at edge locations.
How to Measure TTFB
Before optimizing, you need a baseline. Here are the best tools for measuring TTFB:
- Google PageSpeed Insights: Shows TTFB as "Server Response Time" under the Diagnostics section. Tests from Google's infrastructure, which is useful for understanding what Googlebot experiences.
- WebPageTest.org: The most detailed tool. Set multiple test locations to see how TTFB varies geographically. The waterfall chart shows exactly where time is spent.
- Chrome DevTools: Open DevTools → Network tab → click on the HTML document → look at the "Waiting (TTFB)" value in the Timing tab. This measures from your actual location.
- GTmetrix: Shows TTFB prominently in its summary and allows testing from multiple global locations.
- curl command: For a quick server-side test:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://yourdomain.com
What Is a Good TTFB?
| TTFB Range | Rating | Typical Cause |
|---|---|---|
| Under 100ms | Excellent | Well-cached, nearby server |
| 100–200ms | Good | Cloud hosting with caching |
| 200–500ms | Needs improvement | Uncached dynamic pages |
| 500–1000ms | Poor | Slow hosting or no caching |
| Over 1000ms | Critical | Overloaded server, serious issues |
Strategies to Reduce TTFB
Strategy 1: Upgrade Your Hosting
If your TTFB consistently exceeds 400ms, no amount of plugin optimization will fix the problem. The server hardware, web server software, and resource allocation set a floor for your TTFB that application-level changes cannot break through.
Specifically, look for hosts that offer:
- LiteSpeed or Nginx instead of Apache (see our web server comparison)
- NVMe SSD storage (7x faster than SATA SSDs for random reads)
- Modern CPUs with high single-thread performance
- Adequate RAM for your site's size (at least 1 GB for WordPress with WooCommerce)
- HTTP/2 and HTTP/3 support
Strategy 2: Implement Full-Page Caching
This is the single biggest TTFB improvement for most sites. Full-page caching stores the complete HTML output and serves it directly without executing PHP or querying the database.
The best caching solutions, ranked by performance:
- LiteSpeed Cache (LSCache) — Server-level caching, TTFB under 20ms. Requires LiteSpeed web server.
- Nginx FastCGI Cache — Server-level caching, TTFB under 20ms. Requires Nginx.
- Varnish — Dedicated caching proxy, TTFB under 20ms. Requires separate Varnish installation.
- WP Super Cache / W3 Total Cache — Application-level caching, TTFB 30–80ms. Works on any server.
Strategy 3: Enable Object Caching
Install Redis or Memcached on your server and configure WordPress to use it for object caching. This eliminates repeated database queries on pages that cannot be fully cached (cart, account, checkout). Most quality hosting providers include Redis in their plans. Configure it with the Redis Object Cache plugin for WordPress.
Strategy 4: Optimize Your Database
- Remove post revisions: WordPress stores every revision of every post by default. A post edited 50 times has 50 revisions in the database. Use WP-CLI or a plugin to delete old revisions and limit future revisions by adding
define('WP_POST_REVISIONS', 5);to wp-config.php. - Clean up transients: Expired transients accumulate in the wp_options table. Delete them with a database optimization plugin or WP-CLI.
- Add database indexes: For WooCommerce stores, adding proper indexes to the postmeta and order tables can reduce query times by 80%+.
- Optimize tables: Run
OPTIMIZE TABLEon large tables to reclaim space and defragment data.
Strategy 5: Use a CDN
A Content Delivery Network caches your content at edge servers around the world, reducing the physical distance between your server and your visitors. For static assets (images, CSS, JavaScript), a CDN reduces load times dramatically. For HTML pages, some CDNs (Cloudflare, KeyCDN) can cache the full page at the edge, achieving sub-50ms TTFB globally.
Strategy 6: Upgrade PHP
Check your current PHP version in WordPress (Tools → Site Health → Info → Server). If you are running anything below PHP 8.1, upgrading will improve TTFB measurably. Always test the upgrade on a staging site first to catch any plugin compatibility issues.
Strategy 7: Reduce Plugin Count
Audit your plugins ruthlessly. For each plugin, ask: Does this provide genuine value? Is there a lighter alternative? Can this functionality be achieved with a code snippet instead of a full plugin? Deactivate and delete anything you do not actively use.
"We reduced a client's active plugins from 38 to 16 and their uncached TTFB dropped from 720ms to 310ms. Then we enabled LiteSpeed Cache and it dropped to 14ms. The combination of fewer plugins and proper caching produced a 98% improvement."
TTFB and SEO: The Real Connection
Google does not use TTFB directly as a ranking factor, but it directly impacts metrics that are ranking factors:
- Largest Contentful Paint (LCP): One of the three Core Web Vitals. Google considers LCP under 2.5 seconds as "good." Your TTFB sets the minimum floor for LCP — if TTFB is 1 second, your LCP cannot be under 1 second.
- Crawl budget: Googlebot allocates a crawl budget to each site. Slow TTFB means Googlebot crawls fewer pages per session, which can delay indexing of new content. Sites with sub-200ms TTFB get crawled significantly more efficiently.
- User experience signals: Slow TTFB leads to higher bounce rates and lower engagement, which are behavioral signals Google uses for ranking adjustments.
Frequently Asked Questions
What is a good TTFB for WordPress?
For cached pages, aim for under 100ms. For uncached dynamic pages (cart, account, search results), under 400ms is good, under 200ms is excellent. If your cached TTFB exceeds 200ms, your hosting or caching configuration needs improvement.
Does TTFB affect mobile rankings specifically?
Yes. Google primarily uses mobile-first indexing, and mobile connections typically have higher latency than desktop connections. A TTFB that is acceptable on desktop broadband may be problematic when mobile network latency is added on top. This makes server-side TTFB optimization even more critical for mobile performance.
Can a CDN fix bad hosting TTFB?
Partially. A CDN caches content at edge servers, effectively bypassing your origin server for cached requests. However, cache misses, dynamic pages, and API calls still hit your origin server. A CDN masks the problem for some requests but does not fix the underlying server performance. Start with better hosting, then add a CDN for global reach.
How do I measure TTFB for specific pages?
Use Chrome DevTools (Network tab) or WebPageTest.org. Test your homepage, a blog post, a product page, and your checkout page separately. Each page type may have different TTFB characteristics due to different database queries and PHP processing requirements.
Is zero TTFB possible?
Effectively, yes. If your page is cached at a CDN edge location near the visitor, the TTFB can be as low as 5–15ms — essentially just network latency with no server processing. This requires full-page edge caching, which services like Cloudflare APO or LiteSpeed's QUIC.cloud provide.