Browser Pool

A browser pool is a managed set of browser instances or browser contexts that a crawler checks out, uses for a page or a session, and returns. Launching a process per page and killing it afterwards is what most crawlers do first, and what they stop doing once volume grows. Pooling amortises startup cost across many pages and puts a hard ceiling on how much memory the fleet can consume at once.

The resource arithmetic forces the design. A Chromium instance is heavy on both axes: as a working rule of thumb, expect hundreds of megabytes of resident memory per instance and on the order of a second or more to reach a usable state, though real figures depend on flags, extensions and page weight, so measure your own. At modest concurrency that is the difference between one machine and ten. Playwright's own documentation points at the cheaper unit inside the browser: contexts are "fast and cheap to create and are completely isolated, even when running in a single browser" (Playwright browser contexts docs, read 2026-07-27).

That sets up the isolation choice. Reusing one browser and handing out fresh contexts is fast and cheap, but the contexts still share a process, a network stack and whatever the browser caches below the context boundary, so a crash takes every tenant down with it. Full process isolation per job is clean and expensive. Most production pools sit in between: several browser processes, each serving a bounded number of contexts, recycled after a fixed page count. Recycling is not optional, because the failure modes are cumulative. Zombie processes survive a killed parent, page handles leak when an error path skips close(), and long-lived instances grow memory until the host swaps. A pool without a max-pages-per-browser limit and a reaper will run fine for hours and then fall over.

Hosted browser infrastructure sells this as a product, though usually metered by browser time rather than by session. Browserbase prices a Developer plan at $20 per month with 100 browser hours included, then $0.12 per browser hour, and a Startup plan at $99 per month with 500 hours and 25 to 100 concurrent browsers depending on tier (Browserbase pricing page, read 2026-07-27). Browserless meters differently, defining a Unit as "a block of browser time of up to 30 seconds per browser connection," with overage from $0.0020 down to $0.0015 per unit across plans and concurrency from 10 to 100 (Browserless pricing page, read 2026-07-27). Steel and hyperbrowser compete on the same ground. The decision is arithmetic: size a pool against target latency and concurrency, convert your monthly browser-seconds into the vendor's unit, and compare that against the fully loaded cost of running your own fleet.