Cypress 16: Faster Test Startup with HTTP/2 Support

Cypress 16.0.0, released September 1, 2026, changes how Chrome, Chromium, and Edge send application traffic during tests: the browser connects directly to your server and negotiates the protocol the server supports, including HTTP/2 and HTTP/3. That can reduce queuing on request-heavy pages, but it is not a universal startup-speed guarantee. Firefox, WebKit, and Electron remain on Cypress’s legacy network path.

This guide explains the networking change, how to upgrade and check its effects, what to measure in your own suite, and how to diagnose common migration issues. Cypress’s release notes do not report a quantified whole-suite startup or runtime improvement.

1. What changed in Cypress 16

Before Cypress 16, Cypress routed application requests through a legacy network path that supported HTTP/1.1. In Chrome, Chromium, and Edge, Cypress 16 uses native browser networking by default. The browser connects to the application server and negotiates HTTP/1.1, HTTP/2, or HTTP/3 according to what the server supports.

HTTP/2 and HTTP/3 can multiplex requests over one connection. This can help a page that makes many requests avoid queuing behind the former six-connection-per-origin ceiling associated with the old path. The size of any improvement depends on your application, server, browser, test setup, and network conditions.

Cypress describes the production-fidelity difference this way: “Your application connects to your server directly and negotiates whatever protocol the server supports, exactly as it does in production.” See the official Native Network Interception guide.

2. Browser and protocol support

Browser	Cypress 16 network path	What to expect
Chrome	Native by default	Negotiates the protocol supported by the server: HTTP/1.1, HTTP/2, or HTTP/3.
Chromium	Native by default	Same native-network behavior as Chrome.
Edge	Native by default	Same native-network behavior as Chrome and Chromium.
Firefox	Legacy	Does not receive the Cypress 16 native-network change.
WebKit	Legacy	Does not receive the Cypress 16 native-network change.
Electron	Legacy	Electron remains on the legacy path and is deprecated as a test browser; plan a move to an installed browser.

HTTP/2 support in Cypress does not mean every test uses HTTP/2. The app server and the connection must support and negotiate it. HTTP/3 is also available on the native path when supported. Check the browser’s negotiated connection and the server configuration when protocol behavior matters.

3. Upgrade and verify your setup

Read the Cypress migration guide for the changes between your current version and 16.0.0. Cypress 16 requires Node.js 22.x, 24.x, or 26.x and above; Node.js 20 and 25 are no longer supported.
Upgrade Cypress using the package manager already used by your project. For example, with npm:
```
npm install --save-dev cypress@16
```
Run a representative set of tests in Chrome, Chromium, or Edge, especially tests with many network requests, intercept assertions, caching, or compressed responses.
Run your cross-browser checks separately. Firefox and WebKit continue to use the legacy network path, so do not infer their behavior from a Chrome run.
Review failures in assertions that depend on transport details. Prefer checks of application behavior and decoded response content when the test does not need to verify a particular network-layer property.
Compare timings on the same machine and test selection before and after the upgrade. Repeat runs and compare distributions; do not treat one run as a release-wide performance result.

The migration guide also lists removed APIs and options, including Cypress.env(), cy.end(), and cy.exec(), as well as other behavior changes. Consult it for the specific replacements and migration steps relevant to your codebase.

4. What may change in network assertions

cy.intercept() keeps its familiar API, and many suites will not need edits. Some values observed by intercepts differ because the browser owns the connection. Audit tests that assert on:

req.httpVersion or other transport-level properties.
Compression-related headers, which are not reported as before.
Responses the browser rejects before delivering them to Cypress; Cypress cannot observe those responses in the same way.
Stubbed responses and browser caching, whose behavior differs on the native path.
Revalidated cached responses: a response may appear as 200 rather than 304.

When the purpose of a test is to verify user-visible behavior, assert the resulting page state or decoded response body rather than an incidental protocol detail. When you specifically need to verify headers, caching, or a transport outcome, follow the relevant examples in the native networking guide and make the expected browser path explicit.

5. How to measure the effect on your suite

Cypress 16’s network change can reduce queuing on request-heavy pages, but it does not promise a fixed reduction in test startup or suite duration. Cypress’s release and performance pages reviewed for this guide provide no quantified aggregate startup gain.

Choose a stable, representative test group. Include a request-heavy flow if that is where you expect a difference.
Keep the machine, browser version, app server, test data, and parallelization settings consistent.
Measure test startup separately from application navigation and the full suite. This helps distinguish browser initialization from page-request changes.
Repeat runs and compare medians or distributions. Record browser and negotiated protocol alongside timings.
Look for a bottleneck before attributing a change to HTTP/2: server response time, test setup, fixture work, retries, and rendering can dominate.

Cypress’s performance guidance also covers test-level practices. Cypress 16’s release summary lists faster visibility checks, removal of cy.type()’s implicit 10 ms keystroke delay, retry behavior for cookie and storage commands, and browser memory management enabled by default. These are separate changes; the keystroke-delay change is not an overall suite-speed statistic. See Optimizing Test Performance.

6. Troubleshooting

Symptom	Likely cause	What to do
A test expects HTTP/2 but reports HTTP/1.1.	The server, browser, or connection did not negotiate HTTP/2; native networking permits negotiation but does not force a protocol.	Confirm the server supports HTTP/2 and inspect the actual browser connection. Check that the test uses Chrome, Chromium, or Edge.
A transport assertion fails after the upgrade.	Native networking changes which connection details and headers Cypress observes.	Review assertions on `httpVersion` and compression headers. Assert on application outcomes unless the transport itself is under test.
An intercept does not see a browser-rejected response.	The browser rejected the response before Cypress received it.	Investigate the browser’s network error and server response. Cypress cannot inspect a response the browser rejected before delivery.
A cache test expects 304 but sees 200.	A revalidated response can appear as 200 on the native path.	Check the resulting content and cache behavior rather than relying only on the status code. Use the native-network guide for case-specific expectations.
A Firefox or WebKit run behaves differently from Chrome.	Those browsers still use the legacy path.	Diagnose by browser and keep browser-specific network expectations separate.
Cypress fails to run under the project’s Node.js version.	The runtime is outside the supported versions listed for Cypress 16.	Use Node.js 22.x, 24.x, or 26.x and above, and review the migration guide for other upgrade requirements.
Electron results do not match Chrome results.	Electron uses the legacy network path and is deprecated as a test browser.	Plan to test with an installed browser and use the browser matrix to interpret current results.
Suite duration changes but page requests do not explain it.	Other Cypress 16 changes, test setup, machine load, retries, or application work may affect timing.	Measure startup, navigation, and suite duration separately, then compare repeated runs under consistent conditions.

7. Performance, reliability, and cost considerations

Performance: Native networking can make request-heavy pages more efficient when the server negotiates HTTP/2 or HTTP/3. There is no official release-wide startup percentage to apply to your suite; benchmark the workflows that matter.

Reliability: The browser now validates the application certificate on the native path, and stubbed or modified traffic appears in the browser’s network panel. That is closer to how the browser connects in production, while also changing what Cypress can observe for rejected responses, caching, and transport headers. Validate those cases during migration.

Cost: The cited Cypress release and guide material does not establish a Cypress 16-specific price change. For test infrastructure, measure the actual runtime and compute or CI usage in your environment rather than assuming the protocol change will reduce cost.

8. Or skip the browser setup

If your task is to capture a page as an image or PDF rather than run an end-to-end test, ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. It is the alternative to try first when you need clean captures: consent banners, newsletter popups, and chat widgets are removed before the shot, and only clean shots are billed.

For a runnable cURL example, see the ScreenshotNeo API docs. Replace the URL with the page to capture and supply your API key:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, no card required.

9. FAQ

Does Cypress 16 force HTTP/2?

No. On the native path, the browser negotiates the protocol supported by the server. HTTP/1.1 remains possible.

Will every Cypress browser test become faster?

No. Native networking applies by default to Chrome, Chromium, and Edge. Firefox, WebKit, and Electron remain on the legacy path, and speed depends on the application and test environment.

Should I keep using `forceHttp1`?

Cypress documents it as a temporary, deprecated compatibility option that sends browsers through the legacy path. Treat it as a migration or issue workaround, not a lasting performance setting.

Does Cypress 16 provide a published startup benchmark?

The official release and performance material cited here does not publish a quantified aggregate startup gain. Measure your own suite with repeated, controlled runs.

Does ScreenshotNeo replace Cypress?

No. Cypress runs browser tests; ScreenshotNeo captures a page as an image or PDF through an API or MCP server.

Sources

Cypress App Changelog — Cypress 16.0.0 release entry, dated September 1, 2026.
Native Network Interception — protocol behavior, browser coverage, intercept differences, and forceHttp1.
Upgrade Cypress: Version Migration Guide — runtime requirements and breaking changes.
Optimizing Test Performance — test performance guidance.