Measuring Performance: Lighthouse vs RUM (and Setting Budgets)

What you’ll learn

• Lab metrics vs field metrics
• Why Lighthouse can mislead you
• How to set budgets that teams actually follow

---

30‑second interview answer

Lighthouse is lab testing: controlled conditions, good for debugging and regressions. RUM (Real User Monitoring) is field data: what real users experience. The best setup uses both: Lighthouse in CI for guardrails, and RUM for truth. Budgets should focus on the few things that correlate with user pain: CWV, long tasks/INP, and bundle size/JS execution.

---

Lab vs field

Lab (Lighthouse)

Pros:

• repeatable
• great for profiling

Cons:

• not your real devices
• not your real networks

Field (RUM)

Pros:

• real users
• captures variance

Cons:

• harder to debug without context

---

Useful budgets

• JS bundle size per route
• LCP target on mobile
• INP target
• CLS target

Budgets are only useful if they block regressions.

---

Common mistakes

• Chasing Lighthouse score at the expense of real UX
• Tracking too many metrics and acting on none
• No budget enforcement

---

Production rule of thumb

• Use Lighthouse as a regression alarm.
• Use RUM as the truth.
• Keep budgets small and enforceable.

---

Quick recap

• Lab helps you debug; field tells you what users feel.
• Budgets prevent slow creep.
• Focus on CWV + JS execution.

---

Performance checklist (copy/paste)

• Lighthouse in CI for regressions (lab)
• RUM for truth (field)
• Budgets: bundle size per route + CWV targets
• Track by device class (mobile vs desktop)