Cypress 16: HTTP/2 Support Makes Your Tests Match Production Reality • tooniezland

The Protocol Gap That Slowed Your Tests

For years, Cypress ran your application over HTTP/1.1 in the browser while your users experienced HTTP/2 in production. The reason was architectural: Cypress sits between the browser and your servers, proxying every request so cy.intercept() can observe and modify traffic. When that proxy was built, HTTP/1.1 was the standard. The web moved on—today the overwhelming majority of production traffic is HTTP/2—but Cypress tests didn’t.

Cypress 16 closes that gap. Requests now use HTTP/2 whenever the server supports it, in Chromium-based browsers (Chrome, Chromium, Edge), with zero changes to your tests.

Why HTTP/2 Matters for Test Speed

Multiplexing Eliminates the Queue

HTTP/1.1 limits browsers to six parallel connections per domain. A request-heavy page—hundreds of images, API calls, chunks from a Vite dev server—queues behind that ceiling. HTTP/2 multiplexes many requests over a single connection.

In the Cypress team’s benchmark loading 1,000 images:

HTTP/1.1: 3,896 ms
HTTP/2: 1,362 ms

That’s a 65% reduction purely from protocol upgrade. If your pages fire many small requests, especially through a dev server, you should feel the difference in open mode and in CI.

// cypress/e2e/dashboard.cy.js
// This test now runs over HTTP/2 automatically
// No code changes required

describe('Dashboard loads efficiently', () => {
  it('fetches all widgets in parallel over HTTP/2', () => {
    cy.intercept('/api/widgets/**', { fixture: 'widgets.json' }).as('widgets')
    cy.visit('/dashboard')
    cy.wait('@widgets')
    
    // Before Cypress 16: these 20 widget requests queued behind 6 connections
    // Now: they multiplex over a single HTTP/2 connection
    cy.get('[data-testid="widget"]').should('have.length', 20)
  })
})

Streaming Features Become Testable

Over HTTP/1.1, browsers cap Server-Sent Events at six connections per domain. That limit put upload progress indicators, live notifications, and activity feeds effectively out of reach for reliable testing.

Over HTTP/2, the number of concurrent streams is negotiated with the server and defaults to 100. If you gave up on testing a streaming workflow, it’s worth another look.

// cypress/e2e/streaming.cy.js
// Testing SSE progress updates—now reliable with HTTP/2's 100 concurrent streams

it('displays real-time upload progress', () => {
  cy.visit('/upload')
  cy.get('input[type="file"]').selectFile('fixtures/large-video.mp4')
  
  // SSE connection no longer competes with the 6-connection HTTP/1.1 limit
  cy.intercept('/api/upload/progress*').as('progress')
  
  cy.get('[data-testid="progress-bar"]').should('be.visible')
  
  // Wait for multiple progress events over the same HTTP/2 connection
  cy.wait('@progress').then(({ response }) => {
    expect(response.body.percent).to.be.greaterThan(0)
  })
})

Opting Out When You Need To

This is a big change. If you encounter issues—corporate proxies that mishandle HTTP/2, servers with broken HTTP/2 implementations—you can opt out per test or globally:

// cypress.config.js
export default defineConfig({
  e2e: {
    // Global opt-out
    // forceHttp1: true, // Commented out by default
  }
})

// Per-test opt-out
it('works with legacy proxy', { forceHttp1: true }, () => {
  cy.visit('/legacy-app')
  // Test runs over HTTP/1.1
})

Beyond HTTP/2: The Other Performance Wins in Cypress 16

HTTP/2 is the headline, but Cypress 16 attacks test slowness from multiple angles. Most of these arrive without editing a single test.

Typing at Full Speed

The default keystroke delay for cy.type() is now 0 ms. Previously it was 10 ms to simulate human typing. For a suite with hundreds of form tests, this adds up.

// Before: cy.type('hello') took ~50ms for 5 characters
// After: cy.type('hello') takes ~0ms

// If your app genuinely depends on inter-keystroke timing (aggressive debouncing, re-render on every keystroke):
cy.get('input').type('slow typing', { delay: 10 })

// Or globally:
Cypress.Keyboard.defaults({
  keystrokeDelay: 10
})

Faster Visibility Checks

The legacy visibility algorithm walked up the ancestor tree reading CSS at each level, triggering layout recalculation. The new default uses the browser’s built-in visibility check first, then confirms with adaptive point sampling.

// cypress.config.js
// Opt back into legacy if you need migration time
export default defineConfig({
  e2e: {
    visibilityStrategy: 'legacy' // default is now 'modern'
  }
})

Memory Management On by Default

Since 12.4, experimentalMemoryManagement cleared memory between tests in Chromium. It worked well but most teams never found the experimental flag. In 16 it’s stable, renamed to manageBrowserMemory, and on by default.

// cypress.config.js
// You probably don't need to touch this
export default defineConfig({
  e2e: {
    manageBrowserMemory: true // default
    // Set to false only if your light suite pays overhead without benefit
  }
})

With this enabled, Cypress monitors renderer memory during a run and triggers garbage collection before the browser runs out—the difference between a long spec finishing and “We detected that the Chrome Renderer process just crashed.”

Fewer Flaky Cookie/Storage Reads

Reading a cookie set asynchronously after a redirect could miss it by milliseconds and fail. In 16, cy.getCookie(), cy.getCookies(), cy.getAllCookies(), cy.getAllLocalStorage(), and cy.getAllSessionStorage() are query commands. Chained assertions re-read and retry until they pass.

// Before: race condition possible
cy.getCookie('session_id').should('exist') // Could fail if cookie not yet set

// After: retries automatically like cy.get()
cy.getCookie('session_id').should('exist') // Waits for cookie to exist

One less race, one less reason for a green suite to go red for no good reason.

A Faster Foundation

Cypress 16 moves onto Node.js 24, Chromium 146, Electron 41, Vite 8, and Angular 21/22. Each brings its own performance work your tests inherit for free. Several long-deprecated APIs and experiments (experimentalSourceRewriting) are gone.

Secrets Stay Out of the Browser

Cypress.env() has been removed. It hydrated every configured environment variable into the browser—meaning a single secret in your environment was readable by application code, third-party scripts, and any cross-origin context your test entered.

Cypress 16 splits this into two APIs with different guarantees:

// cypress/e2e/auth.cy.js

// Sensitive values: read asynchronously, kept in Node process
// Only the keys you request cross into the test
const apiKey = await cy.env('STRIPE_SECRET_KEY')
cy.request({
  url: '/api/charges',
  headers: { Authorization: `Bearer ${apiKey}` }
})

// Non-sensitive values: published for synchronous access
// Feature flags, public API base URLs
Cypress.expose('FEATURE_NEW_DASHBOARD', true)
Cypress.expose('API_BASE_URL', 'https://api.example.com')

// In your test:
if (Cypress.expose('FEATURE_NEW_DASHBOARD')) {
  cy.visit('/dashboard/new')
}

The env key is no longer accepted in per-test or per-suite configuration overrides, and the allowCypressEnv option is removed.

Breaking Changes Checklist

Removed	Replacement
Electron browser	Deprecated (warns, still works); migrate to Chrome/Edge
`cy.exec()` / `execTimeout`	`cy.task()`
`cy.end()`	Delete `.end()` calls
`viewportWidth`/`viewportHeight`/`blockHosts` via `Cypress.config()`	Set in test config: `it('test', { viewportWidth: 1280 }, () => {})` or `cy.viewport()`
CoffeeScript support	—
Angular 18–20, Vite 5–7, Next.js 14 (Component Testing)	Upgrade to Angular 21/22, Vite 8, Next.js 15/16

Upgrading: Let AI Do the Heavy Lifting

The Cypress 16 migration guide includes a ready-made prompt you can paste into any AI coding assistant (Claude Code, Cursor, Copilot):

“Upgrade this project to Cypress 16. Check Node version and framework requirements, update the dependency, find code that needs to change, apply fixes, and run tests.”

It works through the upgrade with you—checking your Node version and framework requirements, updating the dependency, finding the code that needs to change. Review what it does and commit.

Not on the latest Cypress 15? Catch up first. Every major from 10 forward has a migration prompt in the guide. One major at a time until you land on the latest.

The Bottom Line

Cypress 16 isn’t a single feature—it’s a suite of changes that collectively make your test suite faster, more realistic, and more secure. HTTP/2 support is the most visible: your tests now speak the same protocol as your users. But the typing speedup, visibility algorithm, memory management, and cookie retries all compound.

If your suite is slow because of request-heavy pages, lots of typing, many visibility assertions, or long runs hitting memory pressure, upgrade. If it’s slow because of long waits, repeated UI logins, or real network calls, the test performance guide is still the place to start.

npm install cypress@16 --save-dev
# or
pnpm add -D cypress@16

Then paste the migration prompt into your AI assistant and let it handle the grind.