FSD Frontend System Design

Part III — The Speed · Lesson 5.4

Performance Tools

In one lineRead the waterfall before you read the code — the shape of the chart names the bottleneck.

Where you've seen itA network panel where the hero image doesn't start until three other requests have finished, one after another.

  • Time16 min
  • DiagramAnnotated waterfall + which tool answers which question
  • Chapter5 · Performance

Diagram

diagram
READING A WATERFALL — the shape tells you the bug

  document    ████                                    TTFB 620ms ← slow origin
  app.css         ███                                 render-blocking
  app.js          ██████████                          render-blocking
  font.woff2              ████                        (discovered late)
  hero.jpg                    ████████                ← LCP element,
                                                        starts at 1.4s!
  api/user                            ██████          waited for JS
  api/feed                                  ██████    waited for api/user
                                                        ↑ CHAIN
  ├─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┤
  0    0.5   1.0   1.5   2.0   2.5   3.0   3.5   4.0s

  STAIRCASE shape = dependency chain → the real enemy
  Fix: preload hero + font, parallelise the API calls
diagram
WHICH TOOL ANSWERS WHICH QUESTION

  "what's slow?"           DevTools Network panel   → waterfall
  "why is the UI frozen?"  DevTools Performance     → flame chart,
                                                      long tasks
  "what should I fix?"     Lighthouse               → prioritised list
  "on a real device?"      WebPageTest              → filmstrip, real
                                                      phones, locations
  "what's in my bundle?"   source-map-explorer      → treemap
  "is it leaking memory?"  DevTools Memory          → heap snapshots
  "what do users get?"     RUM / CrUX               → field p75
diagram
LONG TASKS IN THE FLAME CHART

  main thread ──────────────────────────────────────────────►
  [ parse ][ eval bundle.js ─── 420ms ───][hydrate 280ms][ok]
             └──────────── anything > 50ms blocks input ────┘

  Look for wide blocks. Width = frozen UI. Names come from your code.

How it works

  1. Always throttle first — 4× CPU slowdown, Slow 4G. Unthrottled numbers on a dev machine are fiction.
  2. Start in the Network panel. Find the LCP resource and ask what delayed its start, not its duration.
  3. Identify chains. A staircase means each request had to wait for the previous one to be discovered — the highest-value fix is usually preload or parallelisation.
  4. Move to Performance for anything after load: long tasks, layout thrash, excessive re-render.
  5. Confirm with Lighthouse, then verify on a real device with WebPageTest before claiming a win.

Trade-offs

ToolBest forBlind spot
DevToolsDeep, interactive debuggingYour machine only
LighthouseQuick prioritised auditSimulated throttling variance
WebPageTestReal devices, filmstripsSlower to iterate
Bundle analyzerWhat to deleteNothing about runtime

Chrome's Coverage tab deserves a mention: it shows unused bytes per file at runtime, which is the fastest way to justify code splitting to a skeptic.

Interview angle

"Walk me through debugging a slow page."

  • Throttle, reload, open the waterfall, and find what delays the LCP element's start time.
  • Chains and render-blocking resources first; only then look at bundle size and main-thread work in the flame chart.
  • Verify on a real mid-tier device, then lock the win in with a CI budget (4.5) so it doesn't regress.

Recap

  • Waterfall first: a staircase means a dependency chain, and that's the biggest lever.
  • Flame chart for anything after first paint — wide blocks are frozen UI.
  • Throttle every measurement, or you're debugging a page your users never see.