Rendering at Scale — Course Map
React decides what the UI should be. This section is about everything after that: getting pixels on screen fast, and keeping them there when the data gets huge.
Read this first. It takes five minutes.
Why this section exists
Most frontend learning stops at the framework: components, state, hooks. That's enough until one of these lands on your desk:
- "The landing page takes 4 seconds to show anything on mobile."
- "Typing in the filter box freezes the whole dashboard."
- "The table has 50,000 rows and scrolling is a slideshow."
- "We need to plot a million points from a live feed."
- "Design the frontend for a Figma-style canvas."
None of these are React problems. They're browser problems: how bytes become pixels, what the main thread can do in 16 milliseconds, how many DOM nodes a page can afford, and when to stop using the DOM at all. Senior frontend interviews probe exactly this, because it's what separates someone who uses a framework from someone who can make a product fast.
The one idea behind every chapter
The browser has one main thread that runs your JavaScript, calculates styles, does layout and paints, and it has about 16.7 ms per frame to do all of it if the screen is to update 60 times a second.
Every technique in this section does one of four things:
| Move | Chapters |
|---|---|
| Start sooner: get the first pixels out with fewer round trips | 1 · Critical Rendering Path |
| Do less per frame: render only what's visible, only what changed | 4 · Virtualization, 5 · Live Dashboards, 6 · Canvas |
| Do it elsewhere: move work off the main thread, or onto the GPU | 3 · Off the Main Thread, 7 · GPU Rendering |
| Do it in smaller pieces: let input and frames through between chunks | 2 · Main Thread and Scheduling |
Reading order
| # | Chapter | You'll be able to… |
|---|---|---|
| 1 | The Critical Rendering Path | Read a waterfall, find what blocks the first paint, and fix LCP with fewer round trips |
| 2 | The Main Thread and Scheduling | Explain the frame budget, find long tasks, and break them up so input stays responsive |
| 3 | Off the Main Thread | Decide what belongs in a Web Worker, move data cheaply, and render from a worker with OffscreenCanvas |
| 4 | Virtualization | Render 100,000 rows with a few dozen DOM nodes |
| 5 | Real-Time Data Dashboards | Ingest, buffer, downsample and draw a live feed without dropping frames |
| 6 | Canvas 2D Engineering | Build a canvas renderer with hit testing, pan/zoom and dirty-rect redraws |
| 7 | GPU Rendering and Choosing a Renderer | Choose between DOM, SVG, Canvas and WebGL with numbers, not vibes |
| 8 | Design Drills | Answer "design a million-point chart / spreadsheet / infinite canvas" end to end |
Chapters 1–3 are the foundation. Read them in order. After that the chapters stand alone.
How this connects to the rest of the site
This section builds on, and links to, the Frontend Engineering chapters rather than repeating them:
- FE-04 · Web Vitals: what LCP, CLS and INP measure. Chapters 1 and 2 are about moving them.
- FE-06 · CSS and Rendering Performance: compositor layers and layout thrashing. Chapter 2 assumes this.
- FE-05 · Network and Caching: HTTP caching and service workers. Chapter 1 covers the first visit, FE-05 the repeat ones.
- FE-07 · Memory Leaks: what happens when a dashboard runs for eight hours.
- FE-09 · Senior Frontend Scenarios: interview prompts that this section gives you the depth to answer.
- JS · The Event Loop Under Pressure, and its simulation: the task/microtask model that Chapter 2 builds on.
How each chapter is built
Every chapter has the same parts, so you know where to look:
- A story: a real-feeling failure that shows why the topic matters.
- First principles: what the browser is actually doing, with diagrams.
- Numbers to remember: the few figures that let you reason on a whiteboard.
- A DevTools workflow: how to find the problem in a real app.
- Cheat sheet and "Say it in the interview": for revision.
Three chapters include simulations that measure your own browser. Nothing in them is faked: the numbers are real timings from the device you're reading on, so they'll differ between your laptop and your phone. That difference is part of the lesson.