← Back to Discord Forum

Playwright vs. Cypress 12 Performance Testing

Hey all! I'm currently doing an in depth research for my company whether or not to switch from Cypress 12 to Playwright.

My question pertains to the area of speed/load testing by looking at how well can both automation frameworks iterate through an n number of rows in a table. Currently, we are starting with 1 row and increase the number of rows by a magnitude 10. Therefore, we will have test cases for 1 row, 10 rows, 1000 rows, to 10000 rows in a table. After looking online Cypress notorious memory hog, I managed to get Cypress framework test with disabling their command window log via command line and increase the timeout to 10 minutes and and able to iterate and validate through 100000 rows in a table. Is there something similar on Playwright's side that I can look up and do to increase playwright's speed?

Note: Added screenshot for reference and the simple Cypress project to use to reproduce the test run (Please ignore the README.md file and just do "npm install" to install the necessary packages):


This thread is trying to answer question "Is there something similar on Playwright's side that I can look up and do to increase playwright's speed?"

7 replies

Playwright is fast as it is, I don't think there's anything you can do to increase speed even more. However, you might see memory hogging as well. I can't find an issue now but if I remember correctly, Playwright releases memory only on closing browser context so if you'll do long living test (10 min in your example) you may see big memory consumption.

If it's for speed testing purposes then you'll be fine. For short lived normal e2e tests there are no issues with memory consumtion as far as I know.

I've only got "local" tests for specific projects, and even then mostly i can say "use specific locators" and that POM is potentially slightly slower than non-POM, you can see the results of that in <#1054712814675169300>

Oh, right. I read somewhere that xpath is supposedly slow, and ids should be fastest, but from my results I'm not quite sure if id is always the fastest. To reiterate, best results seem to be when there's a very clear path through the DOM tree.

...oh, and actually, I reuse a page in some of my tests, because reloading a single page application was taking most of the time of the test for simpler cases

And y'know, now that I've started, chromium is slightly faster in the general case, but firefox was beating it in some specific cases. webkit has been way too slow to consider for me.


Speeding Up Playwright Tests

Playwright supports parallel execution of tests. This means you can run multiple tests simultaneously. If you have many independent tests in a single file, consider running them in parallel. Here's how you can configure this:

test.describe.configure({ mode: 'parallel' })

You can also shard your test suite across multiple machines with Playwright. This distributes the workload and executes tests concurrently on different machines, reducing overall execution time. Here's how to shard your test suite:

npx playwright test --shard=1/3

Soft assertions are another way to improve speed. They allow your test to continue running even if an assertion fails, providing more comprehensive feedback.

Keep your Playwright dependency up to date to maximize speed and ensure compatibility with the latest browser versions. Update Playwright regularly using:

npm install -D @playwright/test@latest

Playwright offers various tools that contribute to faster development and debugging processes. The VS Code extension provides an enhanced developer experience for writing, running, and debugging tests. The trace viewer allows you to inspect DOM snapshots for each action during testing and view network requests.

By following these best practices, you can optimize the speed and performance of your Playwright tests. For more tips, check out Tips for Writing Efficient Playwright Test Scripts.

Related Discord Threads

AboutQuestionsDiscord ForumBrowser ExtensionTagsQA Jobs

Rayrun is a community for QA engineers. I am constantly looking for new ways to add value to people learning Playwright and other browser automation frameworks. If you have feedback, email luc@ray.run.