The Full Sequence at a Glance
When you press Enter on a URL, your browser performs a precise sequence of operations before the first pixel appears on screen. Understanding this sequence explains why some sites are fast, why latency matters more than bandwidth for browsing, and how to diagnose exactly where a slow page is losing time.
- Parse the URL — extract the scheme, hostname, path, query string, and fragment.
- DNS lookup — translate the hostname into an IP address.
- TCP connection — establish a reliable connection to the server's IP.
- TLS handshake — negotiate encryption and verify the server's identity.
- HTTP request — ask the server for the resource at the given path.
- HTTP response — receive the server's content (typically HTML).
- Render — parse HTML, load subresources, build the page.
Step 1–2: Parsing and DNS
The browser first splits the URL into its parts. For https://example.com/page?q=1, the scheme is https, the hostname is example.com, the path is /page, and the query string is q=1. The scheme determines the default port: http implies port 80, https implies port 443.
With the hostname known, the browser checks several caches in order: its own internal DNS cache, the operating system's DNS cache, and then the system's configured DNS resolver. If none have a cached answer, the resolver performs a full recursive lookup — querying root nameservers, then TLD nameservers (e.g. .com), then the authoritative nameserver for the domain — and returns an IP address. A cold DNS lookup typically takes 20–120ms. A cached one takes under 1ms.
Step 3–4: TCP and TLS
With an IP address in hand, the browser opens a TCP connection using the three-way handshake: SYN → SYN-ACK → ACK. This costs one round trip — 20ms on a local server, 80ms to a server across the country, 180ms to one on another continent. This is why physical server location matters for latency even when bandwidth is abundant.
Because the URL uses https, a TLS handshake follows immediately. With TLS 1.3, this adds one more round trip and authentication of the server's certificate. The browser verifies the certificate was signed by a trusted Certificate Authority, checks that it hasn't expired, and confirms the hostname matches. After the handshake, all traffic between the browser and server is encrypted with a symmetric key derived during the handshake.
HTTP/3 over QUIC combines the transport and TLS handshakes into a single round trip (or zero for resumed connections), which is one of its key speed advantages over TCP+TLS.
Step 5–6: HTTP Request and Response
The browser sends an HTTP GET request for the resource. The request includes headers such as Host (the domain), Accept (content types it can handle), Accept-Encoding (compression algorithms), and Cookie (any stored session data). The server processes the request, generates or retrieves the content, and sends back a response with a status code (usually 200 OK), response headers, and the body — typically the HTML document.
The time from sending the request to receiving the first byte of the response is called Time to First Byte (TTFB). It includes the server's processing time plus the final round trip. TTFB above 600ms is a warning sign of either a slow server or a distant one.
Step 7: Rendering — HTML, CSS, and Subresources
Once the HTML arrives, the browser starts parsing it from top to bottom, building the Document Object Model (DOM). When it encounters a <link> tag for CSS, it fetches the stylesheet and blocks rendering until it has parsed it — because CSS affects how every element looks. When it encounters a <script> tag without async or defer, it also blocks to execute the JavaScript, since scripts can modify the DOM.
After building the DOM and CSSOM (CSS Object Model), the browser combines them into a render tree, calculates the layout of every element, and paints them to the screen. For a typical page, this initial render is fast — the bottleneck is usually the loading of subresources: images, additional scripts, web fonts.
Where Time Is Lost: Performance Bottlenecks
| Step | Typical Time | What Slows It |
|---|---|---|
| DNS lookup | 5–120ms (cold) | Slow resolver, high TTL, no cache |
| TCP handshake | 1 × RTT (20–200ms) | Distant server, high latency link |
| TLS handshake | 1 × RTT (TLS 1.3) | TLS 1.2 (2 RTTs), slow certificate chain |
| TTFB | 50–600ms | Slow server, no CDN, heavy backend |
| HTML download | 10–200ms | Large uncompressed HTML |
| Subresources | 100ms–3s | Many scripts, large images, no HTTP/2 |
The biggest win for most sites is moving static content to a CDN — it replaces the multi-hundred-millisecond round trip to the origin server with a 10–20ms hop to a nearby edge node, at every step of this sequence.
Frequently Asked Questions
How fast does a page load?
On a fast connection with a well-optimized site, the first byte arrives in under 100ms and the full page renders in under 1 second. DNS lookup takes 5–50ms on a warm cache, the TCP handshake one round trip (~20–80ms), TLS 1.3 one more round trip, and then the response. Slow DNS, distant servers, and heavy JavaScript are the most common culprits.
What is a DNS lookup in this context?
Your browser extracts the hostname from the URL and asks your DNS resolver to translate it into an IP address. The resolver checks its cache; if it misses, it queries root, TLD, and authoritative nameservers. The result is the IP address the browser connects to.
How many round trips does HTTPS require?
With TLS 1.3: two round trips before the first byte of content — one for TCP, one for TLS (combined with the first HTTP request). With TLS 1.2: three round trips. HTTP/3 over QUIC can reduce new connections to one round trip and resumed connections to zero.
What is a subresource?
After parsing the initial HTML, the browser discovers additional files: CSS, JavaScript, images, fonts. Each requires its own request. A typical page loads 50–100 subresources, which is why HTTP/2 multiplexing — all over one connection — matters for performance.
What is the critical rendering path?
The sequence the browser must complete before displaying anything: parse HTML → build DOM → load CSS → build CSSOM → combine into render tree → layout → paint. Render-blocking CSS and synchronous JavaScript extend this path and delay visible content.
How does HTTP/2 change this sequence?
HTTP/2 multiplexes all subresource requests over a single TCP connection, eliminating the need for many parallel connections. It also enables server push. Together these collapse the serial request waterfall into parallel streams, dramatically improving page loads on resource-heavy sites.