← Lessons

quiz vs the machine

Platinum1860

Frontend

Performance Testing In CI

Track bundle size and metrics to stop regressions before merge.

5 min read · advanced · beat Platinum to climb

Guarding speed in the pipeline

Performance degrades one small change at a time. Performance testing in CI measures key metrics on each pull request and fails or warns when they regress past a budget, so slowdowns are caught before users feel them.

What to measure

  • Bundle size of key entry points, with a budget per chunk.
  • Lab metrics like load and interactivity timings from an automated audit.
  • Render counts for hot components in interaction tests.

Making it trustworthy

  • Run on consistent hardware since lab numbers vary with the machine.
  • Compare against the base branch, not absolute thresholds, to reduce noise.
  • Average multiple runs to smooth variance.

Acting on results

  • Block merges that break a hard budget like a bundle size cap.
  • Post a comment with the metric delta so reviewers see the impact.

Budgets turn performance from a vague goal into an enforced contract.

Key idea

Measure bundle size and metrics per pull request against budgets so performance regressions are caught before merge.

Check yourself

Answer to earn rating on the learn ladder.

1. Why compare performance against the base branch rather than absolute thresholds?

2. What is a hard budget that justifies blocking a merge?