You hit enter. Now what?
You type a URL, hit enter, and a fraction of a second later there's a page on your screen. In that gap your machine talked to half a dozen systems spread across the planet, in a strict order, each one handing off to the next. Let's walk the whole chain.
DNS: a name becomes a number
Computers don't route to names, they route to IP addresses. So the first job is translation. Your browser checks its own cache, then the OS cache, then asks a resolver (usually your ISP's or something like 1.1.1.1). If nobody knows, the resolver walks the hierarchy: a root server points it at the .com servers, which point it at the domain's authoritative server, which finally answers with an IP.
One name, resolved by walking root to .com to authoritative.
TCP first, then TLS
Now your machine has an IP, but it still has to open a connection. TCP does a three-way handshake: SYN, SYN-ACK, ACK. Then, because the URL is https, TLS negotiates encryption: the server proves who it is with a certificate, both sides agree on keys, and a secure tunnel comes up. With TLS 1.3 that's down to a single round trip.
The request is just text
With the tunnel up, the actual request is almost boring. It's a few lines of plain text sent through the encrypted pipe:
That's the whole thing. The server reads it and starts sending HTML back.
Parse, then paint
The server streams HTML back. Your browser doesn't wait for all of it. It parses as bytes arrive, building the DOM from HTML and the CSSOM from CSS, then combines them into a render tree, works out where every box goes (layout), and finally paints pixels. Images, scripts and fonts it spotted along the way get fetched in parallel, often over the same connection.
It's fallbacks all the way down
Every leg of that race has a cache in front of it and a fallback behind it. That's why the same page can feel instant once and sluggish the next: a cold DNS cache, a fresh TLS handshake, a far-away server. Next time it's slow, you now know exactly which leg to go measure.