Frontend Principal Engineering — Measured
"When advice is repeated confidently and cheaply, measure it before you design around it." — heuristic earned in Phase 1 of this curriculum
A lab-based curriculum for becoming the frontend subject-matter expert for a large engineering organisation. Every claim in it is measured in a real browser, and every measurement is reproducible with one command.
What makes this different
Most frontend curricula are prose. This one is a measurement harness with prose attached.
Twenty-two experiments drive Chrome for Testing 149 over the Chrome DevTools Protocol —
forcing garbage collection, parsing heap snapshots, dumping the real accessibility tree, sampling
the renderer's own style and layout accounting, and dispatching trusted keyboard input. Every table
in every chapter came out of a script in that module's src/, and npm run all regenerates it.
That constraint produced results that contradict widely-repeated advice:
| Common belief | Measured |
|---|---|
Chunking work with await keeps the page responsive | 0 frames rendered over 400 ms; 49 for task-based chunking |
| Moving work to a Web Worker makes it faster | The naive worker was the worst of seven strategies — worse than doing nothing |
| A closure only retains what it references | An unused, never-called sibling retained 38 MB vs 0.01 MB |
performance.memory will show you a leak | Freeing 508 KB of detached DOM moved the JS heap 0.10 MB |
| Semantic HTML is verbose | Div soup was 1.38× larger — with zero landmarks, headings or controls |
| Property order is the hidden-class hazard | 1.14×. delete is 11.9× |
| Flex and grid are slow; absolute is fast | 1.4× across six modes, and absolute was slowest |
| Large DOM is inherently slow | Identical 261,011-node DOM: 401.9 ms → 7.9 ms with one CSS declaration |
Each of those had a real effect somewhere, misremembered as a general rule. Learning to tell the difference is the actual curriculum.
The loop
Every module runs the same sequence, and the order is not negotiable:
Understand → Predict → Implement → Break → Debug → Measure → Compare → Explain
Predict is the load-bearing step. A prediction you get right needs no correction; a prediction you get wrong localises the defect in your model precisely. Every step file opens with a prediction you are asked to commit to in writing before running anything.
Measurement honesty
Three practices are enforced throughout, because performance work fails quietly:
Harness bugs are documented, not fixed silently. Every module hit at least one, and all produced
clean, plausible, wrong data — a reused JavaScript realm that voided 39 of 40 trials, INP computed
per-event instead of per-interaction, a shared page letting one variant's leak contaminate the next,
shared inline-cache state that reported doubles as 4× faster than integers. They live in each
module's docs/measured-results.md under "harness failure modes", because the reflex they teach
outlasts any individual number.
Unexplained results stay unexplained. One measurement in fe-03 reproduced, had its leading hypothesis tested and rejected, and was then abandoned because the effect is 0.6 nanoseconds. It is recorded as an open question, not dressed up as a finding. Knowing when to stop investigating is the same judgement as knowing when to stop optimising.
Every module states what its numbers do not prove. One machine, one browser version, synthetic content, no network. The ratios transfer; the milliseconds do not.
How to use this book
- Read Toolchain Setup — Node 18+ and a Chrome binary is the whole dependency list.
- Read the Curriculum Map for the dependency graph and why the ordering is what it is.
- Start at fe-01. Each module is self-contained:
fe-NN-<name>/
├── CONCEPTS.md # the "why" and the mental model — read first
├── references.md # specifications first; excluded sources named and justified
├── docs/
│ ├── measured-results.md # every number, with the browser version
│ ├── analysis.md # trade-offs, decision rules, what breaks at scale
│ ├── execution.md # tool versions, quick start, method notes
│ ├── verification.md # pass/fail checkpoints with expected output
│ ├── observation.md # how to read the evidence, and its limits
│ └── broader-ideas.md # where the mechanism reappears later
├── steps/ # predict → run → expected output → what just happened
└── src/ # the experiments. `npm install && npm run all`
- Do the Principal Engineer Review at the end of each module in writing. Several questions are about refusing work with arithmetic, which is most of the practical value.
Three tracks
| Track | Prefix | Modules | Focus |
|---|---|---|---|
| Frontend Principal Engineering | fe-NN | 6 built of 51 | judgment, architecture, measured trade-offs |
| Browser Internals | bi-NN | 17 | Chromium, Blink, V8 — source to pixels |
| Framework Internals | fw-NN | 12 | build a React, signals, bundler, router, query cache |
Siblings, not stages. The frontend track develops judgment; the internals tracks remove abstraction
boundaries. The measured-evidence discipline described above is fully applied to the fe- track so
far; the bi- and fw- tracks share the structure and are at an earlier stage of that treatment.
Source of truth
This book is derived from two specification files, which remain authoritative:
- Frontend Principal Engineering — the 46-area curriculum spec
- Browser & Framework Internals — the sibling depth track
Where the book and the specifications disagree, the specifications win.