What Happens When You Press Enter?

You press Enter. Nothing visible happens yet.

Underneath, the browser runs a short decision sequence before it touches the network — checking four different places that might let it skip a round-trip to a remote server entirely. Most of the time, at least one check produces a hit. The full network journey we’ll trace across this series is the slow path — the path taken only when every cache misses.

This post maps the pre-network phase: what the browser checks, in what order, and what each hit means.

Anatomy of a URL

The first thing the browser does is parse the text in the address bar. Not just to display it neatly — the parsed result drives every decision that follows: which protocol to use, which host to connect to, which cached responses to look up, which Service Worker to consult.

The browser extracts three things it needs immediately: the scheme (determines security requirements and port), the host (www.google.com) for DNS resolution and cache lookup, and the origin (https://www.google.com) for Service Worker scope matching.

What if it’s not a valid URL?

If what you typed doesn’t look like a URL — no scheme, no recognisable TLD, spaces in it — the browser sends it to your configured search engine instead. Chrome’s omnibox tries hard to guess: google.com without https:// gets treated as a hostname, but how does the internet work goes to Google Search. The heuristics are fuzzy, and the browser occasionally gets it wrong in either direction.

Check 1 — HSTS: The Security Hardcode

Before opening any connection, the browser asks: is this domain required to use HTTPS?

HTTP Strict Transport Security (HSTS) is a mechanism that lets a server tell the browser: “for the next N seconds, only connect to me over HTTPS — never plain HTTP.” Once a browser has seen this header from a server, it will silently upgrade any future http:// request to https:// without sending the original HTTP request at all.

The header looks like this:

max-age=31536000 means 365 days. For the next year, the browser will never send an HTTP request to this domain, regardless of what URL the user types or a link provides.

The preload list — no first visit required

HSTS has a bootstrapping problem: the very first visit to a site is still vulnerable, because the browser hasn’t received the HSTS header yet. An attacker who intercepts that first HTTP request can downgrade the connection before the user ever reaches HTTPS.

The HSTS preload list solves this. It’s a hardcoded list of domains — baked into Chrome, Firefox, Safari, and Edge at compile time — for which HTTPS is enforced before any network request, even on first visit. Google, most banking sites, and over 100,000 other domains are on it.

You can check any domain’s status at hstspreload.org, or query Chrome’s own database directly:

Check 2 — Service Worker: The Programmable Gatekeeper

If a Service Worker is registered for this origin, it intercepts the fetch before the browser checks any network cache.

A Service Worker is a JavaScript file that runs in a background thread, separate from the main page. It registers itself for an origin (e.g., https://www.google.com) and receives a fetch event for every request that origin makes — navigations, API calls, image loads, everything.

// Inside the service worker
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) => {
      return cached ?? fetch(event.request);
    })
  );
});

This is a cache-first strategy: check the SW’s own cache (caches.match), and only go to the network if nothing matches. The SW has total control — it can serve stale content, synthesize responses, or route different URLs to different caches.

The browser checks whether a SW is registered for the current URL’s origin and, if so, routes the fetch through it. If the SW serves a response from its own cache, the network is never consulted.

We’ll cover Service Worker caching strategies in depth in Block 7. For now, the key point is: if an SW is active and has a cached response, the request never leaves the browser process.

Check 3 — Browser DNS Cache

If no SW intercepted the request, the browser needs an IP address for the hostname. Before going to the network for DNS, it checks its own DNS cache.

The browser maintains a small in-memory cache of recent DNS responses. Each entry has a TTL (time-to-live) — a duration set by the DNS server that tells resolvers how long to cache the answer. If the cached entry hasn’t expired, the browser uses it directly.

There are three cache layers the OS checks in order before going to the network:

Only if all three miss does a real DNS query leave the machine. We’ll trace that query in full in Block 2.

Check 4 — HTTP Cache

The HTTP cache stores full request/response pairs on disk. If the browser has previously fetched this exact URL and the cached response is still fresh, it can serve it without contacting the server at all.

Freshness is determined by the Cache-Control header. A response with Cache-Control: max-age=86400 is considered fresh for 24 hours. During that window, any request for the same URL can be served from cache with zero network activity.

HTTP/2 200 OK
cache-control: max-age=86400, public
content-type: text/javascript

If the cached response is stale (past its max-age), the browser doesn’t discard it immediately — it sends a conditional request to the server, asking “has this changed?” The server either confirms it’s unchanged (returns 304 Not Modified, saving bandwidth) or sends a fresh copy. We cover this fully in Block 7.

The Complete Decision Sequence

Here is how all four checks fit together as a temporal sequence. The browser works through them in order — each one a potential exit that avoids everything that follows.

The Decision Tree

The same logic as a decision flow — showing which check leads where, and what a “yes” at each point means for the request.

What Actually Reaches the Network

In practice, most requests hit at least one cache. A first visit to a new site will miss everything and go through the full sequence. A repeat visit to a well-cached site might never touch the network.

The pattern this creates is why performance work focuses so heavily on caching strategy — every cache hit is a round-trip avoided. The Service Worker gives you programmatic control over the most powerful cache layer. Cache-Control headers control the HTTP cache. The HSTS preload list eliminates the HTTP→HTTPS redirect round-trip on first visit.

When you’re debugging “why is my updated file not showing,” you’re fighting these four layers. The browser isn’t broken — it’s working exactly as designed.