Start from zero: what a browser actually does
When a browser opens a page it downloads HTML, builds the DOM, applies CSS, runs JavaScript on a single main thread, and paints pixels. This is the zero-level map and the eight words the rest of the browser track assumes you already know.
You type a URL, press Enter, and a few hundred milliseconds later a fully interactive page is sitting in front of you. Something received bytes from a server, figured out what colour every pixel should be, and handed your fingers control over the result. That something is the browser — and it does all of it on a single thread of execution, one task at a time, without ever pausing to ask you which thing to do next. Every advanced topic in this track — the event loop, the render pipeline, React Fiber, Web Workers, Core Web Vitals — is a detail of that one-thread story. This lesson is the map before the climb.
The one thing the browser does
You give the browser a URL. It fetches an HTML document and starts reading it top to bottom. As it reads, it builds a tree of nodes — the DOM — that represents every heading, paragraph, image, and button on the page. Linked CSS files are downloaded and turned into a style tree. JavaScript files are downloaded, parsed, and executed on the main thread. When the JS finishes, the browser combines the DOM and styles, works out the geometry of every element, and issues drawing commands to the GPU. Pixels appear on screen.
That sentence is the whole track in miniature. Every later unit zooms into one step of that pipeline — and every performance problem you will ever debug is caused by something in that pipeline taking longer than the user is willing to wait.
The eight words the rest of the track assumes
The senior lessons that follow drop these terms without stopping to define them. Here they are, one sentence each — what it is and why it exists.
| Word | What it is | Why it exists |
|---|---|---|
| HTML | A text file that describes the structure and content of a page using tags. | So the browser knows what content exists and how it is organised. |
| CSS | Rules that say which element looks which way — colour, size, position. | So appearance is separated from content and can change without rewriting HTML. |
| JavaScript | A programming language that runs inside the browser and can change anything on the page. | So pages can react to clicks, load new data, and update without a full reload. |
| DOM | The live tree of objects the browser builds from HTML — every element is a node. | So JavaScript has something concrete to read and modify at runtime. |
| Parsing | Reading a text file and converting it into a data structure the browser can work with. | So raw bytes from the network become the DOM and style trees the renderer needs. |
| Main thread | The single execution thread where parsing, JS, layout, and paint all happen. | So the browser has one authoritative place that owns the DOM and can mutate it safely. |
| Repaint / reflow | Repaint redraws pixels; reflow recalculates layout before repainting. | So the screen stays correct after the DOM or styles change — but both cost time. |
| Event loop | The scheduler that picks the next task — click handler, timer, network callback — and runs it on the main thread. | So a single thread can appear to do many things without blocking forever on any one of them. |
How they fit together
Read in order, the words tell one story: the browser downloads the HTML and parses it into the DOM. Linked CSS is parsed into a style tree alongside it. JavaScript runs on the single main thread — it can read and mutate the DOM, which triggers a reflow (if geometry changed) and a repaint to push fresh pixels to the screen. When JS needs to wait for something — a click, a timer, a network response — the event loop parks that work and picks up the next task so the thread never sits completely idle. That loop, and everything that can delay it, is what Unit 01 is about. When you next open DevTools and see a long yellow task blocking the main thread, you will know exactly which step of this pipeline is responsible.
▸Why this works
Why one thread? Shared mutable state is the root of most concurrency bugs. If two threads could touch the DOM at the same time, you would need locks everywhere and race conditions would break layouts in ways that are nearly impossible to reproduce. One thread means the DOM is always in a consistent state. The price is that anything slow on that thread blocks the user from seeing updates — which is exactly why you will spend the rest of this track learning how to keep the main thread free.
You do not need to memorise this
Two honest notes before the climb. First: nobody holds all of this at once on day one — you will meet each word again, in depth, in its own unit, and it will stick then. This page is a coat-hook to hang the details on, not a test. Second: the browser’s job sounds simple — download, parse, run, paint — but each step has a decade of optimisation and failure modes baked in. The senior track teaches the full picture because that is what building fast, correct web apps at scale demands.
Why does the browser use a single main thread for parsing, JavaScript, and painting?
Order what the browser does from the moment you press Enter to pixels on screen:
- 1 Download HTML and parse it into the DOM
- 2 Download and parse CSS into the style tree
- 3 Execute JavaScript on the main thread (may mutate the DOM)
- 4 Run layout (reflow) and paint pixels to the screen
- 01In one breath: what does a browser do when you open a page, and why does it all happen on one thread?
- 02Name the eight foundational terms and give one-sentence definitions for at least four of them.
The browser’s job is one pipeline: download HTML and parse it into the DOM, apply CSS styles, execute JavaScript on the main thread, and paint pixels. Every element you can see or click is a node in the DOM; every visual rule lives in the style tree; every interaction passes through the event loop before reaching your code. The pipeline runs on a single main thread because a shared mutable DOM across threads would be a race-condition disaster. The price of that safety is that anything slow on the main thread blocks the user — long JS tasks, expensive reflows, unnecessary repaints. Everything this track teaches is a strategy for keeping that pipeline lean. Now when you see a page freeze on a click or a scroll, you will know where to look first: something held the main thread too long, blocked the event loop, and the user felt it. Next up: Unit 01 — The Event Loop — where you will learn exactly how the browser decides which task to run next and why a 50 ms JS task can make a page feel broken.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.