What Happens When You Type a URL into the Browser

You type shop.example.com/products/42 into the browser and press Enter. Less than a second later, the product page appears.

In that second, the request passes through many separate systems: name servers, networks, a content delivery network, load balancers, app servers, caches, and databases. Then the browser turns the response into a page and asks for more files.

This lesson follows that path once, step by step, in the order it really happens. It connects the ideas from this chapter, and it shows where the time goes.

The Whole Path

Here are the main steps. The sections below explain each one.

1. The browser reads the URL.
2. DNS turns the host name into an IP address.
3. The browser opens a TCP connection.
4. For HTTPS, a TLS handshake secures the connection.
5. The browser sends the HTTP request.
6. A CDN edge server answers, or passes the request to the origin.
7. The origin servers build the response.
8. The browser renders the page and requests the files it needs.

Step 1: The Browser Reads the URL

First, the browser decides whether you typed an address or a search. shop.example.com/products/42 looks like an address. best running shoes looks like a search, so the browser sends it to a search engine instead.

For an address, the browser splits the URL into its parts. The scheme says which protocol to use. You did not type one, so the browser uses HTTPS. The host is shop.example.com, and the path is /products/42. The URL vs. URI vs. URN lesson explains these parts.

The browser also checks whether it has a fresh copy of this page in its own cache. If it does, it can show the page without using the network at all.

Step 2: DNS Turns the Name into an IP Address

Networks move data between IP addresses, not names. So the browser must find the IP address for shop.example.com. The system that does this is DNS (Domain Name System), which stores the IP addresses for domain names.

The browser looks for the answer in several places, from the nearest to the farthest.

1. The browser's own cache. It may have looked up this name recently.
2. The operating system's cache.
3. A DNS resolver. This is a server, usually run by your internet provider or a public service. If the resolver does not know the answer, it asks other DNS servers in order. First it asks the root servers, then the servers for .com, and then the servers for example.com.

Each answer comes with a TTL (time to live), which says how many seconds the answer may be cached. So most lookups end in a cache and take almost no time. A full lookup through the resolver can take tens to hundreds of milliseconds. The DNS resolution process lesson covers this in detail.

Step 3: The Browser Opens a TCP Connection

The browser now knows the IP address. Next it opens a TCP connection to port 443, the default port for HTTPS.

TCP starts with a three-way handshake. The client sends SYN, the server replies with SYN-ACK, and the client sends ACK. This costs one round trip, which is the time for a message to reach the server and come back. No request data moves until the handshake finishes.

Step 4: TLS Secures the Connection

Because the scheme is HTTPS, the browser and server now run a TLS handshake.

1. The server sends its certificate, which proves it owns shop.example.com.
2. The browser checks that a trusted certificate authority signed the certificate, and that it has not expired.
3. Both sides create the same secret key, which encrypts everything from now on.

With TLS 1.3, this takes one more round trip. With the older TLS 1.2, it takes two. The HTTP vs. HTTPS lesson explains the handshake.

Step 5: The Browser Sends the HTTP Request

Now the browser sends the request. In the text form of HTTP/1.1, it looks like this.

GET /products/42 HTTP/1.1
Host: shop.example.com
Accept: text/html
Cookie: session=abc123

The request names a method (GET) and a path. Its headers include the host and any cookies the browser stored for this site. HTTP itself is stateless, so the cookie tells the server who you are.

With HTTP/2 or HTTP/3, the same information travels in a binary format, but the meaning is the same. The HTTP versions lesson compares them.

Step 6: A CDN Edge Server Often Answers First

For a popular website, the IP address from step 2 usually belongs to a CDN (content delivery network), not to the company's own servers. A CDN is a group of servers in many cities. The request reaches an edge server near the user.

• Cache hit. If the edge server has a fresh copy of the response, it answers immediately. The request never reaches the company's servers.
• Cache miss. If it does not have a copy, it passes the request on to the origin, which is the company's own servers.

Static files, like images and scripts, are often cache hits. Personal pages, like your shopping cart, are usually passed to the origin. The What is CDN? lesson explains more.

Step 7: The Origin Builds the Response

On a cache miss, the request reaches the origin, where several parts work in order.

1. Load balancer. It picks one healthy app server from a group of identical servers.
2. API gateway. In many systems, the request passes through a gateway that checks authentication and rate limits, and routes it to the right service.
3. App server. The application code runs and builds the response.
4. Cache. The app first checks a fast cache, like Redis, for the product data.
5. Database. The app reads the database only if the cache does not have the data. It then saves a copy in the cache for the next request.

The response goes back along the same path. It carries a status code, like 200 OK, and headers, like Cache-Control, which says how long the response may be cached. Text responses are usually compressed, which makes them several times smaller for the trip back. If the response may be cached, the CDN keeps a copy on the way, so the next nearby user gets a cache hit.

Step 8: The Browser Renders the Page

The first response is only the HTML document. The browser now turns it into a page.

1. It reads the HTML and builds the page structure, called the DOM (Document Object Model).
2. It finds references to other files: stylesheets, scripts, fonts, and images.
3. It requests those files, often many at the same time.
4. It applies the styles, runs the scripts, calculates where everything goes on the screen, and draws the page.

A page often needs 50 to 100 files, so this second pass is usually larger than the first. Three ideas from this chapter keep it fast.

• Connection reuse. The browser keeps the connection open, so steps 3 and 4 do not repeat for each file on the same host.
• Multiplexing. HTTP/2 and HTTP/3 send many requests over one connection at the same time.
• Caching. The CDN serves most files from the edge. The browser also stores files, so a repeat visit may not download them again.

Files from other hosts, like a separate image domain, need their own DNS lookup and connection.

Where the Time Goes

Count the round trips before the first byte of the page arrives, on a new HTTPS connection with a cached DNS answer.

That is three or four round trips before the first byte arrives, not counting the server's own work.

Now compare two distances. Suppose the server is on another continent, and a round trip takes 150 ms. Three round trips add 450 ms. Now suppose a CDN edge server is in the same city, and a round trip takes 20 ms. The same three round trips add only 60 ms.