Slow server response time

DNS resolution, TCP connection and the TLS handshake — network time, largely determined by distance and by whether connections are reused.

Then the server's own work: routing the request, querying databases, rendering the response.

A high TTFB with a fast server means the network path is the problem — usually distance to a single origin. A high TTFB with a nearby server means the application is slow. Measuring from more than one location separates the two in about a minute.

Database queries. The classic shape is one query per item in a list — fast in development with twenty rows, ruinous in production with two thousand.

No caching. A page whose content changes daily but is rendered from scratch on every request is doing the same work thousands of times.

Distance. A single origin server serving a global audience pays the round trip every time. A CDN in front of static responses removes it for those responses.

Cold starts, on serverless platforms. The first request after idle pays the initialisation. It affects a small share of requests and can dominate the worst percentiles.

`curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer}\n' <url>` prints the breakdown. The gap between `tls` and `ttfb` is the server's own work; everything before is the network.

Measure several times. A single measurement mixes cold caches and transient load; the shape over ten requests is informative and one request is not.

Measure from where your users are. A 40 ms TTFB from your office and 600 ms from another continent is a distance problem, not an application problem.

Distinguish the page types. A home page is usually cached and fast; a search result or a logged-in account page often is not, and that is where the real cost sits.

Google's guidance for Core Web Vitals treats TTFB as a diagnostic metric rather than a threshold of its own, and suggests keeping it under roughly 0.8 seconds to give the visible metrics — Largest Contentful Paint in particular — room to land in the good range.

It is a floor, not a target in isolation: a 200 ms TTFB followed by three seconds of render-blocking scripts is still a slow page.

`performance.ttfb` and `performance.response_time` record the time to first byte for each page the crawler fetched, so the distribution across the site is visible rather than a single home-page measurement.

`performance.cdn_cache_status` and `performance.static_cache` read the cache headers the responses carry, which is what distinguishes a page served from cache from one rendered on every request.

`infrastructure.cdn` and `infrastructure.hosting` report what sits in front of the origin, which is the other half of the distance question.

The mistake that costs the most time is optimising before locating. Four measurements, in this order, locate it.

First, compare a static asset against a page. Request an image or a CSS file from the same host and compare its TTFB with the page's. If the asset is fast and the page is slow, the network path is fine and the application is doing the work. If both are slow, the problem is before the application.

Second, compare cached against uncached. Request the same page twice. A large gap means caching is working and the uncached cost is the real one; no gap means nothing is cached and every visitor pays full price.

Third, compare page types. A home page, a listing, a search result, a logged-in page. Slowness concentrated in listings and searches points at queries; slowness spread evenly points at framework or infrastructure overhead.

Fourth, compare locations. A large difference between two continents is distance, and no amount of database work will change it.

Only then open the application. By that point you know whether to look at queries, at cache configuration, at the edge, or at the platform — and three of those four are usually eliminated in ten minutes.

One caveat worth stating: the first request to an idle serverless deployment pays initialisation, so a single cold measurement can look catastrophic and mean nothing. Measure repeatedly before concluding.