Performance Benchmarks of Playwright, Cypress, and Selenium in 2026

Every testing framework claims to be fast.

But when your CI pipeline takes 90 minutes, and half the failures are flaky, claims don't matter. Numbers do.

Playwright, Cypress, and Selenium are the three frameworks that dominate E2E testing in 2026.

The performance gap between these frameworks is real and measurable. It shows up in CI build times, cloud infrastructure costs, developer wait times, and how often your team reruns a "failed" test that was never actually broken.

But raw speed is only part of the picture. Execution consistency, flakiness rates, memory consumption, parallel execution throughput, and CI cost all matter when choosing between these three frameworks. A framework that's 20% faster but twice as flaky doesn't save you anything.

This article collects every credible, reproducible benchmark we could find and lets the numbers speak. For a broader look at framework adoption trends beyond performance, see the linked guide.

Benchmark 1: Raw Execution Speed

The most cited data comes from the Axelerant study, which ran identical test scenarios across all three frameworks:

In throughput terms, that translates to roughly:

• Playwright: ~1,240 tests/hour

• Cypress: ~857 tests/hour

• Selenium: ~670 tests/hour

The Checkly benchmark (1,000 runs against a production web app) confirmed the pattern:

• Playwright: Fastest in real-world E2E scenarios, with the lowest execution time variability

• Cypress: ~23% slower than Playwright in production tests, but the gap narrows for suites vs single tests

• Selenium (via WebDriverIO): Slowest, with the highest execution time variability

Tip: The gap between Cypress and Playwright narrows for suite execution vs single tests. In Checkly's three-test suite scenario, Cypress was only ~3% slower than Selenium but still 23% behind Playwright. This is because Cypress adds ~5-7 seconds of startup latency before any test logic begins, which amortizes across longer suites.

Benchmark 2: Scaling to 100 Tests

Single-test benchmarks can be misleading. What matters in CI is how frameworks perform at scale. The ray.run benchmark tested this by running the same test 1x, 10x, and 100x:

Test 1 (single run), relative to fastest:

Test 2 (10 runs), relative to fastest:

Test 3 (100 runs), relative to fastest:

Two patterns stand out:

• Playwright consistently wins at scale, and the gap grows as the test count increases

• Cypress improves dramatically from 350% to 126% as its startup cost amortizes

• Selenium gets relatively worse at scale (from 166% to 149%, but still behind)

Tip: If you're evaluating frameworks with a 5-test proof-of-concept, Cypress's startup penalty will make it look disproportionately slow. Run at least 50+ tests in your evaluation to get realistic numbers. For Playwright sharding strategies that maximize parallelism, see the linked guide.

Tip: If you're evaluating frameworks with a 5-test proof-of-concept, Cypress's startup penalty will make it look disproportionately slow. Run at least 50+ tests in your evaluation to get realistic numbers. For Playwright sharding strategies that maximize parallelism, see the linked guide.

Benchmark 3: Resource Usage (CPU and Memory)

This is where the differences get expensive. Framework architecture directly determines how much hardware you need.

The memory gap comes from how each framework handles browser instances. Selenium spawns one full browser per test session. Cypress uses one browser per suite, but adds its own proxy and bundling overhead. Playwright shares a single browser process across multiple lightweight contexts.

At scale, these differences compound. One study found that running 5,000 tests/day required:

• Selenium: 32 runner-hours/day

• Playwright: 16 runner-hours/day (50% fewer CI minutes)

In cloud CI pricing, that 50% reduction can translate into thousands of dollars in annual savings.

Most benchmarks only test Chromium. But real-world suites run across browsers. The ray.run cross-browser analysis measured Playwright's performance across all supported engines:

• Chromium is consistently fastest for Playwright tests

• Firefox is the slowest, especially in headed mode on VMs (+70.8%)

• Headed vs headless gap: ~15% locally, but nearly zero on VMs

• WebKit performance varies wildly between local and VM execution

This matters for teams running cross-browser matrices. If your CI pipeline runs all three browsers, Firefox will be your bottleneck. Plan shard allocation accordingly.

Benchmark 5: Architecture and Why Speed Differs

The performance gaps aren't random. They're built into how each framework communicates with browsers.

Cypress runs tests inside the browser itself. Direct DOM access makes debugging excellent, but the trade-off is:

Startup overhead (~5-7 seconds to bundle, inject, and proxy)

• Single-tab, single-origin execution limits

• JavaScript/TypeScript only

Selenium communicates over HTTP to a separate WebDriver process. Each step involves a four-hop round-trip:

• Test code sends HTTP request to WebDriver

• WebDriver translates to browser command

• Browser executes and returns response

• WebDriver sends HTTP response back

Tip: Selenium 4.x introduced BiDi (bidirectional) protocol support to reduce this overhead. If you're benchmarking Selenium, make sure you're using Selenium 4+ with BiDi enabled. One independent analysis described Selenium as "the historical source of flakiness" due to its protocol overhead, while noting Playwright "combines the best of both" Cypress speed and Selenium flexibility.

Benchmark 6: Flakiness and Consistency

Speed means nothing if results aren't consistent. Teams spend 40-50% of E2E testing effort just on maintenance (fixing broken tests), regardless of framework.

Playwright tests tend to be most stable because its high-speed protocol and built-in locator strategies produce the highest consistency in run times. Cypress improved reliability with built-in retries, but complex asynchronous apps can still cause occasional random failures. Selenium is historically the most brittle: user surveys consistently cite timing and asynchronous handling as top pain points.

This is where flaky test detection becomes a performance concern. A framework that runs 20% faster but generates 3x more retries ends up slower in total pipeline time.

See which tests flake the most in your suite

TestDino tracks flakiness rates, retry patterns, and duration trends automatically

Start free Start free

Benchmark 7: Parallel Execution Throughput

Parallelization is the single biggest performance lever in CI. Here's how the three frameworks handle it:

Playwright's browser context isolation is the key differentiator. Multiple contexts share a single browser process, meaning you can run 2-3x more tests simultaneously on the same hardware than with Selenium Grid.

One case study showed 60% faster CI runs on 8 machines after migrating from Selenium to Playwright, driven primarily by the advantage of parallelism.

Note: Cypress added limited free parallelism in recent versions, but production-scale parallel execution still requires Cypress Cloud. For teams running 100+ parallel tests, the infrastructure cost model matters as much as raw speed.

The Consolidated View

Here's everything in one table:

Tip: Selenium's npm package only captures JavaScript usage. Its Java and Python ecosystems (Maven, PyPI) are massive and not reflected here. For the full adoption picture, see the Playwright market share analysis.

How TestDino Helps After You Choose a Framework

Choosing a framework based on benchmarks is step one.

Keeping your suite fast over months is a harder problem.

Test suites accumulate slow specs, flaky tests, and gradually worsening CI times. TestDino provides the monitoring layer that benchmarks can't:

For teams migrating from Selenium or Cypress to Playwright, TestDino's GitHub integration posts AI-generated test summaries directly to PRs and commits. The Trace Viewer integration lets you debug failures with Playwright's built-in trace files without leaving the TestDino dashboard.

These benchmarks proved Playwright is faster

Now prove your suite stays fast. TestDino tracks every run, every spec, every trend

Try TestDino Try TestDino

What This Means for Your Team

1. Playwright is the fastest framework in every benchmark we reviewed. The advantage ranges from 1.45x faster than Cypress to 1.85x faster than Selenium per action. At scale, the gap holds or widens.

2. Resource efficiency is Playwright's hidden advantage. Using 50-60% less memory per test and supporting 2-3x more parallel tests on the same hardware means fewer CI runners and lower cloud costs.

3. Cypress's startup penalty is real but manageable. For test suites (not single tests), Cypress closes much of the speed gap. If your team values its debugging experience, the trade-off may be acceptable for smaller suites.

4. Selenium's speed disadvantage is architectural. The HTTP-based WebDriver protocol adds latency to every action. Selenium 4's BiDi protocol helps, but can't fully close the gap against WebSocket-native frameworks.

5. Consistency matters more than peak speed. Playwright's lowest execution time variability means fewer surprise timeouts and retries. This reduces total pipeline time more than raw speed alone.

6. Parallel execution is the bigger lever. The difference between 4 workers and 30 workers dwarfs the per-test speed difference between frameworks. Invest in parallelization before obsessing over framework switching.

FAQs

Pratik Patel

Founder & CEO

Pratik Patel is the founder of TestDino, a Playwright-focused observability and CI optimization platform that helps engineering and QA teams gain clear visibility into automated test results, flaky failures, and CI pipeline health. With 12+ years of QA automation experience, he has worked closely with startups and enterprise organizations to build and scale high-performing QA teams, including companies such as Scotts Miracle-Gro, Avenue One, and Huma.

Pratik is an active contributor to the open-source community and a member of the Test Tribe community. He previously authored Make the Move to Automation with Appium and supported lot of QA engineers with practical tools, consulting, and educational resources, and he regularly writes about modern testing practices, Playwright, and developer productivity.

View all posts →