Is TTFB the same as server response time?

Almost. Server response time is the part spent on the server generating the answer; TTFB adds the network legs before it: DNS, connection and TLS setup, and the transfer of the first byte back. On a fast network the two are close.

Does TTFB affect rankings?

Google's crawl budget documentation ties response time, including time to first byte, to the crawl capacity limit, not to ranking. A slow server gets crawled less and refreshed later; page speed as a ranking factor is a separate topic.

Google's crawling documentation gives no millisecond threshold. It talks about stability: if response times stay stable or improve, the crawl limit goes up; if they get longer, it goes down. Compare against your own baseline rather than a universal number.

Why is TTFB slow only for logged-out users or bots?

Because those requests miss the cache. Logged-in sessions often bypass the page cache, and crawlers hit URLs nobody has requested recently, so they see the uncached generation time.

For cached pages, yes: the edge answers without contacting the origin. For uncached or dynamic pages the CDN adds a hop, so the origin still has to be fast.

How often should I measure it?

Continuously or at least daily, from the same location, because a single curl run shows one request on one day. Trends and spikes after a deploy are what matter.

TTFB (time to first byte)

TTFB, time to first byte, is the time between sending a request and receiving the first byte of the response. It covers DNS lookup, the TCP and TLS handshakes, the request itself and the server's work before it starts answering. Google's crawl budget documentation names time to first byte as one of the response-time signals that raise or lower how much Googlebot crawls a site.

TTFB is the delay before the first byte of a response arrives: network setup plus the server's thinking time. Google's crawl documentation says stable or improving response times raise the crawl capacity limit and slower ones lower it.

What it measures

A request goes through several steps before any content comes back:

DNS lookup of the hostname.
TCP connection to the server.
TLS handshake for HTTPS.
Sending the request.
The server building the response: application code, database queries, template rendering, calls to other services.
The first byte travelling back.

TTFB is the sum of all six. Steps 1-4 and 6 are network and depend on distance and configuration; step 5 is the server response time and is usually the largest and most variable part on dynamic sites. A static file from a CDN edge can have a TTFB dominated by the network legs; a WordPress product page without cache is dominated by step 5.

How it looks

With curl you can print each stage with the -w option:

curl -s -o /dev/null -w "dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n" https://example.com/

time_starttransfer is the TTFB. The gap between time_appconnect and time_starttransfer is roughly the server's own response time. Run it a few times; the first request pays for DNS and TLS, later ones in a warm session may not.

How Google handles it

Google's crawl budget documentation lists crawl health as the first factor behind the crawl capacity limit. If the site responds consistently and its response times, including latency and time to first byte, remain stable or improve, the limit goes up and more connections can be used to crawl. If the site slows down, with increased latency or longer response times, or responds with 5xx errors or rate-limiting signals such as HTTP 429, the limit goes down and Google crawls less. The same guide, under making pages efficient to load, says that if Google can load and render pages faster, it may read more content from the site, and recommends optimizing server response times.

The Crawl Stats report documentation reflects this: it reports the average response time for all resources fetched during the period and suggests checking which file types are slow when you see availability issues or slow response rates. Google's crawling documentation does not publish a target number for either metric, so there is no official millisecond threshold to quote. What it describes is direction: stable or faster is rewarded, slower or erratic is penalised with fewer crawls.

The budget mechanics are explained in the entry on crawl budget. A practical consequence for large sites: pages stuck in Discovered - currently not indexed are often waiting on a crawl that a slow host keeps postponing.

Typical causes of a slow TTFB

Cause	What happens
Shared or undersized hosting	CPU and I/O contention; response time swings with other tenants' traffic
No page cache	Every request runs the full application stack and database queries
Slow or unindexed database queries	Product listings and search pages wait on the database
External calls during rendering	APIs, payment or stock lookups block the response
Heavy plugins or middleware	Each adds work before the first byte
Origin far from users and crawlers, no CDN	Network legs add latency on every request
Cold caches after a deploy or cache purge	TTFB spikes until pages are regenerated
TLS misconfiguration	Handshake takes longer than it should, or renegotiates

A CDN helps only for responses it can cache. For dynamic pages the origin still does the work, and the CDN adds a hop. Full-page caching at the origin or edge is the single change that moves TTFB most on content sites.

How to measure it

curl, as above, gives one sample per run. Loop it ten times and look at the spread, not the best value. Test both a cached and an uncached URL (add a random query string to bypass the cache) to see the difference the cache makes.

Browser devtools: in the Network tab, click the document request and open the Timing panel. "Waiting for server response" (Chrome) is the TTFB; the entries above it show DNS, connection and TLS. Use a private window so logged-in sessions do not skew the result.

Search Console: the Crawl Stats report shows average response time as seen by Googlebot, with a chart per file type when you click into the responses table. A rising line there is the only view of what Google itself experiences.

Server logs: nginx can log $request_time and $upstream_response_time per request, which separates proxy time from application time.

The redirect checker reports the timing of every hop for up to 10 URLs, which also shows how much a redirect chain adds before the final page even starts responding; chains are a hidden TTFB cost described in the entry on HTTP status codes.

How IndexRise monitors it

IndexRise records the response time of every monitored URL during the nightly check, from the same crawler and location each time, so the series is comparable day to day. By default a warning is raised when the response time triples compared with the median of recent checks; the factor can be changed per project. The project view shows response time and page weight charts over time, which is where a slow deploy, an expired cache or a hosting change becomes visible as a step in the line. Status codes are recorded alongside, so a slowdown that turns into 5xx errors shows up as one story rather than two.

You cannot make Googlebot crawl faster than your server answers. Measure TTFB from outside, watch the trend rather than a single number, and treat a sudden jump after a release as a regression to fix.