Performance profiling

The performance fundamentals lesson's rule holds in the browser: measure first. JavaScript performance is dominated by surprising costs — layout, rendering, network — that intuition gets wrong. Devtools show you the truth.

Measure, then profile

For a quick comparison, performance.now() gives high-resolution timing:

const start = performance.now();
doWork();
console.log(`took ${performance.now() - start} ms`);

For where time goes, the Performance panel in browser devtools records a timeline of script execution, rendering, and idle time — your cProfile equivalent. The tall bars are your hotspots; optimise those, ignore the rest.

The frame budget

Smooth UIs refresh ~60 times a second, which leaves about 16 milliseconds per frame for all your work. Blow that budget — a long synchronous task (the event-loop lesson) — and the page visibly stutters, because the main thread can't render. The goal isn't "fast" in the abstract; it's "fits in the frame budget."

Highest-leverage speedups

In the browser, the biggest wins are usually not tweaking your loops:

• Ship less JavaScript. Parsing and executing JS is often the dominant cost. Smaller bundles (the builds lesson) beat micro-optimisation.
• Minimise layout/render work. Touching the DOM in a loop forces expensive recalculation; batch DOM updates instead.
• Keep heavy work off the main thread — Web Workers (the event-loop lesson) so the UI stays responsive.
• Algorithms still matter — an O(n²) loop over a big list is slow in any language (the complexity lesson).

Where to go next

That completes Performance & Internals. The next module covers the tooling and type-level skills of a serious JS/TS codebase: Tooling & Types.