​
Overview

There are lots of best practices for optimizing performance. You’ll see these ideas throughout the docs when relevant, but they’re combined here in summary. The optimizations fall into two sections:
  1. Architecture & Implementation optimizations
  2. Browser Session configuration & optimizations

​
Architectural Performance Patterns

​
Decrease round trip time (RTT) by running browsers in your region.

When prototyping locally, the round trip latency of the request minus execution time (the round trip time) is much shorter than when hosted. This is especially true when factoring in nonlocal capabilities like captcha solving or proxies. Also, keep in mind that each interaction with the page, even ones that seem atomic, can result in several underlying CDP commands, increasing the RTT. Using browser sessions geographically close to where you deploy your code reduces round trip time. Region localizing may produce an 8-9x gain in performance without code changes.
To learn more about running region-localized sessions, check out our multi-region guide.

​
Implement parallel processing.

When using Browserbase to run jobs, increase speeds by parallelizing your job processing. If you process the work concurrently, tasks can run in parallel, completing faster. Both Node.js and Python have support for parallel processing. Here’s a Python example to illustrate:
Python
# SLOWER -- processes elements sequentially
# for an_html_element in html_elements:
#     await get_element_text(an_html_element)

# FASTER -- processes elements in parallel
await asyncio.gather(
    *(get_element_text(an_html_element) for an_html_element
    in html_elements)
)

​
Parallelize session creation with app initialization.

Similarly, if your app has setup steps to do prior to processing work, you can parallelize session creation with that work. During initialization, use the Sessions API. This effectively eliminates some or all of the perceived clock time for creating the new session.

​
Choose the right runtime environment.

Try comparing performance across implementation languages & runtimes. You may discover through testing your app that Node.js outperforms Python in raw speed for I/O bound requests, whereas Python may be a better choice for CPU-bound tasks.

​
Follow your framework’s best practices.

Stagehand

Playwright

Puppeteer

Selenium

​
Browser Session Configuration & Optimizations

​
Avoid using multi tab browser sessions.

We support browser sessions with multiple tabs, but depending on the workload, you will likely begin to notice worse performance with more tabs. We don’t recommend this approach. You’ll get better performance by using multiple single tab browser sessions instead.

​
Disable CSS, images, JavaScript, and other unwanted assets.

If you don’t need it, don’t request it. Optimizing this should speed up your page downloads. Here’s a Playwright example in JavaScript showing how to intercept the request to block image, CSS, and JavaScript requests:
Node.js
// Enable request interception
await page.route('**/*', route => {
  if (
    route.request().resourceType() === 'image' ||
    route.request().resourceType() === 'stylesheet' ||
    route.request().resourceType() === 'script'
  ) {
    route.abort();
  } else {
    route.continue();
  }
});

​
Optimize page loading with waitUntil option

You can optimize page loading by configuring the waitUntil option when navigating to a page. Using the domcontentloaded event instead of the default load setting can significantly improve load speed:
Node.js
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
This instructs the browser to mark the page as “loaded” once the initial HTML document is fully parsed, without waiting for external resources like stylesheets, images, and frames. This approach can significantly reduce perceived load times, particularly for content-heavy pages.

​
Variable-Sized Browsers (Beta)

Variable-Sized Browsers can unlock improvements for your workflows—but should be used after trying core optimizations like region selection, blocking resources, and fine tuned optimizations. Once you’ve refined those, upgrading the browser size is a powerful next step. You can now choose the processing power behind each browser with Variable-Sized Browsers:
  • small - Default option for most workflows
  • medium - Great for faster page execution or moderate compute loads
  • large - Ideal for resource-intensive sites or heavy scripts
This feature is currently in waitlist-only beta. To join the waitlist, message us via the Pylon widget or email support@browserbase.com.