FSD Frontend System Design

Part III — The Speed · Lesson 5.1

Performance Overview

In one lineThree metrics describe what a user feels: is it there, does it respond, does it stay still.

Where you've seen itA news article that paints, then shifts as an ad slot fills — and your tap lands on the wrong link.

  • Time14 min
  • DiagramCore Web Vitals on a page-load timeline
  • Chapter5 · Performance

Diagram

diagram
THE THREE VITALS ON ONE TIMELINE

  0s        1s        2s        3s        4s
  ├─────────┼─────────┼─────────┼─────────┤
  │                                       │
  ▼ TTFB    ▼ FCP           ▼ LCP         │
  first     first           largest       │
  byte      pixel           content       │
  (server)  (something)     (the thing    │
                             you came for)│
                                          │
       user taps ──► ▼ INP                │
                     how long until the UI responds
                                          │
       any element moving = CLS ──────────┘

  LCP  ≤ 2.5s   is it THERE?
  INP  ≤ 200ms  does it RESPOND?
  CLS  ≤ 0.1    does it STAY STILL?
diagram
WHAT EACH METRIC BLAMES

  LCP slow  ─► slow server (TTFB) · render-blocking CSS/JS
              · unoptimised hero image · client-side-only rendering

  INP slow  ─► long tasks on the main thread · heavy event handlers
              · huge re-renders · hydration still running

  CLS bad   ─► images without dimensions · ads/embeds injected late
              · web fonts swapping · content inserted above viewport
diagram
THE MENTAL MODEL — one thread does almost everything

  main thread:  [parse HTML][eval JS][layout][paint] [long task 380ms]
                                                      ▲
                                    user taps here ───┘
                                    nothing happens for 380ms

  Every long task is a moment your UI is frozen.

How it works

  1. LCP marks when the largest visible element renders — usually a hero image or headline block.
  2. INP measures the worst interaction latency across the visit, replacing the old FID (which only measured the first one).
  3. CLS sums unexpected layout shifts across the page's life, weighted by how much moved.
  4. All three are measured at p75 of real users (see 4.5) — a metric measured on your laptop is not a metric.
  5. Fix in dependency order: TTFB → render-blocking resources → LCP element → main-thread work.

Trade-offs

MetricCheapest big win
LCPPreload the hero image, cut render-blocking CSS
INPBreak up long tasks, defer non-critical JS
CLSwidth/height on images, reserve ad slots
TTFBCDN, edge caching, faster origin

Interview angle

"Which metric would you optimise first, and why?"

  • Start with LCP, because it usually shares a root cause with TTFB and render-blocking resources — one fix moves several numbers.
  • Then INP, since main-thread work is what makes an app feel broken even after it looks loaded.
  • CLS is usually the cheapest fix of the three: dimensions on media and reserved space for late-injected content.

Recap

  • There, responsive, stable — LCP, INP, CLS.
  • One main thread does parsing, JS, layout, and paint; long tasks freeze all of it.
  • Always p75 of real users, never a single lab run.