View contents
Server Response Guide: Fixing TTFB at the Root
Introduction
Time to First Byte (TTFB) is the foundation of the entire loading chain: nothing else can happen—not FCP, not LCP, not JavaScript execution—until the browser receives the first byte of HTML. This guide covers how to diagnose and reduce server response time with concrete database, caching, CDN, and hardware techniques. The UXR SEO Analyzer reports the TTFB of every page you analyze in its "Performance" tab.
Because TTFB sits at the very start of the loading chain, it's also the optimization with the widest blast radius: a server-side fix usually applies to every page served by that backend, not just the one you happened to test. That makes it the right place to start any performance effort, even before touching CSS or JavaScript.
Two Thresholds, Not One
It's important to distinguish two numbers that sometimes get confused:
- 600 ms - the threshold for Lighthouse's "Reduce server response times" audit, which fails when the browser waits more than 600 ms for the server to respond to the main document request
- 800 ms - the recommended TTFB threshold as a Core Web Vital ("Good" category)
Lighthouse uses a stricter limit because its "server response time" measurement is only part of the full TTFB. Field TTFB can also include DNS lookups and redirects—for example, if the final slash, the www subdomain, or the https protocol is omitted, the server might redirect to the correct URL before responding with content. That's why Lighthouse applies a smaller limit (600 ms) than the Core Web Vitals recommended TTFB time (800 ms).
Common Causes of Slow TTFB
The server may need to do a lot of work to return a page with all the content users expect. For example, if a user is looking at their order history, the server needs to fetch each order from a database and insert that content into the page. Even when the server doesn't need to do much work, network latency between client and server can result in slow response times.
How to Improve Server Response Times
The first step is identifying the core conceptual tasks your server must complete to return page content, then measuring how long each one takes. Once you've identified the longest tasks, look for ways to speed them up. There are many possible causes of slow server responses, and therefore many possible ways to improve:
1. Optimize Application Logic
Optimize the server's application logic to prepare pages faster. If you use a server framework, check its specific recommendations for reducing response preparation time.
2. Optimize Database Queries
Optimize how your server queries databases, or migrate to faster database systems. Missing indexes and N+1 query patterns are the most frequent causes of slow TTFB in applications with dynamic content.
3. Upgrade Server Hardware
Upgrade your server hardware to have more memory or CPU available when the bottleneck is compute capacity, not inefficient logic.
4. Use a CDN
Use a CDN to reduce network latency. This is particularly effective if the document can be cached at the CDN's edge node, avoiding a round trip to the origin server for every request.
5. Implement Server-Side Caching
Caching full responses or page fragments avoids recomputing the same content on every request. For content that changes infrequently, this is the optimization with the best effort-to-benefit ratio.
A Practical Diagnosis Example
A product page reports a field TTFB of 1400 ms—in the "Needs Improvement" zone. Lighthouse's lab breakdown shows the main document takes 1100 ms to respond, well above the audit's 600 ms limit. Profiling the backend reveals the route runs five separate database queries, three of them without an index on the search column.
After adding the missing indexes and combining two of the queries into a single join, server response time drops to 180 ms. Field TTFB improves to roughly 450 ms a week later, once Google refreshes the CrUX data—a reminder that field changes take time to show up, unlike lab tests which show the effect immediately.
TTFB in Production: Ongoing Monitoring
Measuring TTFB once isn't enough—server load, traffic, and data change over time. Two complementary approaches:
- Synthetic monitoring: run Lighthouse or automated tests periodically from fixed locations, to catch regressions before they reach production
- Real user monitoring (RUM): the
web-vitalslibrary can report each visit's real TTFB to your analytics system, capturing the real variability of devices, networks, and geographic locations that synthetic tests don't reflect
Search Console and the CrUX Core Web Vitals report are the most reliable source for knowing whether your TTFB meets the "Good" threshold for 75% of your real users, which is the criterion Google uses for ranking.
How to Diagnose the Root Cause
- Measure field TTFB with the Search Console Core Web Vitals report or CrUX
- Run Lighthouse to get the "server response time" breakdown under lab conditions
- If the server is slow, profile your slowest database queries first—they're usually the dominant cause
- If server logic is fast but TTFB is still high, suspect network latency or geographic distance to the origin server
Server Response Checklist
- [ ] Field TTFB under 800 ms at the 75th percentile
- [ ] Database queries indexed and free of N+1 patterns
- [ ] Server-side caching enabled for content that doesn't change on every request
- [ ] CDN configured to serve static content and, where possible, cacheable HTML from the edge
- [ ] Redirect chains removed or minimized
Frequently Asked Questions
Why does Lighthouse use 600 ms if the Core Web Vitals threshold is 800 ms?
Because Lighthouse's audit measures only the "server response time" portion of TTFB, without including DNS or redirects that the full TTFB does account for. The stricter limit compensates for that difference in scope.
Does a CDN replace the need to optimize the database?
No, they're complementary. A CDN reduces network latency and can serve cached content without touching your origin server, but any request that has to generate dynamic content still depends on your application and database responding quickly.
Does TTFB directly affect SEO ranking?
TTFB isn't a Core Web Vital by itself, but it's the foundation for LCP, which is a confirmed ranking factor. A slow TTFB delays everything that follows in the loading chain.
Do redirect chains affect TTFB much?
Yes, significantly. Every redirect (for example, HTTP to HTTPS, or non-www to www) adds a full network round trip before the browser receives the first byte of actual content. Two or three chained redirects can, by themselves, push field TTFB from "Good" to "Needs Improvement".
Related Guides
References
- Chrome Developers - Reduce server response times
- Chrome Developers - CrUX methodology: metrics
- web.dev - Core Web Vitals