Launching a headless Chrome or Firefox instance takes 1–3 seconds and consumes 100–300 MB of memory. For a scraping service handling many concurrent requests, launching a new browser for each task is prohibitively slow. A browser pool maintains a collection of already-running browser instances, allocating a browser or context to each incoming task and returning it to the pool when done.
Pool implementations typically track state for each browser: whether it is idle or busy, how many tasks it has processed (browsers are recycled after N tasks to prevent memory leaks), and health status. When all browsers are busy, new tasks wait in a queue or receive an HTTP 429-style response indicating capacity is full.
Browserless, Playwright's browser-over-CDP pattern, and custom pool implementations using asyncio semaphores are common approaches. Kubernetes-based browser farms scale the pool horizontally by adding pod replicas based on queue depth.