How do I choose budgets that won’t create noise?

Use current medians on stable hardware as your baseline, then set budgets with 10–20% headroom. Run 3–5 iterations and gate on the median. Tweak thresholds per route; checkout deserves stricter budgets than blog pages.

Should we block merges on synthetic metrics only?

Block on synthetic for immediate feedback (Lighthouse CI, k6) and complement with RUM (e.g., INP from real users via Google Analytics 4 or Elastic RUM) for ongoing validation. If RUM drifts despite green builds, tighten the gate or adjust test realism.

Our stack is a legacy monolith. Is this only for SPAs on Kubernetes?

No. You can run Lighthouse against server-rendered pages and k6 against any HTTP endpoint. We’ve put this in Jenkins for on-prem monoliths and in Buildkite/GitHub Actions for microservices. Start with one route and one API.

What about AI-generated code and perf regressions?

Treat AI suggestions like junior dev PRs: benchmark, profile, and gate. We’ve seen Copilot add “harmless” client-side JSON parsing that doubled bundle size. Add bundle-size checks and Web Vitals gates to catch vibe coding regressions early.

How do we tie improvements to dollars?

Use switchback or A/B tests with holdout groups. Track conversion, retention, and support tickets alongside perf metrics. Even simple before/after analysis with seasonality-aware controls can show revenue impact.

Performance-optimization · Dec 9, 2025 · 9 minute read

The Build That Saves Your UX: Catching Performance Regressions Before Users Feel Them

Perf doesn’t die in a fire; it bleeds out via tiny regressions that nobody notices—until your conversion graph does. Here’s how to make performance a merge blocker with metrics your CFO cares about.

Back to all posts

The Build That Saves Your UX: Catching Performance Regressions Before Users Feel Them

Key takeaways

Implementation checklist