The minute you start typing, your browser jumps into action. From scanning your history and bookmarks, offering autocomplete suggestions, to background DNS lookups.

Then you press Enter and the real work begins. Resolvers resolve, connections connect, servers stream, and renderers render. The whole dance often finishes in a few hundred milliseconds, yet the underlying symphony is complex enough to compose an entire opera.

Let’s slow it down and set the stage before the curtain rises.

To Search or not to Search that is the question

The journey starts in the address bar, Google Chrome calls it the omnibox, where the browser runs a quick heuristic check to decide, “search or navigate?”

If the text contains a space or begins with a question mark, the browser assumes you want a web search and hands the string to your default engine.
When the text begins with a scheme (https://), ends with a slash, looks like an IP address or host:port, or simply contains a dot followed by a TLD (.com, .io, .dev), it is treated as a URL.

Once that verdict is in, the address bar switches to lint mode. It lowercases the hostname, adds any missing protocol, probing HTTPS first and falling back to HTTP if the HTTPS handshake fails, and autocompletes from your history and bookmarks.
If the domain is on Google’s HSTS preload list, the fallback never occurs; the browser locks in HTTPS even on the very first visit.

After these clean‑ups, the browser sends a concrete request.

The Three Horsemen of Cache: Memory, Disk, and the Proxy

When you request a page, the browser consults three local layers before it even thinks about the network.

• Memory Cache:
  Each renderer process keeps its own in-memory cache of recently fetched responses. Tabs that share a renderer process (typically same-origin windows opened one after another) can reuse this cache. But a tab launched in a new renderer process won’t have access to it and falls back to the next caching layer.

• Proxy (Service Worker):
  If the memory lookup fails and your origin has a registered service worker, the browser fires a fetch event. That background script can serve files from Cache Storage, pull data from IndexedDB, stitch together an offline page, or defer to the network. Most apps pair a cache‑first policy for static bundles with a network‑first‑plus‑timeout policy for live data, allowing a full launch even in airplane mode.

• Disk Cache:
  After the service worker (if present) finishes, Chrome checks its disk cache, which usually answers in a few hundred microseconds. The cache respects server caching directives: objects tagged no-store are never written, while items saved with max-age=0 or no-cache are stored but immediately marked stale.
  Reusing a stale file requires an online “Is this still fresh?” round‑trip powered by three headers the server included with the original response:

  • Date gives the browser a baseline for age calculations.
  • Last‑Modified lets the browser ask, “Send this file only if it has changed since x.”
  • ETag provides a precise content fingerprint. The browser can ask, “Send the body only if this tag no longer matches.”

  If the server replies 304 Not Modified, the disk entry is renewed without downloading the body.
  With no connection, that revalidation fails and the dinosaur page appears.

Try it Yourself

Open DevTools, switch to the Network panel, keep “Disable cache ” unchecked, and reload.
The first reload shows network hits; the second reload in the same tab shows many “memory cache ” entries.
Open the same URL in a new tab and you’ll see “disk cache ", proving that memory cache is scoped to a renderer while disk cache spans them.

Note: Some resources still show “disk cache” on the second reload because Chrome keeps only small, recently used files in memory cache; large assets, hard‑reloaded items, or objects that were never memory‑eligible (like certain cross‑origin or streaming responses) fall back to the on‑disk cache instead.

The Curious Case of DNS Resolution

If every local cache draws a blank, the browser triggers a full DNS‑resolution sequence.
It starts with the OS stub resolver, which checks the hosts file, the OS cache, and the browser’s own mini‑cache.
A miss there becomes an encrypted DNS‑over‑HTTPS (DoH) query to a public recursive resolver such as  1.1.1.1 or  8.8.8.8.

The recursive resolver climbs the Internet’s “phone book” one rung at a time, revealing only the detail each rung needs (this is called QNAME minimization):

1. Root step – It asks a root server, “Where do .coms live?” and receives a list of .com TLD name‑server IPs.
2. TLD step – It asks a  .com server, “Who is authoritative for sahilten.com?” and gets back the domain’s set of name servers.
3. Authoritative step – It asks one of those servers for the A (IPv4) and AAAA (IPv6) records of sahilten.com and receives the live IP address plus a time‑to‑live (TTL), often 3600 seconds.

The resolver caches that answer for the TTL, returns it to the stub resolver, and the stub hands it to the browser.
Each hop is DNSSEC‑signed to prevent tampering, and NXDOMAIN (non-existent domain) replies are cached too, so they aren’t asked repeatedly.

Chrome hides this latency by launching DNS prefetch (resolves domain names early) while you type and by opening a speculative pre‑connect (opens TCP and TLS connection in advance) the moment the IP arrives.
Finally, the address feeds into the Happy Eyeballs algorithm, which races IPv6 and IPv4 connections in parallel and goes with whichever wins - delivering the quickest handshake even on patchy dual‑stack networks (both IPv4 and IPv6 protocols).

Wrap-up

This was just the warm-up act. Next, we’ll dive into the magic behind secure connections (TLS), server communication, and explore how browsers turn raw data into the visuals you see on your screen. Stay tuned!