What happens when you type a URL

You type an address, press Enter, and a second later a page appears. It feels like one action, but it is a chain of small, separate jobs, and each one can be fast or slow. So what happens when you type a URL? The browser works out where the site lives, opens a secure connection to it, asks for a file, and then turns that file into pixels. This chapter walks through each step in order. Once you can picture the chain, most of what comes later in this course, from HTML to speed, has an obvious place to sit.

01What happens when you type a URL, step by step

A URL (Uniform Resource Locator) is the full address of one thing on the web. Take https://example.com/about. It has three parts that matter here:

Computers on the internet do not find each other by name. They use IP addresses, numbers such as 93.184.216.34. So the browser's first job is to turn the name into a number. Then it can connect, ask, receive and draw.

Step through the journey below. Each stage is a different job, done by a different part of the system.

The rest of this chapter takes those six steps one at a time.

02DNS: turning a name into an address

DNS (the Domain Name System) is the internet's directory. When you ask for example.com, the browser checks whether it already knows the address from a recent visit. If not, it asks a resolver, usually run by your internet provider or a service you chose, and the resolver asks the name servers responsible for that domain until one of them answers with an IP address.

MDN's guide to how browsers work points out two details worth knowing. The answer is cached, so the lookup usually happens once per hostname for a page load. But every different hostname on a page needs its own lookup. A page that loads fonts from one domain, analytics from another and images from a third pays for three lookups before those files can even be requested. On a phone, each one has to travel through the mobile network, which adds delay.

03Connecting: TCP, TLS and why HTTPS costs a round trip

With an IP address, the browser can open a connection to the server. On most of the web this still starts with TCP (Transmission Control Protocol), which sets up a reliable line with a three way handshake: the browser says hello, the server answers, the browser confirms. Only then can data flow.

Because the address starts with https, there is a second handshake on top: TLS (Transport Layer Security). In it, the browser and server agree how to encrypt everything that follows, and the server proves who it is with a certificate. A browser trusts that certificate because it was signed by an authority the browser already trusts. That is what the padlock in the address bar means: the connection is private and you are talking to the real example.com, not something pretending to be it. It does not mean the site itself is honest.

Each handshake is a trip to the server and back, so distance matters. A server on the other side of the world adds a noticeable delay before a single byte of the page arrives. This is one reason sites use a CDN (content delivery network): copies of the files sit on servers close to the visitor.

The protocols keep improving. MDN's page on Transport Layer Security notes that TLS 1.3 is the current and most widely used version, and that 1.0 and 1.1 should no longer be used. MDN's history of the evolution of HTTP explains that HTTP/2 lets many requests share one connection at once, and that HTTP/3 swaps TCP for a newer transport called QUIC, designed to cut delay. You do not choose any of this in your HTML. Your host and the browser agree on the best version they both support.

04The request and the response

Now the browser can ask for the page. It sends an HTTP request, a short text message. Under HTTP/2 and HTTP/3 it travels in a compact binary form, but the meaning is the same as this:

GET /about HTTP/1.1
Host: example.com
Accept: text/html
Accept-Language: en-GB

GET is the method: it means "send me this". The headers below it add context, such as which languages the visitor prefers. MDN's overview of HTTP covers the other methods and headers.

The server answers with a response: a status code, its own headers, and the body.

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=600

<!doctype html>
<html lang="en">...

The status code is the server's one line summary. 200 means here it is. 301 means it has moved, look over there. 404 means there is nothing at this address. 500 means the server broke while trying. Cache-Control tells the browser how long it may keep this copy and reuse it without asking again, which is why a second visit is often faster than the first.

05From HTML to pixels: parsing and rendering

The response body is just text. The browser has to read it and decide what to draw, and it starts before the whole file has arrived. MDN notes that the first chunk of a response is usually about 14KB, and the browser begins parsing and rendering from whatever it has.

Parsing: building the DOM

As the HTML streams in, the browser parses it into the DOM (Document Object Model): a tree of objects, one for every element, in the order they appear. Headings, paragraphs and links become nodes in that tree. Scripts can read and change it later.

Along the way the parser finds references to other files: a stylesheet in the <head>, a script, images, fonts. Each one becomes a new request, often to the same server over the same connection. A helper called the preload scanner reads ahead of the main parser so these requests start early.

Some of those files hold things up. CSS is render blocking: the browser will not draw the page until it has the stylesheets, because drawing unstyled content and then restyling it would look broken. A plain <script> tag is parser blocking: the browser stops building the DOM, fetches the script and runs it, because the script might change the document. That is why scripts usually carry defer:

<head>
  <link rel="stylesheet" href="styles.css">
  <script src="script.js" defer></script>
</head>

With defer, the script downloads in parallel and runs only after the HTML has been parsed. We come back to what JavaScript should and should not do in progressive enhancement.

Rendering: style, layout, paint, composite

The stylesheets are parsed into the CSSOM (CSS Object Model), a second tree that holds every rule. MDN's guide to the critical rendering path describes how the two trees are combined into what the browser actually draws:

1. Style. For every visible element, the browser works out which CSS rules apply and what the final values are.
2. Layout. It calculates where each box sits and how big it is, based on the width of the window.
3. Paint. It fills in the pixels: text, colours, borders, images.
4. Composite. It stacks the painted layers in the right order and puts them on screen, sometimes with help from the graphics chip.

This is not a one time event. When a script changes the page, or the window is resized, or an image arrives and takes up space, some of these steps run again. Changing a colour only needs a repaint. Changing a width needs layout again, then paint, for everything it affects. That cost is why some animations are smooth and others stutter, which our post on website animation performance covers in detail.

06Why this chain matters for real sites

Every step above takes time, and visitors feel the total. A few habits follow directly from the chain:

• Fewer hostnames. Each new domain on a page means another DNS lookup and another handshake.
• Small, early HTML. The browser starts work on the first chunk it receives, so the important content should be near the top of the document, as real text.
• Lean CSS, deferred scripts. CSS holds up the first paint and plain scripts hold up parsing, so keep both small and load scripts with defer.
• Reserved space. Images and embeds with known dimensions stop the layout from jumping when they arrive.

Google measures how this feels to real visitors with the Core Web Vitals, which we explain for beginners in website speed. If you already run a site, our Core Web Vitals checklist is the practical version.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Northlight Studio</title>
  </head>
  <body>
    <h1>Northlight Studio</h1>
  </body>
</html>