What is Time to First Byte (TTFB)?
Learn what Time to First Byte (TTFB) means, why it matters for search rankings, and how consistent content publishing keeps your business visible in Google.
Definition
Time to First Byte (TTFB) is a speed metric that measures how long it takes for a browser to receive the first byte of data from the server after requesting a web page.
What Is Time to First Byte (TTFB)?
Time to First Byte (TTFB) measures the duration from when a browser makes an HTTP request to when it receives the first byte of the server’s response. It captures the server’s responsiveness before any content actually starts loading on the page.
TTFB includes three phases:
- Request travel time — The browser sends the request to the server
- Server processing time — The server processes the request, queries databases, runs application code
- Response travel time — The server sends the first byte back to the browser
TTFB does NOT include:
- DNS lookup time (though some tools measure this separately)
- SSL/TLS handshake time (also measured separately)
- Time to download the full page
- Time to render the page
Why TTFB Matters
TTFB is the foundation of page speed. Every other speed metric depends on it. If TTFB is slow, even the most optimized frontend cannot achieve good performance.
The cascading effect:
| Metric | Depends On |
|---|---|
| TTFB | Server response time |
| First Contentful Paint (FCP) | TTFB + render-blocking resources |
| Largest Contentful Paint (LCP) | TTFB + resource load times |
| Total Page Load Time | TTFB + all resource downloads |
Example: If TTFB is 2 seconds, even with perfect frontend optimization, LCP cannot be faster than 2 seconds plus the time to load the largest content element.
TTFB Scoring Thresholds
| Rating | Time | Impact |
|---|---|---|
| Good | ≤ 600 milliseconds | Fast server response, quick page starts |
| Needs Improvement | 600 - 1800 milliseconds | Noticeable delay before content appears |
| Poor | > 1800 milliseconds | Users perceive the site as very slow |
Target: Keep TTFB under 600ms for the best user experience.
What Causes Slow TTFB
1. Slow Hosting
Budget shared hosting plans often have slow server response times due to overcrowded servers.
Fix: Upgrade to VPS, dedicated, or cloud hosting. Use hosting near your target audience.
2. Database Queries
Complex or unoptimized database queries can take seconds to execute.
Fix:
- Add database indexes
- Optimize slow queries
- Use query caching
- Implement object caching (Redis, Memcached)
3. Server-Side Code
Heavy server-side processing — PHP, Python, Node.js — delays the response.
Fix:
- Profile and optimize application code
- Use opcode caching (OPcache for PHP)
- Minimize server-side rendering complexity
4. No Caching
Without caching, every request regenerates the entire page from scratch.
Fix:
- Implement page caching (Varnish, Nginx FastCGI cache)
- Use CDN edge caching
- Enable browser caching
5. Network Latency
Physical distance between the user and server affects TTFB.
Fix: Use a Content Delivery Network (CDN) to serve content from edge locations near users.
How to Measure TTFB
Browser DevTools
In Chrome DevTools Network tab:
- Open DevTools (F12)
- Go to Network tab
- Reload the page
- Click the first request (the document)
- Look at “Waiting for server response” in the Timing tab
WebPageTest
WebPageTest provides detailed TTFB measurements from multiple global locations:
- First View TTFB
- Repeat View TTFB
- TTFB by location
Google Search Console
Core Web Vitals report shows TTFB data from real Chrome users (field data).
Command Line
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\n" https://example.comHow to Improve TTFB
Hosting Optimizations
| Tactic | Expected Improvement | Effort |
|---|---|---|
| Upgrade hosting plan | 200-1000ms | Low |
| Use hosting near your audience | 50-300ms | Low |
| Enable HTTP/2 or HTTP/3 | 50-200ms | Low |
| Use a CDN | 100-500ms | Low |
Application Optimizations
| Tactic | Expected Improvement | Effort |
|---|---|---|
| Implement page caching | 300-2000ms | Medium |
| Optimize database queries | 100-1000ms | Medium |
| Use opcode caching | 50-200ms | Low |
| Reduce server-side rendering | 100-500ms | Medium |
| Enable compression (Brotli/Gzip) | 20-50ms | Low |
Code Optimizations
| Tactic | Expected Improvement | Effort |
|---|---|---|
| Minimize plugins/modules | 50-300ms | Medium |
| Lazy load non-critical resources | 20-100ms | Low |
| Remove unused code | 20-100ms | Medium |
| Optimize autoloaders | 10-50ms | Low |
TTFB by Platform
| Platform | Typical TTFB | Optimization Potential |
|---|---|---|
| Static HTML (CDN) | 50-150ms | Already optimal |
| WordPress (cached) | 100-300ms | Good with caching |
| WordPress (uncached) | 500-2000ms | High — implement caching |
| Shopify | 200-500ms | Limited — platform-controlled |
| Custom application | 100-1000ms | Depends on code quality |
TTFB Myths
Myth: TTFB is the most important speed metric.
TTFB is important but not sufficient. A page with 200ms TTFB but 10-second LCP is still slow. Optimize TTFB first, then focus on other metrics.
Myth: You need perfect TTFB to rank well.
Google considers TTFB as part of Page Experience, but content relevance and quality remain the primary ranking factors. A page with 800ms TTFB and excellent content can outrank a page with 200ms TTFB and mediocre content.
Myth: TTFB only matters for the homepage.
Every page has its own TTFB. Product pages, category pages, and blog posts all need fast server responses. Test TTFB for your highest-traffic page templates.
Related Terms
From understanding Time to First Byte (TTFB) to ranking for it
Understanding Time to First Byte (TTFB) is the starting point. The businesses that actually benefit from it are the ones consistently publishing SEO content. Not just understanding the concept. Most companies know what they should be doing; the bottleneck is execution. theStacc removes that bottleneck by publishing 30 keyword-optimized articles to your site every month, automatically.
See how theStacc worksRelated Terms
A Content Delivery Network (CDN) is a distributed network of servers that caches and delivers website content from locations closer to users, reducing load times and improving global performance.
Core Web Vitals are Google's metrics for measuring page experience: LCP, INP, and CLS. Learn what each metric means, how to measure them, and improvement.
Largest Contentful Paint (LCP) is a Core Web Vitals metric that measures how long it takes for the largest visible content element on a page to load and render, indicating perceived load speed.
Page speed is how fast the content on a web page loads and becomes interactive for users. It's a confirmed Google ranking factor that directly affects.
Server response time is the amount of time it takes for a web server to respond to a browser request, measured as Time to First Byte (TTFB), and is a foundational factor in overall page speed and user experience.
Build rankings around terms like "Time to First Byte (TTFB)". Automatically
30 keyword-optimized articles published to your site every month. Rankings compound while you focus on your business.
Start Your $1 Trial$1 for 3 days · Cancel anytime