Cypress Performance Optimization

Where Cypress Suite Time Actually Goes

In most real suites, time is dominated by a small number of factors: repeated UI-driven setup (like logging in through the real form every test), real (unstubbed) network calls, and simply not parallelizing when the suite has grown large enough to benefit from it.

// Slow: full UI login repeated in every test
cy.visit('/login');
cy.get('[data-cy="email"]').type(...);
// ...

// Fast: cached session, set up once per run
cy.session('user', () => { cy.request('POST', '/api/login', ...); });

This single change, covered in depth in the cy.session() lesson, is often the single highest-leverage performance improvement available.

High-Leverage Performance Levers

1. cy.session() for authentication, instead of repeated UI logins
2. cy.intercept() to stub slow or unnecessary network calls
3. API-based setup instead of UI-driven setup
4. Parallelization once suite runtime becomes a real bottleneck
5. Removing unnecessary fixed waits

• Session caching alone often cuts significant time off suites requiring authentication.
• Stubbing slow, non-critical network calls removes real backend latency from most tests.
• API-based setup for preconditions is typically far faster than the equivalent UI steps.
• Fixed waits, if any remain, are pure wasted time that assertion-based waiting avoids entirely.

Performance Optimization Cheat Sheet

Common optimizations ranked by typical impact for most projects.

Finding Your Suite's Slowest Specs

Before optimizing broadly, identify which specific spec files or tests actually dominate total runtime, Cypress Cloud's analytics (if used) surface this directly, or you can review headless run output/timing logs manually for smaller suites.

• Review per-spec duration in cypress run output or Cypress Cloud analytics.
• Focus optimization effort on the small number of specs contributing disproportionate time.
• Re-measure after each change to confirm the optimization actually had the expected impact.

Avoiding Premature Optimization

Parallelization, elaborate caching layers, and infrastructure changes add real complexity. For suites still small enough to run in a few minutes, that complexity often isn't justified yet, simpler wins like cy.session() and reducing unnecessary UI steps usually go much further first.

Common Mistakes

• Reaching for parallelization or infrastructure changes before exhausting simpler, high-impact wins like session caching.
• Optimizing based on assumptions instead of measuring which specs actually dominate total runtime.
• Stubbing so aggressively that meaningful integration coverage is lost in pursuit of speed alone.
• Not re-measuring after an optimization to confirm it actually delivered the expected improvement.

Key Takeaways

• Repeated UI-driven setup, especially login, is often the single biggest, most fixable source of slowness.
• Stubbing non-critical network calls removes real backend latency from most feature-focused tests.
• Measure before optimizing, focus effort on the specs that actually dominate total runtime.
• Reserve parallelization and infrastructure changes for suites where simpler optimizations are already exhausted.