Cypress Tests Slow? How to Speed Up Cypress

If your Cypress tests are slow, you can usually speed up Cypress by logging in programmatically, removing fixed waits, running a built app, and splitting specs across parallel jobs. This guide covers each fix and shows Cypress parallel tests in GitHub Actions, with and without Cypress Cloud. It is part of the slow e2e tests guide.

Why Cypress is slow

Cypress runs one spec at a time per process, in a single browser, and a spec file reloads the app for each test. Two things multiply: a long login or setup in beforeEach, and fixed cy.wait(ms) calls. Before changing anything, record which specs are the slowest. The Cypress run summary prints a duration per spec; sort by it.

Fix 1: log in without the UI

Use cy.session to log in once per spec run and restore the cookies and storage afterwards, and use cy.request for the login call itself instead of typing into a form:

Cypress.Commands.add("login", (email: string, password: string) => {
  cy.session([email], () => {
    cy.request("POST", "/api/login", { email, password });
  });
});

Create test data the same way: cy.request to an API endpoint or cy.task to seed the database, not clicking through forms.

Fix 2: remove fixed waits

cy.wait(5000) costs 5 seconds every time. Cypress retries assertions automatically, so assert on the outcome. When you must wait on a network call, alias it with cy.intercept and wait on the alias:

cy.intercept("GET", "/api/orders*").as("orders");
cy.visit("/orders");
cy.wait("@orders");
cy.get("[data-cy=order-row]").should("have.length.at.least", 1);

Stub slow third-party calls (maps, analytics, payments sandbox) with cy.intercept so tests do not depend on them.

Fix 3: run against a production build

A dev server compiles on demand, so the first visit to each route is slow. In CI build once, serve the build and run Cypress against that. With the official action, build and start steps run for you:

- uses: cypress-io/github-action@v6
  with:
    build: npm run build
    start: npm run start
    wait-on: "http://localhost:3000"

Fix 4: split big specs and test the right thing

Long specs with 40 tests are hard to parallelise. Keep specs focused, and push logic checks down to unit or component tests. Cypress component testing runs components without a full app load and is much faster for UI states. See unit tests vs e2e tests.

Cypress parallel tests in GitHub Actions

Option A: Cypress Cloud

Cypress Cloud balances specs across machines using historical timing. You need a record key and the same build ID on every machine; the official action handles that:

jobs:
  cypress:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        containers: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v4
      - uses: cypress-io/github-action@v6
        with:
          build: npm run build
          start: npm run start
          record: true
          parallel: true
          group: e2e
        env:
          CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Cypress Cloud is a paid service with a free tier; check its current limits on its own pricing page.

Option B: split specs yourself, no Cloud

The open source cypress-split plugin splits spec files across a matrix using environment variables. Configure it in cypress.config.ts, then pass the job index and total:

strategy:
  fail-fast: false
  matrix:
    index: [0, 1, 2, 3]
steps:
  - uses: cypress-io/github-action@v6
    with:
      build: npm run build
      start: npm run start
    env:
      SPLIT: 4
      SPLIT_INDEX: ${{ matrix.index }}

Check the plugin README for the exact setup on your Cypress version. Splitting by file count is not time-balanced, so put the slowest specs in separate files. The test sharding guide explains balancing, and the planner estimates the shard count and cost.

Install and cache correctly

Cache the npm cache and the Cypress binary (~/.cache/Cypress). The official action does both for you. Use npm ci, not npm install. If your job downloads the Cypress binary on every run, the log will show it; fix that first.

Use more CPU

Cypress runs a browser plus your app on one machine, and a 2-vCPU runner can be the bottleneck, which causes timeouts that look like flaky tests. Compare more cores with faster GitHub Actions runners. compiler.dev was faster than GitHub's 2-core runner on 15 of 19 benchmarked stacks, by 1.1 to 3 times, and comparison mode measures your own jobs. Related: Playwright tests slow, flaky e2e tests and the slow CI hub.

FAQ

How do I speed up Cypress?

Log in with cy.session and cy.request, remove fixed waits, test a production build, and run specs in parallel across several jobs.

Can I run Cypress parallel tests without Cypress Cloud?

Yes. Split spec files across a matrix with a plugin such as cypress-split, or write your own script that assigns spec files to a job index. You lose automatic time-based balancing.

Why are my Cypress tests slower in CI?

CI runners are smaller and start cold. Check CPU use, the binary download and whether you are running against a dev server.

Is Cypress slower than Playwright?

It depends on the suite. Both are fast when set up well; compare on your own tests and see Playwright tests slow for its equivalents.