Core Web Vitals12 min
What is LCP? Complete Guide to Largest Contentful Paint
Master Largest Contentful Paint (LCP) - Google's key Core Web Vital for measuring loading performance. Learn what LCP is, why it matters for SEO, and how to optimize it.
What is TTFB? Complete Guide to Time to First Byte
Comprehensive guide to Time to First Byte (TTFB). Learn what TTFB measures, good TTFB benchmarks, how to diagnose slow server response, and proven optimization techniques.
Published January 9, 2025Updated January 13, 202511 min read
Key Takeaways
- 1TTFB measures server response time and sets the baseline for all other metrics
- 2Use a CDN to reduce geographic latency - the highest-impact TTFB optimization
- 3Target TTFB under 200ms for optimal performance, under 800ms as minimum acceptable
What is Time to First Byte (TTFB)?
Time to First Byte (TTFB) measures how long it takes from when a user's browser requests a page to when it receives the first byte of the response. It includes DNS lookup, TCP connection, TLS negotiation, and server processing time.
TTFB is a foundational metric because everything else depends on it. Your LCP can't possibly be 2 seconds if your TTFB is already 3 seconds. Fast TTFB is a prerequisite for good Core Web Vitals.
While not a Core Web Vital itself, TTFB is increasingly important for Google rankings as part of overall page experience. Google recommends TTFB under 800ms, though under 200ms is ideal.
- TTFB measures time from request start to first response byte
- Includes: DNS + TCP + TLS + Server Processing + Network Transit
- Good TTFB: under 200ms | Acceptable: under 800ms | Poor: over 800ms
- TTFB directly impacts all other performance metrics
Why TTFB matters for performance
TTFB sets the baseline for your entire page load. If your server takes 2 seconds to respond, your LCP mathematically cannot be under 2 seconds. Fast TTFB is the foundation for passing Core Web Vitals.
High TTFB often indicates backend problems: slow database queries, unoptimized code, insufficient server resources, or missing caching. It's a canary in the coal mine for infrastructure issues.
For SEO, slow TTFB means Googlebot spends more time crawling your site, potentially leading to fewer pages being indexed. Google's crawl budget is limited, and slow servers waste it.
Pro tip: Amazon found that every 100ms of latency cost them 1% in sales. Much of that latency starts at TTFB - the fastest front-end optimizations can't fix a slow server.
What affects TTFB?
DNS resolution can add 20-200ms depending on your DNS provider and whether results are cached. Using fast DNS providers like Cloudflare (1.1.1.1) or Google (8.8.8.8) helps.
TCP and TLS handshakes require round trips that scale with geographic distance. A user in Australia connecting to a server in Virginia faces 200ms+ just in network latency.
Server processing time depends on your backend efficiency: database queries, API calls, server-side rendering complexity, and available compute resources.
- DNS lookup: 20-200ms depending on caching and provider
- TCP connection: 1 round trip (varies by distance)
- TLS handshake: 1-2 round trips for HTTPS
- Server processing: Highly variable based on backend
- Network transit: Limited by speed of light and routing
How to measure and test TTFB
Use MakeWebsite.fast's TTFB checker to test server response time from edge locations. This shows how TTFB varies by geography - crucial if you have a global audience.
Chrome DevTools Network panel shows TTFB for every request. Look for 'Waiting (TTFB)' in the request timing breakdown. High values indicate server-side issues.
For comprehensive analysis, combine lab tools with real user monitoring (RUM). Your own testing from a fast connection won't reveal how users on slow networks experience your site.
- MakeWebsite.fast TTFB Checker: Quick server response testing
- Chrome DevTools: Detailed request timing breakdown
- WebPageTest: Multi-location TTFB testing
- Real User Monitoring: Actual visitor TTFB data
How to improve TTFB
Use a Content Delivery Network (CDN) to serve content from edge locations close to users. This eliminates the geographic penalty for distant users and can cut TTFB by 50-80%.
Implement caching at every layer: browser caching, CDN caching, application caching, and database query caching. The fastest response is one that doesn't need to hit your origin server at all.
Optimize your backend: index database queries, use connection pooling, implement efficient algorithms, and ensure adequate server resources. Sometimes the simplest fix is upgrading to a faster hosting plan.
Pro tip: A CDN is the single most impactful TTFB optimization for most sites. It moves content physically closer to users, reducing latency that no amount of code optimization can overcome.
TTFB optimization checklist
Systematically work through this checklist to reduce TTFB. Start with the highest-impact changes (CDN, caching) before diving into backend optimization.
Monitor TTFB continuously with tools like MakeWebsite.fast. TTFB can regress quickly with new deployments, traffic spikes, or infrastructure changes.
- Implement a CDN (Cloudflare, Fastly, AWS CloudFront)
- Enable server-side caching (Redis, Memcached)
- Optimize database queries (indexes, query optimization)
- Use a fast DNS provider (Cloudflare, Route 53)
- Enable HTTP/2 or HTTP/3 for connection reuse
- Consider static site generation for applicable pages
- Upgrade hosting if CPU/memory bound
- Implement connection pooling for database connections
Get weekly performance tips
Frequently Asked Questions
What is a good TTFB?+
Google recommends TTFB under 800ms, but ideally aim for under 200ms. Top-performing sites typically achieve 50-100ms TTFB by using CDNs and aggressive caching. Remember that TTFB varies by location - test from where your users are.
Is TTFB a Core Web Vital?+
No, TTFB is not officially a Core Web Vital, but it directly impacts LCP which is. Think of TTFB as a prerequisite - you can't have good Core Web Vitals with poor TTFB. Google does track and report TTFB in its tools.
Why is my TTFB different from different locations?+
TTFB includes network latency, which increases with geographic distance. A user in New York connecting to a server in New York might see 20ms TTFB, while a user in Tokyo connecting to the same server might see 200ms due to the physical distance data must travel.
M
Verified AuthorExpert ContentRegularly Updated
Performance Newsletter
Weekly tips to make your website faster
Join 5,000+ developers getting actionable performance optimization tips, Core Web Vitals updates, and speed testing insights.
No spam. Unsubscribe anytime.