Playwright vs Cypress, decided rather than described

Architecture explains almost every difference

Cypress runs your test code inside the browser, in the same event loop as the application. That is precisely why the interactive runner can show you the DOM at every command, and precisely why cross origin navigation, extra tabs and iframes are hard. The browser security model that protects users is the same model that constrains a test running inside the page.

Playwright sits outside the browser and drives it over a protocol. That costs you the in page intimacy, and buys multiple independent contexts, unrestricted navigation, popups as ordinary objects, and a recording of everything the browser did that can be replayed afterwards.

When you evaluate these tools, do it on the awkward flows rather than the happy path. Log in through your real identity provider, open the flow that spawns a tab, exercise the embedded payment iframe. Both tools handle a form and a table well. The differences show up exactly where your hardest tests live.

Parallelism is where the budget goes

A suite that takes forty minutes serially and eight minutes across five workers is a different tool in practice, because developers wait for it rather than routing around it. Playwright gives you workers and shards with no licence attached, so scaling out is a CI compute decision.

Cypress can run specs concurrently, but balanced distribution and result aggregation come from Cypress Cloud or from a self hosted service such as Currents or Sorry Cypress. That is a legitimate model, and for many teams the dashboard earns its cost. It does mean the cost of your suite grows with how often you run it, which is the opposite of the incentive you want when encouraging developers to run tests more.

Model this before choosing. Take your expected test count, multiply by runs per day across branches and main, and price it. Teams are regularly surprised, and the surprise usually arrives a year in, when the suite is large enough that switching is expensive.

Two different answers to debugging

Cypress optimises the moment of writing. You watch commands execute, hover a step, see the DOM as it was. Nothing else is quite as good for building a test quickly.

Playwright optimises the moment of failure. A trace from a CI run opens locally with the DOM at each step, network activity, console output and the source line, which turns the usual "cannot reproduce" conversation into a five minute investigation.

Which matters more depends on where your pain is. If tests are hard to write, Cypress helps. If tests are hard to trust, Playwright helps. Most teams past their first hundred tests discover their pain has shifted from writing to trusting.

What a fair speed comparison looks like

Published benchmarks on trivial suites are close to meaningless. Both tools spend most of their wall clock waiting for your application, and the gap between them is smaller than the gap between a well written suite and a careless one.

If you want a real number, port ten of your own tests to both, including the two that flake most, and run each twenty times in CI at the concurrency you would actually pay for. Compare the median, the worst case, and the number of reruns needed to get a green build. That last figure is the one that predicts whether people will trust the suite.