What happens when you enter a URL in your browser?

MITESH KUMAR ANSHU — Sat, 31 Oct 2026 04:01:56 +0000

You type dev.to, press Enter, and the page is there in about a second. It feels instant, so we never think about it. But a lot happens in that small gap, and it is worth knowing, because this one question quietly covers DNS, TCP, TLS, HTTP and how browsers paint pixels.

Let us go through it step by step. Everything below comes from a real test run against dev.to, and every command is included, so you can run the same checks on any site you like.

Step 1: The browser reads the URL

Before any network work, the browser parses what you typed.

A URL like https://dev.to/some-article has three parts: the scheme (https), the host (dev.to) and the path (/some-article). The scheme tells the browser which port to use by default. HTTPS means port 443, plain HTTP means port 80.

The browser also checks two local things first. Does it already have this page cached? And does this site insist on HTTPS? Browsers ship with a preload list of sites that must only load over HTTPS, and a site can also tell the browser the same thing with a response header called HSTS. Either way, even typing http:// can get quietly upgraded to https:// before anything leaves your machine.

Step 2: DNS, or turning a name into an address

Computers do not talk to names. They talk to IP addresses. So the browser needs to resolve dev.to into an IP, and that job belongs to DNS.

The lookup usually ends in a cache. Typically the browser checks its own DNS cache, then asks the operating system, which checks its cache and the hosts file, then the router, then a recursive resolver, usually run by your ISP or a public service like 1.1.1.1 or 8.8.8.8. Most lookups are answered somewhere along that chain and never go further. Browsers can also skip some of these layers, for example when they use DNS over HTTPS and ask a resolver directly.

If nobody has it cached, the resolver does the full walk itself: it asks a root server which servers handle .to, asks the .to servers which ones handle dev.to, then asks that authoritative server for the records.

Here is the real answer for dev.to:

$ dig dev.to A

;; ANSWER SECTION:
dev.to.   300  IN  A  151.101.66.217
dev.to.   300  IN  A  151.101.130.217
dev.to.   300  IN  A  151.101.2.217
dev.to.   300  IN  A  151.101.194.217

Four IP addresses, not one. The 300 is the TTL, the number of seconds this answer may be cached before anyone asks again. Those addresses belong to Fastly, a content delivery network, so the request will typically be routed to a Fastly edge location close to you rather than one far-away server. The infrastructure is already working in the site's favour before a single page byte has moved.

Step 3: TCP says hello

Now the browser opens a connection to one of those IPs on port 443. Classic TCP does this with a three-way handshake:

Your machine sends a SYN packet. "I want to talk."
The server replies with SYN-ACK. "Heard you, I am ready."
Your machine sends ACK. "Great, let us begin."

That is one full round trip before any real data moves. If the server is 50 milliseconds away, the handshake alone costs 50 milliseconds. This is why connection reuse matters so much on the web.

One note: HTTP/3 skips this. It runs over QUIC, which is built on UDP and folds the transport and encryption setup together. But the connection in our test was classic TCP, so let us stay on that path.

Step 4: TLS makes it private

HTTPS means the connection gets encrypted with TLS before any HTTP happens. The short version of the handshake:

Your browser sends a Client Hello: the TLS versions and cipher suites it supports.
The server replies with a Server Hello and its certificate. The browser checks that the name on the certificate matches the host it asked for, that the certificate is still valid, and that its signatures chain up to a certificate authority the browser already trusts. Only then does it treat the other end as the real dev.to and not someone pretending.
Both sides run a key exchange such as ECDHE and derive the same session keys. Once the handshake completes, the actual page data travels encrypted with those keys.

From the real test run, using curl -sv https://dev.to:

* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
*  subject: CN=dev.to
*  issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Atlas R46 DV TLS CA 2026 Q4

Those four lines cover most of the story. The encryption is TLS 1.2 with the ECDHE key exchange and the ChaCha20-Poly1305 cipher. The certificate says CN=dev.to, issued by GlobalSign. Modern sites usually negotiate TLS 1.3, which finishes in fewer round trips, but 1.2 is still common and correct.

One more detail hides in there: ALPN, server accepted to use h2. During the handshake, the browser and server also agreed to speak HTTP/2. They negotiated the protocol inside TLS, with no extra round trip.

Step 5: The actual HTTP request

Only now does the browser ask for the page. On HTTP/2 the request is not sent as plain text but as binary frames, though what it means is simple enough to write down:

:method: GET
:scheme: https
:authority: dev.to
:path: /

plus headers: what formats the browser accepts, cookies if you are logged in, and so on.

The server answers with a status, headers, and then the HTML. The real response from the test:

HTTP/2 200
content-type: text/html; charset=utf-8
server: Heroku
via: 1.1 heroku-router, 1.1 varnish, 1.1 varnish

200 means success. The interesting part is the last two lines. via: ... varnish says the response passed through Varnish caches, which is the software Fastly's CDN runs on, and server: Heroku points at where the application itself is hosted. Headers like these are written by the servers in the chain, so they are not proof of the exact route. But they do line up with what DNS suggested in step 2: a Fastly cache in front, an app on Heroku behind it.

Step 6: The browser renders the page

The HTML arrives, 279 KB of it in this test, and the browser starts rendering. It does not wait for the whole file. It parses as it downloads:

The HTML is parsed into the DOM, a tree of elements.
The CSS is parsed into the CSSOM, a tree of styles.
The two combine into the render tree, which is what actually gets shown.
Layout works out where every element sits on the screen.
Paint fills in the pixels, and compositing stacks the layers together.

Meanwhile the HTML points to more resources: stylesheets, scripts, fonts, images. Over HTTP/2 these share the one connection and load in parallel, which is why the ALPN negotiation in step 4 matters. The response even came with Link: ... rel=preload headers, the server telling the browser which CSS files to start fetching before the HTML parser reaches them.

One thing can still block all of this: JavaScript. By default, when the parser hits a script tag, it stops, downloads the script and runs it, because the script might change the page. That is why defer and async exist.

The whole thing, measured

Here is the real timing from the test, with the exact command:

$ curl -so /dev/null https://dev.to \
  -w 'dns: %{time_namelookup}s\n'\
'tcp: %{time_connect}s\n'\
'tls: %{time_appconnect}s\n'\
'first_byte: %{time_starttransfer}s\n'\
'total: %{time_total}s\n'

dns: 0.000590s
tcp: 0.002930s
tls: 0.025648s
first_byte: 0.031225s
total: 0.047441s

One thing trips people up here: these numbers are cumulative checkpoints, not separate stages. So read them as differences. DNS finished in under a millisecond in this run. The TCP handshake took about 2 ms on top of that. TLS added about 23 ms, because it needs its own round trips. The gap from the end of the handshake to the first response byte was about 6 ms, and that gap covers the request travelling out, the server doing its work and the answer starting back. The rest of the HTML took another 16 ms to download.

Also keep the scope straight: 47 ms is only the HTML document as curl saw it. A real page load also fetches stylesheets, scripts and images and paints the pixels, none of which curl measures here, though a browser overlaps much of that with the HTML download. And the next click on the same site is usually cheaper still, because the browser keeps the connection open and reuses whatever it has already cached.

Where this becomes useful

The next time a site feels slow, this sequence is your checklist. Is DNS dragging? The TLS handshake? Is the server slow to send the first byte, or is the page heavy after that? The timing tab in your browser's dev tools breaks a load into exactly these stages, and now you know what each stage is actually doing. That is usually enough to point at the right layer before you change any code.

It also explains half the performance advice you see around. Keep connections alive, cache aggressively, preload the CSS that matters, defer the JavaScript that does not. Each of those tricks maps to one step in this list.

Next time a page loads, you will have a decent idea of what those milliseconds were doing.

DEV Community: MITESH KUMAR ANSHU