Performance Testing Patterns

Scope

This skill covers performance TESTING methodology -- how to measure, validate, and gate performance at the system level. For code-level performance issues (algorithmic complexity, memory leaks, rendering, bundle size), see performance-reviewer. For API endpoint-level thresholds (p95 response time, error rate per endpoint), see api-testing-patterns.

When to Use Each Test Type

• Load test every release that has performance SLAs
• Stress test before capacity planning decisions -- find the breaking point
• Endurance (soak) test before major releases and after architecture changes -- detect memory leaks and degradation
• Spike test systems with unpredictable traffic patterns -- validate burst handling
• Scalability test before auto-scaling configuration -- measure performance delta as resources scale

Core Web Vitals

Measure at the 75th percentile of page loads, segmented by device type.

System-Level Performance Budgets

Define as CI/CD quality gates:

• Bundle size budget: maximum JS/CSS payload per route
• Load capacity budget: minimum traffic multiplier the system must handle (starting point: 3x normal peak)
• Page load budget: maximum time to interactive (starting point: LCP target above)

Budgets are project-specific. The values above are starting points for discussion, not mandates. For API endpoint-level thresholds (p95 latency, error rate), see api-testing-patterns.

Statistical Rigor

• Establish baseline performance BEFORE optimization
• Use percentiles (p50, p95, p99), not averages
• Require confidence intervals for performance claims (minimum 95% CI)
• Always compare before/after with the same test conditions
• Run tests long enough for statistical significance (minimum 5 minutes sustained load)
• Account for warm-up effects -- exclude initial ramp-up from measurements

RUM vs Synthetic Testing

Use both: synthetic for gatekeeping, RUM for truth.

• Synthetic (lab): CI/CD gates, regression detection, SLA validation
• RUM (field): Real-world performance, device/network variance

Performance Test Coverage Assessment

When reviewing test coverage, check:

• Are critical user journeys covered by load tests?
• Do performance tests run in CI/CD (not just manually)?
• Are thresholds defined and enforced (not just measured)?
• Is there endurance testing for long-running services?
• Are performance baselines documented and tracked over time?