What a Page-Load Test Actually Measures: DNS, TLS, TTFB and Beyond

“The site feels slow” is not a diagnosis. A page-load test decomposes the feeling into named phases with millisecond budgets, and each phase points at a different owner: DNS at your registrar, TLS at your web server, TTFB at your application, download at your assets. Reading the phases in order turns a complaint into a work item.

The phases, in order

1. DNS lookup: resolving the hostname. Typically under 50 ms from a well-connected vantage point. Slow or erratic DNS suggests missing caching at the resolver, an overloaded authoritative server, or — if only sometimes slow — a resolver with a poor route to your NS.
2. TCP connect: one round trip. High values here with low DNS usually mean geographic distance: the vantage point is far from your server.
3. TLS handshake: TLS 1.2 costs two additional round trips; TLS 1.3 costs one. A bloated handshake time often means an oversized certificate chain, no session resumption, or again, distance.
4. TTFB (time to first byte): server processing after the request arrives — application logic, database queries, cache misses. This is the phase that in-house tuning actually fixes.
5. Content download: the HTML and then every referenced asset. Dominated by total payload size, number of requests and whether caching headers exist.

A typical breakdown for a healthy page looks like this:

dns        22 ms
connect    35 ms
tls        48 ms
ttfb      180 ms
download  420 ms   (1.2 MB, 27 requests)

Why the vantage point matters

Your browser on the office LAN is the most flattering observer that exists: warm DNS cache, short route, fast link. External tests measure what real first-time visitors experience. Interpreting from an external vantage point:

• High connect and high TLS, but good TTFB → distance problem; a CDN moves both numbers down without touching your code.
• Good connect/TLS but TTFB above roughly 500 ms → application problem; enable caching, profile the slow query, check that no plugin pings a third-party API on every page view.
• Erratic results across runs → capacity problem or autoscaling cold starts; re-run several times and compare medians.

Common bottlenecks, most likely first

• Uncached dynamic pages driving every load through PHP and the database.
• Redirect chains: each extra 301 adds a full DNS+TCP+TLS+request cycle before content starts.
• Missing compression (gzip/brotli) tripling the download phase.
• Third-party scripts on the critical path — analytics, chat widgets, fonts.

Fix the phase with the worst budget share, re-test, repeat. Two measurement habits keep the numbers honest: clear caches or test a cold URL each run, since a warm page cache makes TTFB look artificially good; and run the test from more than one vantage point when the audience is international, because a result that is excellent from one continent can hide a 900 ms connect time from another. The website speed test on WhoDNS loads your page from an external vantage point and reports the per-phase timings and total payload, so the next “site is slow” ticket starts with a measured answer instead of a guess.