Skip to main content
Batch scraping is just scrape() with an array of URLs and a concurrency setting. Reader handles the parallelism, browser pool checkout, error tracking, and result aggregation.

Minimal example

batchConcurrency: 2 means Reader processes two URLs in parallel. With the default browser pool of size: 2, that fully utilizes both browsers. If you want more parallelism, increase both size and batchConcurrency together.

Progress tracking

Pass an onProgress callback to get updates as URLs complete:
The callback fires after each URL finishes (success or failure). It’s synchronous - don’t do heavy work inside it. For writing progress to a database or emitting events, use setImmediate or a small async queue.

Tuning concurrency

The optimal batchConcurrency depends on:
  • Browser pool size - you can’t scrape more URLs in parallel than you have browsers
  • Target site rate limits - hammering a single domain from multiple parallel requests will get you rate-limited
  • Memory - each concurrent request uses a browser instance (300-500 MB)
A good rule of thumb:

Handling partial failures

Batch scrapes never throw on individual URL failures. The result’s batchMetadata.errors array lists the failed URLs:
result.data.length matches successfulUrls, not the input length. If you need to track which input URL corresponds to which output, use a map:

Batch timeout

The batchTimeoutMs option sets a total time budget for the entire batch:
If the batch doesn’t complete in time, any unfinished URLs fail with a timeout error. Successful URLs up to that point are still returned. For very long batches (thousands of URLs), consider splitting into smaller chunks and processing them sequentially:

Where to go next

Browser Pool

Understand how pool size interacts with concurrency.

Proxy Configuration

Rotate proxies across batch requests.