Server response time (TTFB): why it still matters for SEO
Core Web Vitals dropped time to first byte, but a slow server still costs you crawl budget and AI crawler patience. Here is what to fix.
Core Web Vitals used to score time to first byte directly. Google dropped it from the official set years ago in favor of Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, all of which measure what a user sees and feels. That change didn't make server response time unimportant. It just moved it upstream: a slow server is now a hidden cause behind a slow LCP, and it quietly limits how much of your site Googlebot and AI crawlers bother to fetch in a given visit.
What TTFB actually measures
Time to first byte (TTFB) is the gap between a request going out and the first byte of the response coming back. It bundles DNS lookup, the TCP and TLS handshake, and the time your server takes to build the response, all before any HTML has even started downloading. A fast TTFB doesn't guarantee a fast page. A slow one guarantees that everything after it starts late.
- DNS resolution for the domain
- TCP connection and TLS negotiation
- Server-side processing: database queries, template rendering, third-party API calls
- The network trip back to whoever asked, human browser or crawler
Why crawlers and AI bots care
Search and AI crawlers work under a budget, not an unlimited clock. Googlebot's crawl budget for a site is shaped partly by how fast and reliably it responds: slow, error-prone servers get crawled less, not more patiently. AI crawlers like GPTBot, ClaudeBot, and PerplexityBot behave in similar ways, though none of them publish an exact timeout or retry policy, so treat any specific number you see quoted online as an estimate, not a spec. What holds across all of them is simpler: a page that takes several seconds to start responding gets fetched less often, and a request that times out tends to get skipped rather than retried right away.
The practical effect is a slower feedback loop. If your server is slow, crawlers spend their limited budget waiting instead of requesting more pages, so new and updated content takes longer to get indexed by Google or picked up by an AI engine's next crawl.
What slows it down
- Rendering the full page on every request instead of caching the HTML
- Running several database queries or third-party API calls before the first byte can be sent
- Cold starts on serverless functions that spin up fresh after being idle
- No CDN or edge cache, so every request travels all the way to one origin server
- An origin server located far from most of your visitors and crawler requests
- A shared host under load from other sites on the same box
How to measure it
You can't fix what you haven't measured. Chrome DevTools' Network tab shows TTFB in the waterfall for any single request. WebPageTest and Google PageSpeed Insights both report it, tested from several locations, usually labeled server response time. For a more direct read, run curl with the time_starttransfer timing variable from a few different regions, or pull real numbers from your own server logs: filter for the gap between request and first response byte on actual crawler visits, not just synthetic tests.
How to fix it
- Cache rendered HTML at the edge so most requests never reach your origin server
- Move expensive work, like database joins or third-party calls, out of the request path with pre-computation or background jobs
- Avoid architectures where a crawler's request can land on a cold serverless start
- Put your origin, or at least a cache layer, close to where your traffic and target markets actually are
- Set a performance budget for TTFB, under 200 milliseconds is a reasonable target for a cached page, and monitor it continuously instead of checking once after launch
TTFB isn't scored in Core Web Vitals anymore, but it still sets the ceiling for LCP, and it decides how much of your site crawlers bother to fetch in the first place. If you haven't checked your server response time this year, that's the first thing to measure, before you touch a single meta tag.