open atlas

browser

Browser & Frontend Runtime

What actually happens inside the browser when your page loads and runs — how JavaScript is scheduled, how pixels get drawn, and where the slow parts hide.

9 units·83 lessons·~50 h

Start track
00

Start from zero

Before the senior material: what the browser runtime even is, and the handful of words the rest of the track assumes you already know.
01

The event loop

One thread, two queues, one render step — and everything that happens when any of them stalls.
02

The render pipeline

Six stages, two threads, one 16.67 ms budget — how bytes become pixels, and what breaks the budget.
03

V8 internals

Four JIT tiers, hidden classes, inline caches, Orinoco GC, and the deopt-loop — the mechanisms that make the same JS run 100× faster or slower.
04

Workers

Off-main-thread compute, network proxy, and shared memory — the three worker primitives and the architectural mistakes they cannot solve.
05

React fiber reconciler

A fiber is a JS object whose linked-list tree lets React pause, resume, and prioritise rendering — and the bailout mechanism is what keeps large UIs fast.
06

Render strategies: SSR, SSG, ISR, streaming, RSC — and the cost of hydration

SSG renders once at build; SSR per request; ISR refreshes on a schedule; streaming flushes the shell first. Hydration is the separate ~2× cost of making that HTML interactive — RSC and islands cut what needs to hydrate.
07

Core Web Vitals: LCP, INP, and CLS

Three field metrics Google scores pages on — did it show up fast (LCP), does it respond (INP), does it stay still (CLS)?
08

Putting it all together

Page load is a relay race through network, parse, paint, and hydration — the capstone unit traces all eight layers, names the five places production reliably dies, and gives you the three-move discipline to diagnose and fix any of them.

Build with this track

Guided projects that exercise what you learn here.

Next track

Frontend Architecture

How to structure a real frontend app: where data lives, how to load it, and how to keep a growing codebase from turning into a mess.