Performance Budget vs Real User Metrics (RUM)
Understand the difference between performance budgets (synthetic limits) and Real User Monitoring (RUM) data. Learn how to use both together for a complete performance strategy.
Detailed Explanation
Performance Budget vs Real User Metrics
Performance budgets and Real User Monitoring (RUM) serve complementary purposes. Budgets are proactive — they prevent regressions before deployment. RUM is reactive — it measures actual performance experienced by real users after deployment.
Key Differences
| Aspect | Performance Budget | RUM |
|---|---|---|
| When | Pre-deployment (CI/CD) | Post-deployment (production) |
| Data source | Synthetic (lab) | Real users (field) |
| Consistency | Deterministic | Variable (devices, networks) |
| Metric types | File sizes, request counts | LCP, FID, CLS, TTFB |
| Feedback speed | Immediate (PR check) | Delayed (hours/days to collect) |
| Control | Full (your code) | Limited (user conditions vary) |
Why You Need Both
Budget alone is insufficient:
- A 500 KB page can still be slow if all resources are render-blocking
- Third-party scripts might add latency not captured by file size checks
- Server response time (TTFB) is not part of a page weight budget
- Layout shifts (CLS) are not related to page weight
RUM alone is insufficient:
- By the time RUM shows a regression, it is already affecting users
- RUM data requires enough traffic to be statistically significant
- RUM cannot prevent a bad deploy — only detect it after the fact
- Attribution is difficult (was it code change, server issue, or network?)
Using Both Together
The ideal workflow:
- Pre-merge: Performance budget check in CI (size-limit, Lighthouse CI)
- Post-deploy staging: Synthetic Lighthouse run against staging
- Post-deploy production: RUM collection (Web Vitals, custom metrics)
- Weekly review: Compare RUM trends against budget thresholds
RUM Tools
| Tool | Type | Cost |
|---|---|---|
| web-vitals (npm) | Library | Free |
| Google Search Console | CWV report | Free |
| Vercel Analytics | Edge-based | Free tier |
| SpeedCurve | Synthetic + RUM | Paid |
| Datadog RUM | Full-featured | Paid |
| New Relic Browser | Full-featured | Paid |
Bridging the Gap
Map your performance budget to expected RUM outcomes:
| Budget Metric | Expected RUM Outcome |
|---|---|
| Total weight < 600 KB | LCP < 2.5s on 4G |
| JS < 200 KB | FID/INP < 200ms |
| No layout shift resources | CLS < 0.1 |
| Critical CSS inlined | FCP < 1.5s |
| Image dimensions specified | CLS < 0.05 |
If RUM shows LCP > 2.5s but your budget is under 600 KB, the issue is likely server-side (TTFB) or resource loading order, not asset weight.
Use Case
Combining budgets with RUM creates a complete performance strategy. A product team might set a 500 KB page weight budget enforced in CI, then track p75 LCP in production via web-vitals. If the budget passes but RUM shows slow LCP, the team investigates server response time or resource loading order — problems the budget cannot catch. Conversely, if a developer's PR exceeds the budget, it is blocked before it can affect any real user.