What Happens When You Type google.com and press Enter
You’ve done it ten thousand times. You’ve never watched what actually happens. Here it is — start to finish, in the 300 milliseconds before the page appears.
You press Enter.
That’s it. One key. And now something remarkable is in motion — something involving your laptop, your router, a chain of servers you’ve never heard of, undersea cables, and data centers on the other side of the world. All of it, before your coffee gets cold.
But let’s back up to the first problem. The one your browser hits immediately, before anything else can happen.
It doesn’t know where to go.
You typed google.com. Your browser received it. And then it hit a wall — because google.com is a name, a human convenience, and the internet doesn't move mail by names. It moves mail by numbers. Specifically, by an IP address — a string like 142.250.72.14 that pinpoints exactly one machine on the global network. Your browser has the name. It needs the number. And until it has the number, it cannot send your request anywhere. 📮
So the very first thing that happens when you press Enter is not a connection to Google. It’s a question.
Your browser checks its own memory first. If you visited Google in the last few minutes, the answer is already cached — sitting in a small local store, ready to use. Your browser grabs it and skips ahead. But if the cache is cold, you’re going through the full lookup.
The question goes out over UDP — think of it as a postcard, not a phone call. No handshake, no “are you there?” Just a question fired into the network toward your DNS resolver, a lookup service run either by your internet provider or something public like Google’s own 8.8.8.8. DNS — the Domain Name System — is the phone book of the internet. It's the thing that turns google.com into 142.250.72.14.
The resolver checks its cache. Nothing. So it climbs a chain of nameservers until it finds one with a definitive answer — the address 142.250.72.14, back at your browser in somewhere between 20 ms and 120 ms.
Tucked into that answer is a TTL — a number that says: remember this for 300 seconds. Your browser stores it. That’s why your second visit loads faster. The question was already answered. 🗂️
DNS Resolution — what happens on a cold cache
Now your browser has the address. Now it can knock.
It doesn’t just send your request. The internet has a rule: before any real data moves, both sides must agree to talk. Your browser sends a SYN — a synchronise packet, a polite I’d like to connect. Google’s server sends back a SYN-ACK — heard you, I’m ready. Your browser sends an ACK — great, let’s go.
Get Ankit Verma’s stories in your inbox
Join Medium for free to get updates from this writer.
Three packets. One round trip. About 20 milliseconds if Google’s edge server is anywhere near you. This is the TCP handshake — and it happens before a single byte of your actual request leaves your machine. 🤝
Then it knocks again. Because google.com is HTTPS — encrypted — there's a TLS handshake on top of the TCP one. Your browser and Google's server exchange certificates, verify identities, agree on encryption keys. Another round trip. Maybe two. Your browser is making sure it's actually talking to Google, and not some impostor sitting in the middle pretending to be Google. Add another 20–60 ms.
Only now — after the phone book, after two handshakes — does your actual request go out.
And it travels.
Your packet leaves your device, hits your home router, exits your ISP, and enters a web of interconnected networks you’ve never thought about. Each router it passes through reads the destination address — like reading the address on an envelope — and decides which direction sends it closer. This is BGP routing, the Border Gateway Protocol, the duct tape that holds the global internet together. Thousands of independent networks, each operated by different companies, stitched into one by a shared agreement about how to pass mail along. A traceroute from your laptop to Google would show you 10 to 20 of these hops. 🌍
Your request doesn’t travel as one chunk either. TCP has already broken it into numbered packets. Each packet may take a different physical path. One goes through Frankfurt. Another goes through London. They arrive at Google out of order and get reassembled. The internet is not a pipe. It’s a postal system where every letter gets cut into pieces and mailed separately.
⚠️ Sometimes this goes wrong. A BGP route flap — a brief moment where routers disagree about the best path and start updating their tables simultaneously — can cause your packets to loop, slow down, or get dropped entirely. You see it as a favicon that spins for a few seconds, then resolves. It happens rarely. It’s not a bug. It’s what happens when your request has to cross a dozen independent networks operated by companies that don’t always agree.
Your request arrives at Google. Except — not really at Google. Not at one place.
Here’s something that surprises most people: 142.250.72.14 is not a single machine. It's the same IP address advertised simultaneously from hundreds of locations around the world. When your request heads toward that address, the internet routes it to whichever location is physically closest to you. If you're in Mumbai, you hit a server in Mumbai. If you're in London, you hit London. This is called anycast — one address, many destinations, the nearest one wins. 🗺️
That nearest location is Google’s edge. It accepts your connection, then passes your request deeper into Google’s infrastructure. A load balancer — software that watches thousands of servers and knows which ones are healthy and how busy each one is — assigns your request to a specific machine. You don’t choose. You don’t see the choice. You’re just assigned, in milliseconds, to a server somewhere in a data centre in Virginia or Oregon or wherever makes sense given your edge location and current traffic patterns.
That server processes your request. For a simple Google homepage, the work is almost nothing. The page is mostly static — prebuilt, pre-cached, waiting. By the time you asked, the answer was already sitting there. 🏢
The response arrives at your browser. And here’s the thing — it’s not a web page. It’s a recipe. 📋
Status code 200 — HTTP's way of saying found it, here you go. What arrives is HTML, CSS, and JavaScript: structure, style, behaviour. Raw instructions. Your browser follows them, fires a few more requests for images and scripts — all cached, all fast — and paints the screen. 🎨
The page appears.
You didn’t think about the DNS query, or the TCP handshake, or the BGP hops, or the load balancer that silently assigned you to a server, or the render engine that assembled 300 milliseconds of global infrastructure into a clean white box with a cursor in it.
You just typed. You pressed Enter.
Now you can’t not think about it. 🙂
