What Happens When You Open a Web Page

You type a URL, press enter, and a fraction of a second later a fully-formed page appears — text, images, colours, buttons that respond to your clicks. It feels instant and effortless. Underneath, the browser has just run one of the most impressive pieces of engineering you use every day: a pipeline that takes a stream of plain text off the network and turns it into precisely-positioned, interactive pixels. This guide is about that pipeline — what the browser is actually doing with the HTML, CSS, and JavaScript you write. This first chapter is the map: a bird's-eye view of the whole journey, so every later chapter has a place to fit.

It all starts with text

Here's the fact that surprises people: everything the browser receives is text. Your HTML is text. Your CSS is text. Your JavaScript is text. Even the request that fetches them is text. The browser's entire job is to take these streams of characters and transform them, step by step, into a picture on a screen and a page you can interact with.

That transformation is why a browser is far more than a document viewer. It's a parser, a layout engine, a graphics system, and a JavaScript runtime, all cooperating in a tightly-ordered sequence. Getting a page from URL to pixels breaks down into a handful of distinct stages, and almost everything you'll ever need to know about frontend performance and behaviour lives in understanding what each stage does.

The pipeline, end to end

When the HTML response starts arriving, the browser springs into action. At a high level, the path from those first bytes to a finished frame looks like this:

Fetch HTML

↓→

Parse → DOM

↓→

Parse CSS → CSSOM

↓→

Render tree

↓→

Layout

↓→

Paint & composite

Let's walk each stage at a glance — the rest of the guide is really just these six boxes, examined closely.

Fetch the HTML. The response arrives as a stream of bytes, which the browser decodes into characters and begins reading immediately — it doesn't wait for the whole file. As it reads, it can spot references to other resources (stylesheets, scripts, images) and start fetching those in parallel, before the HTML is even finished.

Parse HTML into the DOM. The browser turns the HTML text into the DOM — the Document Object Model — a tree of objects, one per element, that mirrors the structure of your markup. The DOM is the browser's living model of the page. This is chapter two.

Parse CSS into the CSSOM. In parallel, every stylesheet is parsed into a matching tree of style rules called the CSSOM. It records which visual properties apply to which elements, following the cascade. This is chapter three.

Build the render tree. The browser combines the DOM (what's on the page) with the CSSOM (how it should look) into a render tree — only the parts that will actually be visible, each annotated with its computed styles.

Layout. Now the browser calculates geometry: the exact width, height, and position of every box in the render tree, resolving all your percentages, flex, grid, and font sizes into real pixel coordinates. This — and painting — is chapter four.

Paint and composite. Finally, the browser fills in the actual pixels — text, colours, borders, shadows — often across several layers that are then combined ("composited") into the single image you see. And frequently handed to the GPU to do it fast.

That's the whole show. A page appears when this pipeline reaches the end for the first time.

Nothing is really "done"

There's a crucial twist, and it's what makes the browser a dynamic environment rather than a document printer: the pipeline doesn't run once and stop. The moment JavaScript changes the DOM, or a CSS class flips, or the window resizes, the affected stages run again to update the picture. Add an element, and the browser re-runs layout and paint. Change a colour, and it re-paints. This re-running is where both interactivity and performance problems come from — and it's why chapter six is entirely about doing it cheaply.

What blocks, and why you should care

Because the stages are ordered, some resources can hold up the ones behind them — and this is the root of most "why is my page blank for a second?" questions.

Resource	Effect on rendering
HTML	Parsed incrementally; the browser renders what it has so far
CSS	Render-blocking — the browser won't paint until it has the CSS, to avoid a flash of unstyled content
Synchronous JS (<script>)	Parser-blocking — HTML parsing pauses while the script downloads and runs
<script defer> / async	Non-blocking — the parser keeps going; the script runs later
Images	Don't block rendering; they paint in as they arrive

You don't need to memorise this table yet — later chapters earn each row. The point to carry now is that the order of the pipeline creates dependencies, and dependencies are where pages get slow. A stylesheet in the <head> can delay first paint; a blocking script mid-document can stall everything below it.

The mental model to carry forward

If you take one image from this chapter, make it this: a browser is a pipeline that turns text into pixels, and re-runs parts of itself whenever the page changes. Fetch, parse, style, layout, paint. Each stage has a name, a job, and a cost — and each gets a dedicated chapter ahead.

From here we go stage by stage. Next up: the very first transformation, where your HTML text becomes a living tree of objects the browser can render and your code can manipulate — the DOM. Once you can see the page as a tree, everything else in this guide clicks into place.