Won’t Lighthouse CI be too flaky to gate merges?

It can be flaky if you run it on shared, noisy infrastructure and fail on tiny score changes. Run against a stable staging environment, use 3–5 runs with the median, and gate on meaningful metric deltas (e.g., LCP regression >10% or >200ms). Teams keep Lighthouse gates enabled when failures are rare and actionable.

Should we test in CI or only in production with RUM?

Both. CI synthetic tests catch regressions before users see them and give fast feedback to engineers. RUM validates that your lab improvements actually move **real-user** LCP/INP/TTFB across device mixes and geographies. CI prevents bad changes; RUM proves business impact.

What’s the fastest way to start if we have zero performance testing today?

Pick one revenue-critical journey (usually checkout) and one backend endpoint. Add Lighthouse CI for that page and a k6 test for that endpoint. Store a baseline from `main`, gate PRs on regression thresholds, and iterate. One journey done well beats ten dashboards nobody trusts.

Performance-optimization · Jan 13, 2026 · 8 minute read

Your “Optimization” Didn’t Ship Until a Bot Failed the Build

Automated performance testing that guards user-facing metrics (LCP/TTFB/INP) and proves ROI—before your next release quietly adds 800ms to checkout.

Back to all posts

Your “Optimization” Didn’t Ship Until a Bot Failed the Build

Key takeaways

Implementation checklist