What Happens When You Type google.com?

Most answers to this question stop at 'DNS, then TCP, then HTTP'. The interesting engineering lives in the gaps between those words, and most of the interesting decisions happen long before anything touches a network cable. What follows is the full path from keystroke to painted pixel — including the parts almost every answer skips.

Before the network is touched at all

The browser's UI thread receives the keystrokes and asks the first question: is this a URL or a search query? For a bare domain like google.com the answer is unambiguous, so the browser begins a navigation. Before a single packet leaves the machine, several layers of local state are consulted.

First, the URL is parsed into scheme, host, path and implied port. Then the browser checks its HSTS preload list — a hardcoded set of domains that must be reached over HTTPS even on a first-ever visit, so google.com is upgraded to https before anything else happens. Then a service worker is consulted if one is registered for the origin; a service worker can answer the entire request from the Cache API without touching the network. And if the previous page contained a preconnect or dns-prefetch hint, the DNS lookup may already have happened before you even pressed Enter. A surprising fraction of navigations never leave the process.

Resolution is a chain of caches

If the request does need an address, the browser checks its own DNS cache first, then the operating system's resolver cache, then the configured recursive resolver — your ISP's, or a public one like 8.8.8.8 or 1.1.1.1. The odds are good that one of these already knows the answer, because DNS is designed as a series of layered caches and TTLs govern how long each layer may remember.

• Browser cache, then OS resolver cache, then the configured recursive resolver.
• Only on a cold miss does the recursive resolver walk root, TLD and authoritative nameservers.
• TTLs mean you may be handed an answer that stopped being true minutes ago.

On a cold cache the recursive resolver does the walking on your behalf: root servers refer it to the .com registry, which refers it to Google's authoritative nameservers. Modern resolvers minimise the name sent at each step, and encrypted transport — DNS over HTTPS on port 443, or DNS over TLS on 853 — keeps the query itself private from eavesdroppers on the wire. The whole chain, warm or cold, still ends with the same thing: an IP address and a TTL that says how long to trust it.

The connection

With an address in hand, the browser opens a connection. The classic path is a TCP three-way handshake followed by a TLS handshake, each costing a round trip. Modern browsers and servers collapse both with QUIC over UDP, where the transport and crypto handshake are fused into a single round trip — and a returning visitor with a cached session ticket can send application data in the very first packet. The security of that path rests on certificate validation: the browser checks the chain up to a root it trusts, verifies the hostname matches, and checks validity dates. Certificate Transparency logs make misissuance publicly detectable rather than silently accepted.

The request goes to the nearest edge, not to a building in California

Here is the part most walkthroughs get wrong: google.com does not route to a server in Mountain View. Google announces the same virtual IP address from hundreds of locations worldwide using BGP anycast, so the network delivers your packets to the topologically nearest Google front end — often a point of presence in your own city. Those edge servers terminate the connection and then forward to the real backend over Google's private backbone. For you, the visible effect is a handshake that completes in single-digit milliseconds instead of a cross-continent 200.

$ dig +trace google.com
$ curl -w '%{time_namelookup} %{time_connect} %{time_appconnect}\n' -o /dev/null -s https://google.com

Run both. The namelookup number shows you the cache, the connect number the handshake, and the appconnect number the TLS. Watching the numbers move — and moving yourself to different networks — is worth more than reading ten diagrams.

What actually gets sent, and the cache that answers it

The request itself is governed by HTTP/2 or HTTP/3 multiplexing, which lets many requests share a single connection to the same origin without the overhead of opening a new one each time. The response arrives with headers that decide caching: Cache-Control says how long the browser or an intermediary may keep it, and an ETag or Last-Modified lets the client ask for the same asset again and get a 304 Not Modified instead of re-downloading bytes it already has. For a site like Google, much of the initial response is designed to be cacheable or served from memory, so the measured time is dominated by the negotiation ahead of it rather than the transfer itself.

All of this runs over a network where the shared plumbing quietly works. Google's pages reach you through its anycast edge and, over the long haul of the connection, congestion control decides how much data is in flight at once — modern variants like BBR probe the path continuously rather than waiting for losses to signal a bottleneck. On a mobile connection that varies from a strong to a weak signal, the same principles that power adaptive video keep the page's own requests moving. The end result is that what sounds like a single request — 'load google.com' — is actually a carefully orchestrated handoff across perhaps a dozen different pieces of software, most of which are built specifically so that they do not have to run.

Security and the trust chain

Every connection your browser makes is protected by a chain of trust that runs far beyond the browser itself. The certificate that proves google.com is really Google was issued by a certificate authority, which in turn is signed by a root certificate embedded in your operating system's trust store. Your browser verifies the whole chain, checks the hostname against the certificate's Subject Alternative Name, confirms the dates are valid, and only then proceeds. Public Certificate Transparency logs mean that a certificate misissued for google.com is appended to a tamper-evident, publicly audited log within hours of issuance — a deterrent designed not to prevent misissuance, but to make it detectable before anyone trusts it.

This is the quiet fourth layer of the stack, and it deserves as much attention as DNS, TCP and TLS themselves. The internet runs on the assumption that when you connect to a hostname, you reach the party that legitimately controls it. BGP hijacks, DNS cache poisoning and CA compromises all attack that single assumption, which is why the industry has spent years bolting extra verification onto each layer — RPKI for routing, DNSSEC for names, certificate transparency and short-lived certificates for TLS. None of it is finished, and all of it is the price of the internet's original sin: trust was added after the fact instead of designed in from the start. When you type google.com and it works, you are depending on the entire decade-long project to keep that trust honest.

From bytes to pixels

The response arrives as HTML, CSS and JavaScript. The browser's parser builds the DOM while a preload scanner fetches stylesheets and scripts in the background so they are already in flight before the parser reaches them. CSS becomes the CSSOM, the two trees merge into a render tree, geometry is computed in layout, and finally the pixels are painted. A cached or gzip-friendly response can be rendered in tens of milliseconds; the negotiation that got you there — cache layers, name resolution, handshakes, anycast routing — is where the real engineering lives.

The lesson is that nearly every step in this chain was optimised to not happen. Caches exist so the DNS walk rarely happens. Connection pooling exists so the handshake rarely happens. Anycast exists so the bytes never travel far. A modern page load is mostly the careful orchestration of avoiding work that was once mandatory.