How Browsers Load a Page

End-to-end navigation: resolve URL, fetch HTML, discover resources, parse, and get first pixels — without magic.

beginner3 min readUpdated Aug 4, 2026

browser
navigation
loading
critical-rendering-path

“How does a browser load a page?” is a common interview opener. A crisp answer walks navigation → network → parse → render, and names what your HTML can block. Depth lives in Critical rendering path and Rendering pipeline; this page is the full story arc.

Docs: Navigation and loading — web.dev, MDN How browsers work (concepts).

User hits Enter, clicks a link, or JS assigns location. The browser may consult service worker fetch handlers, bfcache for back/forward, or HTTP cache before the network.

Type URL → security checks → service worker? → cache? → network

2. Network for the document

DNS → connect → TLS → request → TTFB → streaming HTML bytes. Document TTFB gates everything downstream. CDN and origin performance matter before any frontend framework.

3. Streaming HTML parse

Bytes arrive → tokenizer builds DOM incrementally. Speculative parsing / preload scanner looks ahead for src/href to start fetches early even while a script blocks.

<!doctype html>
<html>
  <head>
    <link rel="stylesheet" href="/app.css" />
    <script src="/early.js"></script>
  </head>
  <body>
    <img src="/hero.avif" width="1200" height="630" alt="" />
    <script type="module" src="/app.js"></script>
  </body>
</html>

4. Discover and prioritize subresources

CSS (render-blocking), JS (parser-blocking unless deferred), images, fonts, fetch. Priority depends on type, position, and hints (fetchpriority, preload). LCP images should be discoverable in the initial HTML — LCP tactics.

5. CSSOM + DOM → render tree → first paint

When enough DOM/CSSOM exists and render-blocking CSS is ready, the browser can paint. Scripts without defer still stall DOM construction below them.

6. Later: deferred JS, hydration, idle work

type="module" / defer run after document parse. Hydration attaches listeners. Third parties should not sit on the critical path.

Diagram (compressed)

Navigate
  → Document (TTFB)
  → Parse HTML (preload scanner discovers assets)
  → CSS (blocks render) / JS (may block parse)
  → DOM + CSSOM → layout → paint → composite
  → Deferred JS / SW / ongoing interactions

What frontend engineers control

Lever	Effect
SSR/streaming HTML	Earlier discovery and text LCP
Script `defer`/`module`	Less parse blocking
CSS size/split	Earlier first paint
Image priority & formats	Faster LCP
Cache headers	Faster repeat loads
Avoid unload	Better bfcache

Interview out-loud

“Browser resolves the navigation, fetches HTML, streams parse while discovering CSS/JS/images, builds DOM and CSSOM, then layout and paint. Render-blocking CSS and parser-blocking JS lengthen the path to first pixels; LCP needs early discovery of the largest content.”

Story you can tell in 45 seconds

“User navigates; we resolve DNS and TLS; HTML streams; the preload scanner finds CSS, JS, and images; CSS blocks first paint; classic scripts can block parse; we build DOM and CSSOM, layout, paint; deferred JS runs after. I optimize discovery and reduce blocking resources so LCP doesn’t wait on a late client-rendered hero.”

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.