Glossary

networkidle

How a headless browser decides a page has finished loading — and why that is a guess.

By Roger Campos · Last updated: September 2026

TL;DR

networkidle is a wait condition in browser automation: the page counts as ready once network activity has stayed quiet for a short window, typically 500 ms. Puppeteer's networkidle0 allows no open requests, networkidle2 allows at most two. It catches content loaded after the load event.

Start free See the API

Free plan, no credit card. 1,000 credits a month.

The problem

Why "loaded" isn't loaded

The browser fires load once the HTML and every resource it referenced at parse time have arrived. A modern page keeps going after that: its JavaScript calls APIs, loads more scripts, fetches images. Read the DOM at load and a client-rendered page may still be a spinner.

networkidle is the heuristic automation tools settled on: stop counting on events, and watch the network instead. When requests stop, the page has probably stopped changing.

Condition	Ready when
networkidle0 (Puppeteer)	No network connections for 500 ms
networkidle2 (Puppeteer)	No more than 2 network connections for 500 ms
networkidle (Playwright)	No network connections for 500 ms

In practice

Where it fails

Some requests never finish by design: a WebSocket, a Server-Sent Events stream, a long-poll, an analytics beacon on a timer. With networkidle0 one of those holds the wait until it times out, which is why networkidle2 tolerates two. In the other direction, a page that renders after a setTimeout with no request in flight looks idle before it has drawn anything. Playwright's own docs discourage relying on it for tests and recommend waiting for a specific element.

URLpipe

How URLpipe waits

URLpipe's engine waits for load, then for the page to go quiet: no more than two requests in flight for 500 ms, capped at 15 seconds. A request open longer than five seconds stops counting, so a WebSocket or a stream cannot hold the page forever. That covers most pages without any option.

For the rest, page_options gives you the two dependable waits: wait_for_selector for content you can name, and delay (up to 10,000 ms) for content that arrives on a timer.

POST /html

{
  "url": "https://example.com/dashboard-demo",
  "sync": true,
  "page_options": { "wait_for_selector": "#chart svg", "delay": 500 }
}

Try it

networkidle, on a page you choose

Get the rendered HTML of any URL

Paste a link and get the page's HTML after JavaScript has run and redirects have been followed — the DOM a real browser sees, not the empty shell curl returns.

Try it free

FAQ

Frequently asked questions

Should I use networkidle0 or networkidle2?

networkidle2 is the safer default for real sites, because analytics, chat widgets and sockets often keep one or two connections open indefinitely. networkidle0 suits pages you control.

Why does waitUntil networkidle time out?

Something on the page keeps making requests — polling, a stream, an ad rotating. Use networkidle2, or wait for a selector instead.

What is better than networkidle?

Waiting for the element you actually need. It is the only condition that means what you want it to mean.

Keep reading

Why we built our own rendering engine Headless browser Archiving pages as screenshots Cline Get the rendered HTML of a JavaScript page in cURL Per-project rate limits All of glossary

See it on your own pages.

Free plan, no card. Confirm your email and your API key is live — you'll be making real requests in minutes.

Start free Email the team