What Actually Happens Between Typing a URL and Seeing a Page

It is the oldest interview question in web development, and most answers stop at "DNS lookup, then HTTP request, then the page shows up." That is like describing a flight as "the plane goes up, then it comes down." The interesting part is everything in between, and once you can picture it, a lot of front-end performance advice stops sounding like folklore and starts sounding obvious.

Here is the journey from pressing Enter to seeing pixels, in the order the browser actually does it, with the places where real sites usually lose time.

Before the network: parsing the address and checking caches

The browser first decides whether you typed a URL or a search query. If it looks like a URL, it normalises it, adds a scheme if you left one off, and checks whether the site is on the HSTS list, which forces HTTPS before any request is made.

Then it looks for shortcuts. A service worker registered for that origin can answer the request without touching the network at all. The HTTP cache might hold a fresh copy of the document. Some browsers will already have started a connection while you were typing, based on your history. Every one of these shortcuts exists because the network is the slowest part of the whole process.

DNS: turning a name into an address

If nothing is cached, the browser needs an IP address. It asks the operating system, which checks its own cache and then queries a resolver, usually run by your ISP or a public service. That resolver may need to ask the root servers, then the top-level domain servers, then the domain's own name servers.

On a cold lookup this can take 50 to 200 milliseconds, more on mobile. That is why third-party scripts from five different domains cost more than the bytes they download: each new domain is another lookup. The dns-prefetch and preconnect hints exist to start this work early for origins you know you will need.

Connection and TLS

With an address in hand, the browser opens a connection. Over HTTP/1.1 and HTTP/2 that is a TCP handshake followed by a TLS handshake. TLS 1.3 brought the TLS part down to a single round trip, and HTTP/3 runs over QUIC, which merges the transport and encryption handshakes so a new connection can be ready in one round trip.

Round trips are the unit that matters here. If the server is 150 milliseconds away, each round trip costs 150 milliseconds no matter how fast either computer is. This is the core reason a CDN helps: it moves the server physically closer, and every round trip gets cheaper.

The request and the first byte

The browser sends an HTTP request with headers for cookies, accepted formats, compression and so on. The server does its work, which might be reading a static file or running a database query, and starts sending back a response. The time until the first byte arrives is called TTFB.

A slow TTFB is almost always a server problem: no caching, slow queries, or a cold function waking up. No amount of front-end optimisation fixes it, which is why measuring TTFB separately is one of the first things I check. The Network panel in DevTools shows it clearly, and our guide to DevTools features most developers never open covers how to throttle the connection so you see what a real phone user sees.

Parsing HTML and discovering resources

The browser does not wait for the whole document. It parses HTML as it streams in and builds the DOM, the tree of elements. While it parses, a preload scanner races ahead looking for stylesheets, scripts, fonts and images to request early.

Two things block progress. A normal <script> tag stops parsing until the script is downloaded and run, because the script might change the document. Adding defer or type="module" lets parsing continue. Stylesheets do not block parsing, but they do block rendering: the browser will not paint until it knows how things should look, otherwise you would see a flash of unstyled content.

Style, layout, paint and composite

Once the DOM and the CSS object model are ready, the browser combines them. It works out which rules apply to each element, then calculates layout, meaning the exact size and position of every box. Then it paints, filling in pixels for text, colours, borders and images, usually onto several layers. Finally the compositor stacks those layers and sends them to the screen, often using the GPU.

This pipeline does not run just once. Every time your JavaScript changes something, part of it runs again. Changing a colour triggers a repaint. Changing a width triggers layout, which can ripple through the page. Changing transform or opacity can often skip straight to compositing, which is why animation guides keep telling you to animate those two properties. The same rule drives the smooth motion in browser games, as we explain in the web code behind smooth online game animations.

A common belief that does not hold up

You will often read that the number of HTTP requests is the main thing to cut, and that bundling everything into one huge file is always best. That was sound advice in the HTTP/1.1 era, when browsers opened only six connections per domain. With HTTP/2 and HTTP/3, many requests share one connection efficiently.

Today a single giant bundle is often worse. It cannot be cached in pieces, so a one-line change invalidates everything, and the browser has to download code for pages the user never visits. Sensible splitting, with critical code loaded first and the rest on demand, usually wins. Count bytes on the critical path, not requests.

What this means for your own pages

Walking the pipeline gives you a checklist that is grounded in how browsers actually behave:

• Reduce the number of distinct origins on the critical path, and preconnect to the ones you keep.
• Serve from a CDN so round trips are short, and use HTTP/2 or HTTP/3.
• Fix server TTFB before polishing the front end.
• Defer non-critical scripts so parsing never stalls.
• Keep critical CSS small so the first render is not held back.
• Animate with transforms and opacity to avoid repeating layout.

None of these are tricks. They are what falls out naturally once you can see what the browser is doing between the moment you press Enter and the moment you see a page. Read more pieces like this in our Browsers section.