What Happens When You Type a URL and Press Enter? A Web Page's 300-Millisecond Journey

You do it hundreds of times a day: type a site name into the address bar and press Enter. In the blink of an eye, the page is there. But in that blink, your computer talks to several servers around the world, sets up an encrypted connection, downloads files and calculates millions of pixels.

This journey is the most classic software interview question. But it's instructive for more than developers; for any business owner whose site loads slowly, it shows where the slowness hides.

In short:

• DNS: the browser turns the domain name into an IP address.
• TCP and TLS: a connection to the server is set up and encryption is negotiated.
• HTTP: the page is requested and the server responds with HTML.
• Rendering: the browser processes HTML, CSS and JavaScript and draws pixels on screen.
• Round trips add up at every step. A fast site is one that cuts those round trips.

Step 0: the browser figures out what you typed

When you press Enter, the browser first asks: is this a web address or a search term? "engerektech.com" looks like a domain; "weather" is a search. If it decides it's an address, it adds https:// in front.

The browser also checks whether you've been to the site before. If the site has said "only talk to me over HTTPS" with a rule called HSTS, the browser goes straight to an encrypted connection without trying insecure HTTP.

Step 1: DNS, the internet's phone book

Computers find each other by IP address, not by name. The system that turns a domain like "engerektech.com" into an IP address is DNS (Domain Name System).

The browser checks its own memory first, then the operating system's. If the address was used recently, the answer is ready and this step takes almost no time. Otherwise the question goes to a resolver, usually your internet provider's or a DNS service you chose. If the resolver doesn't know either, it starts a chain of queries:

1. Root servers: "Who knows about .com addresses?" There are 13 root server identities, but through a technique called anycast they have hundreds of copies spread around the world.
2. TLD servers: the servers responsible for ".com" say "here's the authoritative server for engerektech.com".
3. Authoritative server: the server holding the domain's records finally gives the IP address.

Each answer is cached for a time set by the record (its TTL), so the same question isn't asked thousands of times.

To see this on your own machine, type:

nslookup engerektech.com

Step 2: TCP, setting up the connection

The IP address is known. Now the browser needs a reliable connection to the server. The classic way is TCP, which starts with a three-step handshake:

• Browser: "Can we talk?" (SYN)
• Server: "Yes, can you hear me too?" (SYN-ACK)
• Browser: "I hear you, let's start." (ACK)

This handshake takes one full round trip. And round-trip time is bound by physics: light travels about a third slower in fiber than in a vacuum, at roughly 200,000 km per second. Between a user in Istanbul and a server in the US, that physical limit alone adds tens of milliseconds to every round trip, and in practice often more than 100. That's why it matters for the server to be close to the user.

Step 3: TLS, the encrypted tunnel

Behind the padlock in the address bar is TLS. Once connected, the browser and server agree on:

• Authentication: the server presents its certificate, signed by a trusted certificate authority. That's how the browser knows it's really talking to the right site.
• Key exchange: the two sides derive a shared encryption key that nobody in between knows.

The current version, TLS 1.3, cut this negotiation to a single round trip; TLS 1.2 needed two. When reconnecting to a site you've visited before, under certain conditions data can even go out with the very first message (0-RTT).

Step 4: HTTP, requesting the page

The encrypted tunnel is ready. The browser now sends its actual request:

GET / HTTP/2
Host: engerektech.com
Accept: text/html
Accept-Language: en-US

The server receives it, queries the database if needed, prepares the page and responds with a status code: 200 (OK), 301 (moved permanently), 404 (not found) or 500 (server error). The time until the first byte of the response arrives is called TTFB (Time to First Byte), one of the key indicators of server performance.

HTTP/3 and QUIC: shortening the handshake

The web's newest protocol, HTTP/3, uses QUIC, built on UDP instead of TCP. QUIC's biggest win is combining connection setup and the TLS negotiation into one step. The preparation that takes two round trips with TCP + TLS 1.3 takes one with QUIC. And a single lost packet doesn't hold up the download of other files, which makes a visible difference on mobile networks where packet loss is common.

To see how long your own site spends at each stage, use curl:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
First byte: %{time_starttransfer}s
Total: %{time_total}s
" https://engerektech.com

The times are cumulative; each line shows the time from the start of the request to the end of that stage.

Step 5: the browser renders the page

The HTML has arrived, but the job isn't done. The browser now turns raw text into a page on screen:

1. HTML parsing: the HTML is read and the page's tree structure (the DOM) is built. CSS, JavaScript, images and fonts found along the way trigger new requests.
2. CSS processing: style rules are read and the look of each element is computed.
3. JavaScript: scripts are downloaded and run. A script at the top of the page without defer or async can stop HTML parsing, one of the most common causes of slow sites.
4. Layout: the exact position and size of every element on screen is calculated.
5. Paint and composite: elements are turned into pixels, layers are combined and the page appears.

A typical page requests dozens of extra files after the first HTML. Each is a new request, sometimes a new connection. HTTP/2 and HTTP/3 send these requests in parallel over the same connection, cutting the time significantly.

Where does slowness hide?

Knowing this journey makes it easier to see why a site is slow:

A CDN (content delivery network) spreads copies of your site across servers in different cities. Users are served from the nearest one, and handshake round trips get shorter.

Frequently asked questions

How long does the whole process take?

On a well-configured site close to the user, DNS, connection and first byte together can stay under a few hundred milliseconds. If the server is far away, there's no caching and the page carries heavy JavaScript, the same process can stretch to several seconds.

Does HTTPS slow a site down?

The encryption negotiation used to add noticeable time. With TLS 1.3 and HTTP/3 that cost has dropped a lot. And in practice, browsers need HTTPS to use the speed gains of HTTP/2 and HTTP/3. So today HTTPS usually makes a site faster.

Will changing my DNS speed up my internet?

It only affects the DNS resolution step. If your provider's resolver is slow you may notice a difference, but since answers are cached, the effect on overall browsing speed is usually limited.

How do I find which stage makes my site slow?

The "Network" tab in your browser's developer tools (F12) shows DNS, connection, TLS and waiting times for each request separately. The curl command above also gives a quick measurement.

Loading a web page is one of the internet's most complex yet elegant engineering chains. If you want fast websites and apps that never keep users waiting, reach us through our web application development page.

Sources