Network Idle Is Not “Ready”
Learn why network-idle waits can hang or resolve too early, and choose a product-level readiness signal instead.
A quiet network says nothing about the exact UI state your assertion needs.
Network idle is a transport observation, not a product state. Polling, analytics, open streams and health probes can keep a page permanently busy. A cached response can also make the network quiet before React has rendered the result.
Wait for the contract
Choose the smallest signal that proves the next action is valid:
- A loading status disappears.
- A result row becomes visible.
- A button becomes enabled.
- A URL or flash message reaches the expected value.
- A specific response completes when the response itself is what you test.
Use network waits deliberately
Request and response waits are excellent when the network event is the contract. Whole-page networkidle is a broad heuristic. Treat it as a diagnostic tool, not a universal definition of ready.
Try the Streaming Feed and Request Interception challenges with both strategies. The difference becomes obvious as soon as the page performs useful work after the request has finished.
Keep reading
- Practice this topic
- Five Stable-Locator Anti-Patterns
- Testing a Custom Combobox Without Sleeps
- Deterministic Test Data Without Boring Tests
- Visibility vs. Presence: The Wait Condition Bug
Updated
Fun UI Playground — all challenges, bug hunts, getting started, glossary, about.