Before each action, Playwright waits until the element passes the checks that action needs, instead of acting after a fixed delay. Its documentation defines the checks:

• Visible: the element has a non-empty bounding box and does not have visibility: hidden.
• Stable: its bounding box stays the same for at least two consecutive animation frames, so it is not moving.
• Receives events: it is the element that would actually be hit at the click point, not covered by an overlay.
• Enabled: it is not disabled.
• Editable: it is enabled and not read-only (for fill and similar actions).

Different actions run different checks: click needs visible, stable, receives events and enabled, while fill needs visible, enabled and editable. If the checks don't pass within the timeout, the action fails with a TimeoutError, and its call log shows which check it was still waiting for.

Assertions work the same way. Web-first assertions such as await expect(page.getByRole('alert')).toHaveText('Saved') retry until they pass or time out, so you wait for the state you need instead of sleeping. What auto-waiting cannot know is your application's own readiness, for example data that loads after the button is already enabled, so assert on the visible result of that load.

Sources: Playwright auto-waiting, Playwright best practices