Website Speed Test

Times a single request to your page and breaks it into the four phases that make up time to first byte — DNS, TCP connect, TLS handshake and server think time — then reports what the response headers say about compression, caching and protocol.

This measures the server, not the browser. It runs no JavaScript and renders nothing, so it will not tell you your Largest Contentful Paint. What it will tell you is whether the server is the reason the page is slow, which is the question this answers better than a rendering test does.

How it works

Before a browser can draw a single pixel it has to complete four steps in order, and each one has a different fix.

DNS is the lookup of your hostname. A cold lookup of 20–120 ms is normal; consistently more than that suggests slow nameservers or a very low TTL forcing constant re-lookups. Connect is the TCP handshake, which is essentially one network round trip and therefore a measure of distance — this is what a CDN actually fixes. TLS is the certificate exchange, usually one or two more round trips; if it is disproportionate, look at a certificate chain that is longer than it needs to be, or a missing OCSP staple.

Then comes TTFB, and specifically the gap between the TLS handshake finishing and the first byte arriving. That gap is your application: PHP executing, database queries running, templates rendering. Everything before it is network; this part is code. Under 200 ms is good, 200–600 ms is unremarkable, and beyond about 800 ms the usual culprits are an uncached WordPress install, a query without an index, or a slow third-party API call on the critical path. Caching moves this number more than anything else available to you.

The download phase is the rest of the transfer, and it is where compression shows up. Text — HTML, CSS, JavaScript, JSON, SVG — should be served gzipped or, better, with Brotli; the ratio is typically 70–80%. An uncompressed HTML document is the single easiest win on this page, and it is a one-line server change. Images and video must not be compressed again, because they already are, and doing so wastes CPU for nothing.

Two other things visible in a single request matter more than their size suggests. Every redirect is a complete extra round trip — sometimes a whole extra DNS, connect and TLS sequence — before the real request even begins, so a chain of two or three is real, measurable delay for every first-time visitor. And cache headers decide whether a returning visitor repeats any of this at all: without Cache-Control, every asset is fetched again on the next visit even though nothing changed.

Two caveats about the numbers below. The first: this is a single sample from one location, so it includes whatever that moment held — a cold cache, a noisy neighbour, a queue. Run it two or three times and compare the spread rather than trusting one figure.

The second matters more, and most speed tools get it wrong. If your site sits behind a CDN, the wait between the TLS handshake and the first byte is not your application's thinking time. It also contains the CDN edge reaching your origin — and on a cold edge connection that is an entire extra DNS, TCP and TLS sequence, which can be most of a second on its own. A tool that labels that gap "server processing" will tell you your code is slow when your code rendered in twenty milliseconds. This page detects the common CDNs and says so rather than guessing; if a proxy is present, treat the wait as an upper bound on application time, not a measurement of it.

Frequently asked questions