Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Removing fixed waits can make Playwright tests faster and less prone to timing failures—but deleting lines alone does not prove a suite became more stable. The useful change is replacing elapsed-time guesses with checks for the state the test actually needs. Playwright already waits for locator actions to become actionable, and its web-first assertions retry until the expected UI condition is true.
The 200-line cleanup and stability improvement in this title are the author’s reported experience, not an independently verified benchmark. Playwright’s guidance explains why this kind of refactor can help; establishing that it helped this particular suite requires comparable before-and-after results.
Why were there so many waits?
Tests often add a sleep when an application seems unpredictable: wait a second after clicking Save, wait for the page to load, then continue. But elapsed time is only an indirect guess at readiness. If the application finishes sooner, the test still wastes the remaining time. If it finishes later, the test proceeds too soon and may fail.
Playwright’s Page API warns that “Tests that wait for time are inherently flaky” and advises against using page.waitForTimeout() in production tests. A fixed delay can be useful while debugging, but it is a poor synchronization strategy for a test that must behave consistently in CI.
#1 Best Overall
What should replace a fixed sleep?
Let locator actions wait for actionability
For a normal locator action such as click(), Playwright performs relevant checks before acting. For locator.click(), it waits for a unique match and checks that the element is visible, stable, able to receive events, and enabled. If those checks do not pass within the timeout, the action fails instead of clicking an unready target. See Playwright’s auto-waiting and actionability guidance.
That makes a separate sleep before an ordinary click unnecessary in many cases:
await page.getByRole('button', { name: 'Save' }).click();Actionability is not a guarantee that every application-specific asynchronous operation has completed. The click checks whether the target can be acted on; it does not, by itself, establish that a save request finished or that a confirmation appeared.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Assert the outcome the user should see
After an action, use a web-first assertion for the result the test depends on. Playwright’s web assertions retry until the condition passes or the assertion timeout is reached, so they can return as soon as the expected state appears. For example:
await page.getByRole('button', { name: 'Save' }).click();
await expect(page.getByRole('status')).toHaveText('Saved');The locator and expected text must match the application. The important distinction is that the assertion checks the result—“Saved” is displayed—rather than waiting an arbitrary number of milliseconds. See Playwright’s assertion documentation.
Do not treat network inactivity as universal readiness
networkidle means there have been no network connections for at least 500 ms. Playwright discourages using it as a testing readiness signal and recommends relying on web assertions instead. A quiet network does not necessarily establish the particular UI state needed for the next step; assert that state directly. Network behavior can still matter when it is itself the condition being tested.
How the synchronization choices differ
| Approach | What it waits for | When it is useful | Main limitation |
|---|---|---|---|
page.waitForTimeout(ms) |
A fixed duration chosen in advance. | Temporary debugging or deliberate timing experiments. | It neither detects readiness nor adapts to it: the delay may be longer than needed or too short. |
Locator action such as click() |
Actionability checks for the target element. | Performing an interaction once its target is ready to receive it. | It does not prove that a later application-level outcome, such as a completed save, has occurred. |
Web-first assertion such as toBeVisible() or toHaveText() |
The specified UI condition, retried until it passes or times out. | Verifying the user-visible result required by the next test step. | The locator and expected condition must describe the real outcome; a wrong expectation still times out. |
networkidle |
No network connections for at least 500 ms. | Only when network inactivity itself is relevant to the test. | General network quiet is not a universal signal that the required UI state is ready, and Playwright discourages it for testing readiness. |
What a 200-line cleanup does—and does not—show
Removing 200 lines is a meaningful description of the size of a refactor, but line count is not evidence that reliability improved. The title’s outcome should be read as the author’s personal report: no before-and-after run data or independent account is available here to verify the result.
Broader studies offer context, not proof of this particular change. The authors of the 2023 TRaf paper report an 11.1% reduction in test execution time from a time-based repair method that suggested shorter waits; that is not a measurement of this cleanup or evidence that deleting waits improves stability. A 2022 empirical study analyzed 452 commits and found concurrency-related causes—including asynchronous waits, race conditions, and deadlocks—were the dominant category among the flaky-test causes examined. That sample does not establish a universal rate or a Playwright-specific result. See the studies on time-based repair and flaky tests in JavaScript.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to tell whether removing waits helped your suite
For a credible before-and-after comparison, record the changes and run the old and new versions under comparable conditions. A useful report includes:
- Which wait patterns were removed, with representative examples from the diff.
- What observable condition replaced each wait, such as a specific status message or updated control.
- The test count and execution environment, including browsers and CI conditions.
- Comparable repeated-run results before and after, including failures or flaky retries—not just a single successful run.
If a replacement assertion times out, investigate whether its locator is correct, whether the expected state actually occurs, and whether an application or API error prevented it. Increasing a timeout without checking those possibilities can hide the underlying problem rather than fix synchronization.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
