How does Browser Work?
Source: https://medium.com/@ph_vinayak/how-browser-works-1a085cb564ae ↗
A short walk through what actually happens when you type a URL and press enter — parsing, networking, rendering, paint.
It is not a canonical academic reference, but it is the shortest path to something every product director on the web needs and almost none has: a working picture of the browser as a machine with distinct stages, each with its own costs.
The piece pairs well with Rascia's treatment of the DOM: together they close the gap between intuition and ignorance about the medium you ship on.
Read it once, keep it in your head, and every "why is this slow" conversation will go differently afterwards.
Central argument
The article argues that the browser is not a black box but a deterministic pipeline with discrete, identifiable stages — DNS resolution, HTTP request, HTML parsing, DOM construction, rendering tree assembly, layout, paint — and that each stage carries its own latency and failure surface. The central claim is that understanding this sequence as a machine, not a mystery, changes how you reason about performance. Slowness is not a vague property of a page; it is an event that can be located at a specific stage in a specific process.
Critique
Because it targets accessibility over depth, the article necessarily flattens the complexity of the modern browser: the distinction between the main thread and compositor thread, speculative parsing, or how browsers prioritize critical rendering path resources are either absent or oversimplified. A practitioner who internalizes this model as complete may feel equipped to diagnose performance when they are actually missing the concepts that explain most real-world regressions — paint storms, layout thrashing, or jank caused by JavaScript blocking the main thread. The piece is a useful first map, but it can create false confidence if not paired with more precise sources.
Why it matters for product
A product director who understands the browser as a staged pipeline can hold more productive conversations with engineering during performance triage — instead of escalating 'the page feels slow,' they can ask where in the pipeline the cost is being paid, which changes the quality of the diagnosis and the specificity of the fix. It also sharpens prioritization decisions: knowing that rendering and paint are downstream of networking means that eliminating a blocking resource is categorically different from optimizing a component render, and conflating them leads to misallocated engineering capacity. For leaders setting quality standards or defining what 'done' means for web features, this model provides the vocabulary to make those standards technically coherent rather than purely experiential.