1st Principles
Menu

Web · 32 min read

Browsers

The universal web client: how browsers fetch, parse, sandbox, and render, tying DNS, TLS, HTTP, and HTML/CSS/JS into one user-facing machine.

Why this exists

The web's power comes from a ubiquitous client that can safely run untrusted content from anywhere. That client is the browser.

Browsers orchestrate DNS, TCP/QUIC, TLS, HTTP, parsing, layout, painting, and a JavaScript engine, while enforcing security boundaries between sites.

If you only learn server frameworks, you will misdiagnose half of user-visible failures that actually live in client behavior, caching, or sandbox rules.

Axioms & primitives

  1. 01A browser is a networked rendering runtime for web content, not merely a document viewer.
  2. 02Same-origin policy is a foundational isolation boundary between sites.
  3. 03Fetching is a dependency graph: HTML discovers subresources that discover more.
  4. 04Rendering turns DOM/CSSOM into frames through style, layout, paint, and composite stages.
  5. 05Users experience the critical path: DNS, connect, TLS, TTFB, download, parse, and script delays.
  6. 06Extensions and settings can change networking (DoH, proxies) relative to other tools on the same OS.

Learning objectives

After this lesson you should be able to:

  • Narrate the steps a browser takes from URL bar to first paint at a systems level.
  • Explain same-origin policy with one allowed and one blocked cross-origin example.
  • Use the idea of a critical path to explain why a slow script blocks rendering.
  • Distinguish a browser network failure from an HTTP 500.
  • State why DevTools and curl can disagree about cookies or DNS.

Progressive depth

Read the layers in order for a full explanation. Or open the layer you need.

01

Intuition

You press Enter on a URL. The browser becomes a project manager: resolve the name, connect securely, fetch HTML, discover CSS and scripts, build a model of the page, and paint pixels, all while keeping site A from reading site B's private data.

That combination of networking competence and hostile-content sandboxing is why browsers are among the most complex consumer programs.

When a page 'does not load,' ask which job failed: name resolution, connection, certificate, HTTP status, parse, or script exception.

02

Formal shape

Navigation: parse URL, check HSTS/cache, DNS lookup, establish TCP/QUIC, TLS handshake, HTTP request, response handling (redirects, status), begin parse.

Parser builds DOM; CSS builds CSSOM; render tree / layout computes geometry; paint records draw ops; compositor ships frames to the GPU.

JS runs on an event loop; long tasks block input and rendering. Modules, defer/async script attributes, and workers change scheduling.

Security: same-origin policy, CORS, CSP, mixed content blocking, cookie jar rules, and permissions (camera, notifications) mediate powerful APIs.

Cold navigation path

Click a stage to follow the jobs this page lists when you press Enter on a URL.

Loading diagram...

Select a stage to read the boundary detail.

03

Worked examples

Critical path: a CSS file in <head> blocks rendering; a synchronous script without defer blocks parsing. Moving noncritical scripts down or deferring them improves time-to-content.

CORS failure: frontend at https://app.example fetches https://api.example without ACAO headers; browser blocks JS from reading the response even if the server replied 200.

DevTools waterfall: long DNS or TLS bars point below HTTP. A fast 200 with a huge JS bundle points at frontend architecture.

Service workers can intercept fetches and serve offline caches, adding another layer between page and network.

04

Edge cases

Site isolation and process sandboxing differ by browser engine and evolve with exploit pressure.

Prefetch/preconnect hints change networking before navigation; misuse wastes bandwidth.

Private mode changes storage persistence, not physics: you still use the same internet.

Embedded WebViews are browsers with different default security knobs; mobile apps often surprise web engineers here.

Mental models

  • Orchestra conductor

    Networking, parsing, rendering, and JS are sections. The browser conducts; a late soloist (blocking script) stalls the concert.

  • Hotel with locked rooms

    Each origin is a room. JS from one room should not rifle drawers in another. Doors (CORS) open intentionally.

  • Assembly line to pixels

    Bytes become tokens become DOM become boxes become layers become pixels. Jank is often a stage overflowing.

Common misconceptions

  • Myth

    The browser just downloads an HTML file and shows it.

    Reality

    It builds a live document, applies CSS, runs JS, fetches dozens of subresources, and enforces security policies continuously.

  • Myth

    If curl works, the browser must work the same way.

    Reality

    Browsers send different headers, store cookies, enforce mixed content, use HTTP caches, and may use different DNS (DoH).

  • Myth

    Same-origin policy stops all cross-site communication.

    Reality

    It constrains JS access to responses by default; CORS, links, form posts, and public resources are deliberate escape hatches with rules.

  • Myth

    More JavaScript always makes pages richer and therefore better.

    Reality

    JS has a cost on the critical path. Richness that arrives late is often just delay.

Exercises

Work these without looking up answers first. Check yourself against the intent notes.

  1. Exercise 01

    A user sees a blank page; DevTools shows HTML 200, CSS 200, and a JS error 'Unexpected token'. Where is the failure altitude?

    What good looks like

    Application/JS parse or execute after successful HTTP; not DNS/TCP.

  2. Exercise 02

    Explain why an image from another origin can display in <img> while fetch() to the same URL may be unreadable to JS.

    What good looks like

    Embedding vs reading: SOP/CORS constrain JS access to response data; display elements have different rules.

  3. Exercise 03

    List the network-ish steps before first byte of HTML for https://example.com on a cold cache.

    What good looks like

    DNS, TCP/QUIC connect, TLS, HTTP request; mention HSTS/cache checks optionally.

Sources & further reading

External references. Prefer primary documents and clear explainers.

Go deeper on your own

These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.

  • MDN: How browsers workDocs

    Overview of navigation, parsing, and rendering. Use it to connect network fetches to the pixel pipeline.

  • MDN: Same-origin policyDocs

    The isolation rule that shapes almost every browser security boundary. Read it before debugging CORS.

  • web.dev: Rendering on the webDeep dive

    Compares SSR, CSR, and hydration tradeoffs. Use it when browser architecture meets app delivery choices.