Inside the browser

The journey your file actually takes

You write app.js. Somewhere between that and a button lighting up on screen, a lot happens that nobody shows you. Here is the whole route, and then each stop in turn.

Step 1 — the parser meets your script tag

The browser reads HTML top to bottom, building the DOM as it goes. Then it hits a <script>, and by default it does something drastic: it stops. Parsing halts, the file is downloaded, the file is executed, and only then does HTML parsing resume.

This is not an accident. A classic script is allowed to call document.write and inject markup at that exact position, so the browser cannot safely read ahead. One slow script in <head> means a blank page until it lands — no text, no layout, nothing.

<script type="module"> is deferred automatically — you get defer behaviour without asking. That is one more reason the module version is the sane default.

Step 2 — what the engine does with the file

Your source is text. The CPU runs machine code. The engine (V8 in Chrome and Node, SpiderMonkey in Firefox, JavaScriptCore in Safari) closes that gap in stages:

1. Tokenise — chop the text into meaningful pieces: const, total, =, 42.
2. Parse into an AST — an abstract syntax tree, the shape of your program as data. A syntax error is thrown here, before a single line runs, which is why one stray brace kills the entire file rather than just its own line.
3. Compile to bytecode — compact instructions an interpreter executes right away. This is why JS starts fast instead of waiting on a full compile.
4. Watch, then optimise — the engine counts how often each function runs. A function that runs constantly is "hot", so an optimising compiler rewrites it into real machine code, betting on the types it has seen so far.
5. Deoptimise when the bet fails — feed a function that always got numbers a string, and the optimised version is thrown away and the engine falls back to bytecode.

Two useful consequences at beginner level. First, syntax errors are found before execution — so a typo at the bottom of the file stops the top of it from running. Second, keeping a function's inputs the same shape is not folklore, it is what keeps the optimised version alive. The full story, plus how to see it happening, is in Engine & memory.

console.log("does this line run?");

// A syntax error further down — uncomment to see
// const broken = ;

console.log("parse succeeded, so both lines print");

Remove the comment markers and run it again: the first log never appears. Nothing executed, because parsing never finished.

Step 3 — pixels, and the 16 millisecond budget

Most screens redraw 60 times a second. That gives the browser about 16.7ms to produce each frame — and your JavaScript shares that window, because it is the same thread. A frame is built in four stages:

• Style — which CSS rules apply to which element now.
• Layout (reflow) — the geometry: how big everything is and where it sits. Changing width, top or text content forces this, and it cascades to children.
• Paint — filling in pixels: colours, shadows, text.
• Composite — stitching the painted layers together, usually on the GPU. transform and opacity can often be done here alone, skipping layout and paint entirely — which is exactly why animating those two is smooth and animating left is not.

Rendering only gets its turn when the stack is empty. So a function that takes 100ms does not "slow down" the animation — it deletes six frames outright.

Dry run: counting the frames a 100ms handler actually costs

Same numbers as the demo above, as a table. Each frame gets a 16.7ms budget; the click handler needs 100ms in one go, starting partway through frame 3.

16.7ms × 6 ≈ 100ms — one blocking call is long enough to swallow six consecutive frame budgets whole (frame 3 through frame 8). Nothing queues those frames for later: a frame the browser could not build in its window is simply skipped, not delayed.

Where the event loop fits in a frame

Put the last chapter and this one together and the browser's turn order becomes concrete. Per pass, roughly:

1. run one task from the queue — a timer, a click handler, a network callback
2. drain every microtask queued by it, completely
3. run requestAnimationFrame callbacks — the moment designed for "change something visual"
4. style, layout, paint, composite — if there is time before the next frame

Two practical rules fall out of that list. requestAnimationFrame is where visual updates belong, because it runs immediately before rendering rather than at some arbitrary point mid-frame. And reading a geometric property like offsetHeight right after writing a style forces the browser to run layout early, in the middle of your loop, to answer you honestly — do that inside a loop over 200 elements and you have written the classic layout thrash.

// Thrashing: read, write, read, write - a forced layout each pass
for (const box of boxes) {
  box.style.height = box.offsetHeight + 10 + "px";
}

// Batched: all reads, then all writes - one layout
const heights = boxes.map((b) => b.offsetHeight);
boxes.forEach((b, i) => { b.style.height = heights[i] + 10 + "px"; });

The events that tell you the page is ready

If your script is deferred or sits at the end of <body>, you usually need neither. The DOM is already there.

Seeing it for yourself

None of this is theoretical — the browser will show you every stage. In DevTools, the Network panel shows which script blocked the parser, and the Performance panel records a real load: a flame chart of the call stack over time, long tasks flagged in red, and the layout/paint work in between. Record five seconds of your own page and the pipeline in this chapter appears, labelled, in front of you.

What to carry forward

• defer (or a module) for your own scripts; async only for things that do not touch your DOM.
• Syntax errors are found at parse time, before anything runs.
• 16.7ms per frame, shared with your code. Over ~50ms in one function and users feel it.
• Animate transform and opacity; they can skip layout and paint.
• Batch DOM reads and writes instead of alternating them.