FSD Frontend System Design

Part III — The Speed · Lesson 5.3

Performance Monitoring

In one lineLab tests tell you what changed; field data tells you what users actually got.

Where you've seen itA green Lighthouse score in CI while support tickets say the app is unusable — both are true, on different devices.

  • Time15 min
  • DiagramRUM vs synthetic + percentile distribution
  • Chapter5 · Performance

Diagram

diagram
TWO KINDS OF MEASUREMENT, TWO DIFFERENT JOBS

  SYNTHETIC (lab)                    RUM (field)
  ┌──────────────────────┐           ┌──────────────────────┐
  │ same device          │           │ every device         │
  │ same network         │           │ every network        │
  │ same time            │           │ all the time         │
  │ before merge         │           │ after deploy         │
  └──────────────────────┘           └──────────────────────┘
        │                                    │
        ▼                                    ▼
   "did THIS change                  "what are users
    make it slower?"                  actually getting?"
        │                                    │
        └──── gate merges ───┐   ┌──── alert on regressions
                             ▼   ▼
                       you need BOTH
diagram
THE DISTRIBUTION IS THE STORY

  users (count)
    ▲
    │  ████
    │  ████ ██
    │  ████ ████
    │  ████ ████ ██          ██
    │  ████ ████ ████ ██  ██ ██ ██
    └───┬────┬────┬────┬────┬────┬───► LCP
       1s   2s   3s   4s   6s   9s
            ▲         ▲         ▲
          median     p75       p95
           1.9s      3.4s      8.2s

  Reporting "average 2.4s" hides both the 3.4s and the 8.2s.
diagram
RUM COLLECTION — a few lines, sent on page hide

  web-vitals lib ──► onLCP/onINP/onCLS ──► beacon ──► your endpoint
                                            │
                          navigator.sendBeacon survives page unload;
                          fetch() does not.

How it works

  1. Instrument with the web-vitals library — it implements the exact definitions Chrome reports, including edge cases you'd get wrong by hand.
  2. Send on visibilitychange → hidden, using sendBeacon, so metrics survive the user navigating away.
  3. Attach dimensions: route, device class, connection type, country, release version. Aggregate numbers without dimensions are undebuggable.
  4. Alert on p75 by route, not sitewide — a regression on checkout drowns in a sitewide average.
  5. Correlate with deploys. The first question about any regression is "what shipped?"
js
import { onLCP, onINP, onCLS } from 'web-vitals';

const send = (metric) =>
  navigator.sendBeacon('/rum', JSON.stringify({
    name: metric.name, value: metric.value, route: location.pathname,
    release: __BUILD_ID__, conn: navigator.connection?.effectiveType,
  }));

[onLCP, onINP, onCLS].forEach((fn) => fn(send));

Trade-offs

SourceStrengthLimit
Lighthouse CIComparable, pre-mergeOne synthetic profile
CrUXReal Chrome users, free28-day rolling, coarse
Your own RUMYour routes, your dimensionsYou build and maintain it
Vendor RUMFast to adopt, rich UICost, another third-party script

Interview angle

"Lighthouse says 98. Users say it's slow. Who's right?"

  • Both — Lighthouse measures one simulated device, field data measures the population.
  • Look at p75 and p95 by device class and route; the regression is almost always concentrated somewhere specific.
  • Keep lab for gating merges and field for alerting; using either alone leaves a blind spot.

Recap

  • Synthetic gates changes; RUM tells the truth.
  • Report p75 and p95 with dimensions attached — averages hide the users who leave.
  • sendBeacon on page hide, or you lose the metrics that matter most.