What Is TTFB? How Server Response Time Affects Your Website
Disclosure: This post contains affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.
Photo by Pixabay — Pexels
You've optimized your images, minified your CSS, enabled caching — and your site still feels sluggish. Before you blame your WordPress theme or throw more plugins at the problem, check your TTFB. It's often the real bottleneck, and it's almost entirely determined by your hosting.
I spent three weeks troubleshooting a client's slow site before I finally checked TTFB. It was 2.8 seconds. Nearly three seconds before the browser even started receiving content. Switched hosts, and it dropped to 180ms. Same site, same code, same theme. The host was the entire problem.
What Is TTFB, Exactly?
TTFB stands for Time to First Byte. It measures the time between a browser requesting a page and receiving the very first byte of the response. That's it. Simple metric, huge implications.
Here's what happens during that window:
- DNS lookup — the browser translates your domain name into an IP address (20-120ms typically)
- TCP connection — browser establishes a connection to the server (depends on distance)
- TLS handshake — if using HTTPS, the encryption negotiation happens (adds 50-100ms)
- Server processing — this is the big one. The server receives the request, runs your PHP/application code, queries the database, builds the HTML, and starts sending it back
Steps 1-3 are largely determined by geography and network infrastructure. Step 4 is where your hosting quality shows up. A slow server with a congested CPU and spinning HDD will take much longer to process the same request than a fast server with NVMe SSD and adequate resources.
What's a Good TTFB?
Google's guidance through Core Web Vitals gives us clear benchmarks:
| TTFB | Rating | What it means |
|---|---|---|
| Under 200ms | Excellent | Your server is fast. No action needed. |
| 200-500ms | Good | Acceptable for most sites. Room for improvement. |
| 500ms-1s | Needs improvement | Noticeable delays. Investigate server-side issues. |
| Over 1 second | Poor | Significant problem. Users are leaving. |
For context: Amazon found that every 100ms of latency cost them 1% in sales. Google discovered that a 0.5-second increase in page load time caused a 20% drop in traffic. These numbers are from massive sites with billions of pageviews, but the principle scales down. Slow sites lose visitors. Period.
Photo by Castorly Stock — Pexels
How to Measure Your TTFB
You can't improve what you don't measure. Here are the tools I use regularly:
1. Browser DevTools (Free, Instant)
Open Chrome → F12 → Network tab → reload your page → click on the first HTML document → look at the "Timing" breakdown. The "Waiting for server response" value is your TTFB.
Pro tip: use incognito mode and test multiple times. Your first load includes DNS resolution; subsequent loads may use cached DNS. Test both scenarios.
2. Google PageSpeed Insights (Free)
Enter your URL at pagespeed.web.dev. The "Server Response Time" or "Time to First Byte" metric appears in the diagnostics section. This tests from Google's infrastructure, so it reflects what their crawler experiences — which is exactly what matters for SEO.
3. WebPageTest (Free)
webpagetest.org lets you test from different global locations. This is critical for understanding TTFB from your actual audience's perspective. A server in Virginia might show 150ms TTFB from the US East Coast but 800ms from Sydney.
4. GTmetrix (Free + Paid)
Gives you a waterfall chart showing exactly where time is spent. The TTFB is highlighted in the first request. The free tier tests from a limited number of locations; paid plans unlock more.
5. curl from Command Line
For developers who want raw numbers:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://yoursite.com
This gives you a precise measurement without browser overhead.
What Causes High TTFB?
In my experience troubleshooting hundreds of slow sites, these are the usual culprits, roughly in order of frequency:
1. Slow Hosting (Most Common)
Overcrowded shared servers, underpowered hardware, slow disk I/O. This is the #1 cause by far. If your TTFB is consistently above 500ms across all pages, it's almost certainly the server.
Budget shared hosting puts hundreds of sites on one server. During peak hours, you're competing for CPU and RAM with everyone else. We covered this dynamic in detail in our guide to shared hosting.
2. No Server-Side Caching
Every uncached request forces the server to execute PHP, query the database, and build the page from scratch. On a WordPress site, this can easily add 500ms-2s to each request. Page caching (WP Super Cache, W3 Total Cache, LiteSpeed Cache) eliminates this by serving a pre-built static version.
3. Unoptimized Database
WordPress databases accumulate bloat: post revisions, transient data, orphaned metadata, spam comments. A database with 50,000 rows of stale data takes longer to query than a lean 5,000-row database. Regular database optimization cuts TTFB noticeably.
4. Heavy PHP Processing
Too many plugins, each hooking into every page load. I've seen sites where 30+ plugins fire on every single request. Each one adds processing time. Audit your plugins — deactivate what you don't need, and replace heavy plugins with lighter alternatives.
5. Geographic Distance
Physics applies to the internet. Data traveling from a server in Germany to a user in Japan goes through multiple hops, each adding latency. A CDN mitigates this for static content, but the initial HTML response still comes from your origin server. Pick a server location close to your primary audience.
Photo by Malte Luk — Pexels
How to Improve Your TTFB
Start with the highest-impact changes and work down:
Step 1: Upgrade Your Hosting
If you're on a cheap shared plan with TTFB above 600ms, no amount of optimization will fix it. You need a better server. Moving from budget shared to quality shared hosting typically cuts TTFB by 40-60%. Moving to a VPS can improve it by 70-80%.
Hosting.com's Turbo shared plans use LiteSpeed servers and NVMe SSDs — I measured TTFB between 120-200ms for a standard WordPress site. Their VPS plans push that even lower with dedicated resources.
InterServer consistently delivers TTFB under 300ms on their standard shared plan — impressive for the $2.50/month price point. Their data centers in New Jersey and LA give good coverage for US-based audiences.
Step 2: Enable Page Caching
This is the single biggest TTFB improvement for WordPress sites. A cached page can load in 50-100ms instead of 500-2000ms.
- LiteSpeed Cache — if your host runs LiteSpeed server (like Hosting.com's Turbo plans), this is the best option. Server-level caching is faster than PHP-based caching.
- WP Super Cache — simple, reliable, free. Generates static HTML files.
- W3 Total Cache — more configuration options, supports object caching with Redis/Memcached.
Step 3: Use a CDN
A CDN caches your static content (images, CSS, JS) at edge servers worldwide. While it doesn't directly reduce TTFB for the initial HTML response, it reduces the total page load time dramatically — and some CDNs (like Cloudflare) can cache HTML at the edge too.
Cloudflare's free plan is the easiest option. Enable it, and your static assets are automatically served from the nearest edge location. We cover this in more detail in our guide to CDNs.
Step 4: Optimize Your Database
For WordPress: install WP-Optimize or Advanced Database Cleaner. Delete post revisions (keep the last 3-5), clean up transients, remove spam and trashed comments, and optimize tables. Schedule weekly cleanups.
Step 5: Reduce Plugin Overhead
Install the Query Monitor plugin to see exactly how much time each plugin adds to page generation. Deactivate any plugin that adds 100ms+ to your load time unless it's absolutely essential. Typical culprits: page builders loading on the frontend, social sharing plugins, broken analytics integrations.
Step 6: Use PHP 8.x
PHP 8.x is significantly faster than PHP 7.x, which was itself twice as fast as PHP 5.6. If your host supports PHP 8.2 or 8.3, switch to it. Most modern WordPress themes and plugins are compatible. The performance improvement is free — just a version change in your hosting panel.
TTFB and SEO: The Connection
Google has confirmed that server response time affects rankings. TTFB is a component of several Core Web Vitals:
- Largest Contentful Paint (LCP) — can't paint content until the first byte arrives. High TTFB pushes LCP later.
- First Contentful Paint (FCP) — directly gated by TTFB.
- Interaction to Next Paint (INP) — server-rendered navigations are affected by TTFB.
A slow TTFB doesn't just affect one metric — it cascades through all of them. Fix TTFB and you'll likely improve multiple Core Web Vitals simultaneously. Read more about this relationship in our article on how hosting affects SEO.
TTFB by Hosting Type: What to Expect
| Hosting type | Typical TTFB range | Notes |
|---|---|---|
| Budget shared hosting | 600ms – 2s+ | Highly variable, depends on server load |
| Quality shared hosting | 200-500ms | With caching, can drop under 200ms |
| Managed WordPress | 100-300ms | Optimized server stack for WordPress |
| VPS (unmanaged) | 100-400ms | Depends on your configuration |
| VPS (managed) | 100-250ms | Pre-optimized by the host |
| Dedicated server | 50-200ms | No shared resources |
| Edge/CDN cached | 20-80ms | Served from the nearest edge node |
These are for WordPress sites with basic caching enabled. Static sites will be faster across the board. Heavy web applications with complex database queries will be slower.
Photo by Muffin Creatives — Pexels
Frequently Asked Questions
Is TTFB the same as page load time?
No. TTFB is just the beginning — it measures when the first byte arrives. Page load time includes downloading all resources (HTML, CSS, JS, images), parsing, and rendering. A good TTFB doesn't guarantee a fast page (you could have massive images), but a bad TTFB guarantees a slow one.
Does TTFB matter for static sites?
Less so. Static sites don't have server-side processing, so TTFB is mostly network latency and disk I/O. It's still worth optimizing (use a CDN), but you won't see the dramatic differences that dynamic sites experience.
Can a CDN fix bad TTFB?
For cached content, yes. If Cloudflare caches your HTML at the edge, the TTFB your visitors experience is the CDN's response time (typically 20-80ms), not your origin server's. But for uncached requests (logged-in users, dynamic pages), the CDN passes through to your server — and slow TTFB returns.
Why does my TTFB vary between tests?
Several reasons: server load fluctuations (especially on shared hosting), caching warm-up (first request builds the cache, subsequent requests are faster), DNS resolution time, and network congestion. Always test multiple times and average the results.
Is 400ms TTFB okay?
It's acceptable but not great. For a blog or informational site, 400ms won't cause major issues. For an ecommerce site where every millisecond affects conversion rates, aim for under 200ms. The goal is always "as fast as reasonably achievable" without over-engineering.
The Bottom Line
TTFB is the foundation of your site's speed. You can optimize everything else perfectly — image compression, code minification, lazy loading — and still have a slow site if your server takes a full second to start responding.
Measure your TTFB today. If it's above 500ms, start with the hosting. A switch to Hosting.com or InterServer combined with proper caching can bring that number down to 150-250ms — and the difference will be immediately noticeable to your visitors and your Google rankings.
Fix the server first. Then optimize everything else. That's the order that actually moves the needle.
Comments
Post a Comment