Why your website is slow: a diagnosis in four stages

"The site is slow" is a symptom with at least four independent causes, and the usual response — buying a bigger server — fixes only one of them. Before you spend anything, measure where the time actually goes. Every HTTP request has four stages before a single byte of content arrives, and each has its own fix.

Stage 1: DNS lookup

Turning example.com into an IP address. Should be tens of milliseconds. If it is consistently over 100 ms, your nameservers are slow or distant — moving to an anycast DNS provider (most are free) is a one-hour job with a permanent payoff. Check what your records look like from outside with a DNS lookup.

Stage 2: TCP connect

One network round trip to open the connection. This is essentially your distance to the server and you cannot beat physics — you can only shorten the distance, which is what a CDN does. If connect time is much higher than a plain ping to the same host, something in front of the server is rate-limiting new connections.

Stage 3: TLS handshake

Negotiating encryption: one round trip on TLS 1.3, two on TLS 1.2. If this stage is disproportionately large, look for an old TLS version, an unnecessarily long certificate chain, or OCSP stapling that is not enabled — each adds avoidable delay to every new visitor. The SSL checker shows the negotiated protocol and the chain length.

Stage 4: server processing

Everything else: your application running queries, rendering templates, calling APIs. Subtract the first three stages from time to first byte and what remains is yours. This is usually the largest number and almost always the one worth attacking first. Typical causes, in the order you should look:

• One slow query. Nine times in ten there is a single unindexed query dominating the page. Turn on the slow query log for an hour and read it.
• No page caching. A page that could be cached for sixty seconds but is rebuilt for every visitor wastes the entire stack.
• Blocking external calls. An API call to a third party inside the request means their bad day becomes your outage. Move it to a background job and cache the last good answer.
• Shared hosting contention. If TTFB swings wildly at the same times each day, you are sharing a machine with a noisy neighbour.

What good looks like

Under 200 ms to first byte is excellent and normal for cached or static pages. 200–500 ms is good for a dynamic site doing real work. Past a second, visitors notice the blank screen before anything appears, and both conversion and crawl efficiency suffer. Measure it with the response time test, twice — the first run pays for cold caches.

The stages you cannot see from outside

Server response is the floor, not the whole story. Once the HTML arrives, the browser still has to fetch stylesheets, fonts, scripts and images, and a heavy front end can turn a 100 ms response into a four-second page. Two rules cover most of it: do not let anything block rendering that does not have to, and do not ship 2 MB of JavaScript to display 500 words of text. But a fast front end cannot rescue a slow server, which is why the four stages above come first.

Redirects: the invisible tax

Every redirect repeats stages one to three. A chain of three — HTTP to HTTPS to www to the final path — can add half a second before the real request even starts, on every visit. Run a redirect check and collapse the chain to a single hop.