Optimizing Cypress for Faster Execution: Insights from Neocom

Overview

In Neocom, we operate two main front-end services undergoing testing with Cypress. Due to our startup nature, we experience frequent pushes, merges, and deployments, necessitating careful consideration of our CI speed and costs.

Cypress itself is a robust testing tool, but its weightiness imposes a load on requests.

NOTE: The timing discussed pertains solely to Cypress execution, excluding processes such as Docker builds and CI runs.

Integration tests

It's widely acknowledged that Integration tests can be slow, often due to factors like waiting, timeout testing, etc.

Sometimes, extensive testing on a specific page or component can contribute to slower tests.

Another factor affecting speed is the keyboard delay time of Cypress. Yes, you heard me right—if you have multiple inputs, this can consume considerable time.

Solutions

1. Initially, we set the keyboard delay to zero, which worked well for several months. However, for API search inputs, consider adding debounce to your API search input or introducing a delay to the Cypress write function. This led to a 10% speed improvement.

2. Running tests in parallel: While Cypress itself offers parallel execution, it comes with a cost. We opted for the Cypress Parallel library, resulting in significant speed improvements:

Service 1: 06:05 mins => 03:47 mins (37.7% faster)
Service 2: 04:25 mins => 01:36 mins (63.77% faster)

HTTP 1.1

Cypress proxy and local frontend development servers use HTTP 1.1. Browsers, however, have a limit of max 6 connections to the same origin, impacting the speed of requests.

For instance, if you use ES Module and have nearly 200 components to load, the browser can only make 6 requests simultaneously. This sequential loading can result in significant time delays.

Solution

As Cypress proxy doesn't support HTTP 2, and local dev servers typically lack HTTP2 support, we addressed this by bundling less. For example, with Rollup (Vite build), using manualChunks to export code into a few JS Modules improved speed. Example configuration:

import { defineConfig } from "vite"

export default defineConfig({
  .......
  build: {
    rollupOptions: {
      output: process.env.TESTING && {
        manualChunks: () => "index.js",
      },
    },
  },
  .......
})

Results may vary based on Cypress request volume, with more noticeable improvements on the CI.

How about your experiences with Cypress speed? What strategies have you employed to enhance it?