A web request, end to end.

You type a URL and hit Enter. ~370 milliseconds later, pixels appear. Between those two events the browser does a DNS lookup, a TCP handshake, a TLS handshake, sends an HTTP request, waits for the server to think, downloads the HTML, parses it, fetches the CSS, computes layout, and paints. Watch each phase, see where the milliseconds actually go.

speed 1.5s

step 1 / 14 · 0 ms elapsed

request GET https://semicolony.dev/ · cold cache · TLS 1.3 · HTTP/2 single connection · cross-country RTT ~40 ms · no CDN cache hit

DNS

TCP

TLS

HTTP

SERVER

RENDER

t = 0 ms — user hits Enter

You type semicolony.dev and hit Enter. The browser needs to turn that name into an IP, open a connection, encrypt it, ask for the page, parse what comes back, fetch sub-resources, and paint pixels. Total time before you see anything: a few hundred milliseconds if everything goes well.

TTFB: Time To First Byte. From request sent to first byte of response received. Lower bound = network RTT + server processing time.

Where the milliseconds actually go

In a cold-cache cross-country request, network handshakes (DNS + TCP + TLS) eat the first ~110 ms and the server hasn\'t even seen your request yet. Then the request takes another RTT to reach the server, another RTT for the first byte to reach you. Pre-HTTP work easily costs 200 ms before the server\'s response can stream. Every connection paid that toll under HTTP/1.1; HTTP/2 lets a page reuse one connection for all its resources, which is most of why it\'s faster.

Server time is usually a small fraction of the total unless your app is slow. Optimising your endpoint from 200 ms to 50 ms helps; turning a 600 ms ocean RTT into 60 ms via a CDN edge node usually helps more.

What every step buys (and what you can skip)

DNS. Required, but a hot resolver cache turns 30 ms into 1 ms. DNS prefetch (<link rel="dns-prefetch">) does this proactively.
TCP handshake. Required for any new connection. HTTP/3 over QUIC fuses TLS + transport into one handshake, saving an RTT.
TLS handshake. Required for HTTPS. TLS 1.3 cut it to 1 RTT. 0-RTT resumption removes even that on repeat visits, with some replay-attack caveats.
Server processing. Pure latency on your code path. Edge caches (Cloudflare, Fastly) can short-circuit this to ~10 ms for static or near-static content.
Response download. Bandwidth × bytes. Compression, smaller HTML, and brotli over gzip all help here.
Render. Parsing speed + layout cost. Big DOM trees, expensive CSS, and synchronous JS all push this out.

How HTTP/3 changes this picture

HTTP/3 runs over QUIC, which combines the transport handshake with the TLS handshake. So the first ever request to a server takes 1 RTT instead of 2. On 0-RTT resumption it can be 0 RTTs — application data on the first packet. QUIC also fixes head-of-line blocking: in HTTP/2 over TCP, a single lost packet stalls all multiplexed streams; QUIC has separate streams at the transport layer, so other streams keep flowing.

What this visualisation simplifies

One round-trip on each handshake. Real packets fragment, retransmit, get reordered. We show the idealised happy path.
No CDN. Most production sites have a CDN edge somewhere geographically close. The handshake terminates there, not at the origin server. Cut ~100 ms off the RTT.
Single connection. We use HTTP/2 multiplexing. Pages also fetch from cross-origin domains (analytics, fonts, ads), and each new origin pays a fresh handshake unless it\'s been preconnected.
No browser internals. JS execution, font loading, layout shifts, image decoding all happen during/after render. We collapsed those into "render."
No retries. A 5xx, a TLS error, a DNS failure all add roundtrips. The happy path is the best case.

Go deeper

Networking Codex →

DNS resolution paths, TCP congestion control, TLS 1.3 internals, HTTP/2 multiplexing, HTTP/3 over QUIC, CDN architectures.

Open the Codex →

Found this useful?