End-to-End Walkthrough: What Happens When You Type a URL

Goal of This Walkthrough

This chapter stitches together the pieces you already know into one continuous, end-to-end narrative: what your device, browser, network, and servers actually do after you type a URL and press Enter. Instead of re-explaining individual topics (like DNS, TCP, HTTP, TLS, reverse proxies, or load balancing), we will focus on the “glue”: the ordering, the decision points, the common detours, and the practical signals you can observe when something goes wrong.

We’ll follow a realistic scenario: you type a URL for a modern website that uses HTTPS, redirects, a CDN, a reverse proxy, and a backend application that talks to a database and other services. Along the way, we’ll highlight what is happening on your machine, what is happening on the network, and what is happening in the server stack.

Step 0: The Browser Interprets Your Input

When you type something into the address bar and hit Enter, the browser first decides what you meant. This is more than it sounds, because users type many different things: a full URL, a hostname without a scheme, a keyword, or even a local file path.

• Is it a URL or a search query? Browsers apply heuristics. If it looks like a hostname (contains dots, no spaces) it may be treated as a URL; otherwise it becomes a search query sent to your configured search engine.

• Is the scheme missing? If you type example.com, most browsers will assume https:// first. If that fails, they may fall back to http:// depending on settings and HSTS rules.

  Continue in our app.

  You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

  Or continue reading below...

  

  Download the app

• Is there a cached decision? The browser may remember that a site is “HTTPS-only” (HSTS) or that it previously redirected from HTTP to HTTPS.

Practical implication: if you see the browser instantly rewriting what you typed (for example, forcing HTTPS), that is a local decision before any network request is made.

Step 1: Preflight Checks and Local Shortcuts

Before any network traffic, the browser checks whether it can satisfy the navigation from local state.

• Service Worker interception: If the site previously installed a Service Worker, the navigation request may be intercepted. Depending on its code, it might serve a cached HTML shell, perform a network fetch, or do a hybrid strategy.

• HTTP cache: Even for navigations, the browser may use cached responses if they are still fresh. If not fresh, it may perform a conditional request later (using validators) to avoid downloading the full content.

• Preconnect / prerender / prefetch hints: Modern pages can instruct the browser to warm up connections or DNS resolution for likely next navigations. If you clicked a link from another page, some of this work may already be done.

Practical implication: two visits to the same URL can behave very differently. The first visit often pays “cold start” costs; later visits may reuse caches, warmed connections, and stored permissions.

Step 2: Network Path Selection (Proxy, VPN, Captive Portal)

Next, the browser and operating system decide how to reach the destination network-wise.

• System proxy / PAC file: In corporate environments, traffic may be routed through an explicit proxy. A PAC file can choose a proxy based on the URL.

• VPN: A VPN can change routing so that “local” requests go through a tunnel to another network.

• Captive portals: On hotel or airport Wi‑Fi, the network may intercept requests until you sign in. This can cause unexpected redirects or certificate warnings.

Practical implication: if a site works on mobile data but not on Wi‑Fi, suspect a proxy, VPN, DNS filtering, or captive portal behavior.

Step 3: Getting to the Right Edge (CDN vs Origin)

Many modern sites do not send you directly to the “origin” server that runs the application. Instead, you are routed to an edge network (often a CDN) that can serve cached content, terminate TLS, and forward only necessary requests to the origin.

From your perspective, you still typed one URL. Behind the scenes, the hostname may resolve to an edge location near you, and that edge may forward to a regional or central origin. The key idea for this walkthrough is the multi-hop request path:

• Client → Edge (closest point of presence)

• Edge → Origin reverse proxy (your infrastructure entry point)

• Reverse proxy → App (application server)

• App → Dependencies (database, cache, internal APIs)

Practical implication: “the server” is rarely one machine. Latency and failures can come from any hop, and logs are often split across systems.

Step 4: First Response Is Often Not the Final Destination (Redirect Chains)

Even after the browser reaches a server, the first response may instruct it to go somewhere else. Redirects are common and can be intentional and helpful, but they also add round trips.

Common redirect reasons

• Canonical host: redirect example.com → www.example.com (or the reverse) to consolidate cookies and SEO signals.

• Canonical scheme: redirect HTTP → HTTPS.

• Trailing slash normalization: redirect /docs → /docs/.

• Geo or language routing: redirect to /en/ or a regional domain.

• Auth flows: redirect to an identity provider and back (OAuth/OpenID Connect).

Practical step-by-step: what the browser does with a redirect response

• Receives a response with a redirect status and a Location header.

• Decides whether to follow automatically (usually yes for navigations).

• Creates a new request to the new URL.

• Repeats until it receives a non-redirect response or hits a redirect limit.

Practical implication: if a page feels slow “before anything loads,” check for multiple redirects. Each redirect can add latency and can trigger extra DNS lookups and connection setups depending on host changes.

Step 5: The HTML Arrives, and the Browser Starts Parsing Immediately

Once the browser receives the final HTML response, it does not wait for the entire document to download before acting. It streams: as bytes arrive, it parses and begins building internal structures.

What gets built while parsing

• DOM (Document Object Model): the tree representation of HTML elements.

• Preload scanner: a subsystem that looks ahead for resources (CSS, JS, images, fonts) to start fetching them early.

• Request queue: the browser schedules resource downloads with priorities (CSS is usually high priority because it blocks rendering).

Practical implication: the order of tags in HTML matters. CSS in the head tends to be fetched early; scripts can block parsing depending on attributes; large render-blocking resources can delay first paint.

Step 6: Subresource Fetches (CSS, JS, Images, Fonts, API Calls)

Modern pages are rarely a single request. The HTML references many subresources, and JavaScript often triggers additional requests after initial load.

How the browser decides what to fetch

• HTML-driven fetches: <link rel="stylesheet">, <script src>, <img>, <link rel="preload">, <video>, etc.

• CSS-driven fetches: background images, fonts via @font-face.

• JS-driven fetches: fetch(), XHR, GraphQL calls, analytics beacons, feature flag checks.

Each of these fetches may go to the same origin or to multiple different origins (CDN for static assets, API domain for data, third-party domains for analytics). That means the browser may repeat parts of the “reach the server” process for each distinct host, subject to caching and connection reuse.

Practical step-by-step: what happens for each subresource

• Browser checks its cache for a usable response.

• If not usable, it schedules a network request with a priority.

• It may attach cookies and other credentials depending on request mode and origin rules.

• It receives the response, stores it in cache if allowed, and hands it to the appropriate subsystem (CSS parser, JS engine, image decoder, font loader).

Practical implication: a page can “look loaded” but still be busy fetching low-priority resources. Conversely, a single slow CSS file can block rendering even if many images are already downloaded.

Step 7: Server-Side Routing and Middleware (What Happens After the Request Hits Your Stack)

On the server side, once the request reaches your infrastructure entry point (often a reverse proxy), it typically passes through layers that apply rules before the application code runs.

Common layers and decisions

• Edge/CDN rules: cache lookup, bot filtering, rate limiting, WAF checks, header normalization.

• Reverse proxy routing: path-based routing (/api to API service, /static to object storage), header-based routing, canary releases.

• Authentication middleware: session validation, token checks, redirect to login if needed.

• Compression and content negotiation: choosing encodings and variants (for example, compressed responses) based on request headers.

• Application routing: mapping the URL path to a controller/handler, applying business logic, and selecting a response type.

Practical implication: two requests to the same path can take different routes depending on headers, cookies, geolocation, or feature flags. When debugging, capture the full request context (headers, cookies, and the exact URL) rather than only the path.

Step 8: Dynamic Page Generation vs Static Delivery

When the request reaches the application, the response might be produced in several ways. The important part for an end-to-end walkthrough is understanding that “HTML response” can come from different pipelines.

• Static file: served directly from edge storage or a static server with minimal processing.

• Server-side rendered HTML: the app renders HTML on the server using templates or a rendering engine, often including user-specific data.

• Hybrid: server returns an HTML shell plus embedded state; the browser then fetches more data and hydrates the UI.

• Single-page app entry: server returns a mostly empty HTML page that loads JavaScript which then fetches data and renders everything client-side.

Practical implication: “time to first byte” can be dominated by server rendering and backend calls, while “time to interactive” can be dominated by JavaScript parsing/execution and client-side data fetching.

Step 9: Backend Dependencies (DB, Cache, Internal APIs)

For dynamic requests, the application often needs data. That means it becomes a client to other services.

Typical dependency calls

• Database query: fetch user profile, product list, content.

• Cache lookup: retrieve precomputed fragments or session data.

• Internal service calls: pricing service, recommendation engine, inventory service.

• External APIs: payment provider, maps, email service.

Practical step-by-step: how one slow dependency becomes a slow page

• Request enters app handler.

• Handler calls dependency A (fast) and dependency B (slow).

• App waits (or retries) before it can render the response.

• Client sees a long wait before the first meaningful content appears.

Practical implication: performance is end-to-end. Even if your edge and reverse proxy are fast, a single slow query can dominate the user experience. This is why tracing across services is so valuable.

Step 10: Response Assembly (Headers, Cookies, Caching, Compression)

When the server is ready to respond, it assembles headers and the body. This is where many “invisible” behaviors are defined.

Important response behaviors you can observe

• Set-Cookie: establishes or updates session identifiers, preferences, or security tokens. Cookies influence subsequent requests, including subresource and API calls.

• Caching directives: determine whether the browser and intermediaries can store the response and for how long. This strongly affects repeat visits and back/forward navigations.

• Content type: tells the browser how to interpret the body (HTML, JSON, image, font).

• Compression: reduces transfer size; the browser decompresses automatically.

• Varying by headers: instructs caches that different header values produce different variants (for example, language or encoding). Misuse can cause cache fragmentation or incorrect content delivery.

Practical implication: many “why did I get the wrong content?” bugs are caching-variant bugs. If a response varies by cookie or header but caching is configured incorrectly, users can receive content meant for someone else or for a different device/language.

Step 11: Rendering Pipeline: From Bytes to Pixels

After HTML, CSS, and JS arrive, the browser’s rendering engine turns them into pixels. The key is that rendering is incremental and can be blocked by certain resources.

High-level stages the browser cycles through

• Style calculation: CSS rules are applied to DOM elements to compute final styles.

• Layout: the browser computes sizes and positions (the “box model” in action).

• Paint: drawing of text, colors, borders, images into layers.

• Compositing: layers are combined and displayed, often using the GPU.

JavaScript can trigger repeated cycles by changing the DOM or styles. Some patterns cause expensive recalculations (for example, repeatedly reading layout-dependent properties and then writing styles in a loop).

Practical implication: a page can have fast network responses but still feel slow due to heavy JavaScript or complex layout/paint work. Performance debugging often requires looking at both network and CPU timelines.

Step 12: Additional Navigations Without Full Reloads

Many sites behave like applications: clicking a link may not trigger a full page reload. Instead, JavaScript intercepts the navigation, fetches data, updates the URL, and swaps content.

What changes in an “app-like” navigation

• Fewer full document requests: the browser may not request a new HTML document; it may request JSON data instead.

• Client-side routing: the URL changes, but the page is updated by JavaScript.

• Different caching behavior: API responses may be cached differently than HTML documents.

Practical implication: if “refresh fixes it,” you might be seeing a client-side routing state bug rather than a server bug. Conversely, if only refresh breaks it, you might be missing server-side routes for deep links.

Step 13: Observability Checklist: What to Capture When Debugging

When something goes wrong in the end-to-end flow, you want to capture evidence at the right layer. Here is a practical checklist you can use.

On the client (browser)

• Exact URL and whether the browser rewrote it (scheme/host changes).

• Redirect chain: how many hops, and where they go.

• Timing breakdown: waiting vs downloading vs CPU work.

• Which request failed: document, CSS, JS, font, API, image.

• Console errors: blocked resources, CORS issues, script errors.

On the edge / reverse proxy

• Request ID (or trace ID) to correlate logs.

• Cache status: hit/miss/stale/revalidated.

• Upstream selected: which backend instance handled it.

• Response code and bytes sent.

On the application

• Handler/controller that processed the request.

• Dependency timings: DB query time, internal API latency.

• Errors and retries: timeouts, circuit breakers, fallbacks.

Practical implication: end-to-end debugging is mostly correlation. A single request ID propagated through layers can turn a “mystery slowness” into a clear timeline.

Step 14: A Concrete Walkthrough Example (Putting It All Together)

Let’s narrate a realistic sequence for a first-time visit to a site with a CDN, an app backend, and client-side API calls. This is not the only possible sequence, but it is representative.

Navigation request

• You type example.com/products and press Enter.

• The browser treats it as a URL and assumes HTTPS.

• It checks Service Worker and cache; nothing is available (first visit).

• It routes traffic based on system proxy/VPN settings.

• The request reaches the edge network closest to you.

• The edge enforces security rules and checks its cache for the HTML. It is a miss.

• The edge forwards the request to the origin reverse proxy.

• The reverse proxy routes /products to the web application service.

• The app checks whether you have a session cookie. You do not.

• The app renders a generic products page (server-side) and calls a product catalog service and a pricing service.

• The app returns HTML with links to CSS/JS bundles on a static asset domain.

• The edge returns the HTML to your browser and may store it if caching rules allow.

Subresource phase

• The browser parses the HTML and immediately requests the CSS bundle, JS bundle, logo images, and a font file.

• Static assets are served from the CDN edge (often cache hits).

• Once the JS bundle runs, it calls /api/recommendations and /api/inventory to personalize the page.

• The API requests go through the same edge and reverse proxy but may route to different backend services.

• The API responses return JSON; the browser updates the page content without a full reload.

State changes for the next visit

• The browser now has cached static assets, possibly cached HTML (depending on directives), and potentially a Service Worker installed.

• Subsequent navigations may reuse warmed connections and cached resources, making the site feel much faster even if the server behavior is unchanged.

Hands-On: Reproduce the Walkthrough with Simple Tools

You can observe much of this flow yourself using built-in browser tools and a couple of command-line commands.

Browser DevTools (Network tab)

• Open DevTools → Network.

• Enable “Preserve log” to keep redirects and navigation requests visible.

• Reload the page and inspect the first document request: look at status, headers, and timing.

• Sort by “Waterfall” to see which resources block rendering and which are late.

• Filter by “Doc”, “JS”, “CSS”, “Fetch/XHR” to separate document load from API calls.

Command line: follow redirects and inspect headers

curl -I -L https://example.com/products

This shows the redirect chain and final response headers. It’s a quick way to spot accidental redirect loops, missing caching headers, or unexpected intermediaries.

Command line: see where the hostname routes from your location

traceroute example.com

This can hint whether you are being routed to a nearby edge or through an unusual network path (though some networks block or de-prioritize traceroute traffic).