Connect & Get help from 6000+ developers on our Discord community.

Optimize execution time and performance on Automate

Learn how to understand and reduce execution time for your Automate tests by optimizing BrowserStack time and user time components.

This guide covers queuing, start time, session duration, and configuration impacts to help you run faster Selenium tests on Automate.

BrowserStack time and user time

When you run tests on Automate, the total time you see (build or session duration) is split into two main components:

Aspect	BrowserStack time	User time
Definition	The time your Selenium test spends inside BrowserStack’s infrastructure	Everything outside BrowserStack’s infrastructure
Components	• Provisioning the VM, launching the browser, and initializing the Selenium hub/driver before your script runs • Waiting in queue for available browser/OS capacity or for parallels to free up • Executing your WebDriver commands in the browser • Wrapping up the session and finalizing logs, video, and artifacts	• Network hops between your machine/CI and BrowserStack • Time your site and backend services take to respond • Extra waits, retries, sleeps, and timeouts in your code • Any network constraints (VPN, firewall, SSL inspection, etc.) on your side
Depends on	BrowserStack infrastructure and the capabilities and configuration you choose	Your environment, site/backend performance, and test code efficiency
How to reduce	• Smartly choosing popular browser/OS combinations with good availability • Reducing heavy features you don’t need (for example, console/network logs, video) • Managing your parallels and queues effectively	• Improving connectivity to BrowserStack (avoid unnecessary VPN/proxy hops) • Optimizing your site/backend performance in test environments • Cleaning up unnecessary waits and command patterns in your test code

Components of BrowserStack time

BrowserStack time is made up of:

Waiting time
Start time
Session duration (command execution)
Miscellaneous time (stop time and small overheads)

We explain each metric and how to actively reduce it for web (Selenium/WebDriver) tests.

Waiting time

Waiting time is the time your session waits in a queue before a suitable device is allocated and start time begins.

Common queue reasons include:

No parallel available: You hit your parallel limit.
High‑demand browser/OS combos: Requesting rare or busy combinations (for example, a specific legacy browser version).
Region/pool constraints: Limited capacity in a chosen region or pool.

How you can reduce waiting time

Follow these best practices to minimize waiting time:

Broaden browser/OS selection where possible

Instead of a single strict combination, use:

Popular browser/OS combos and allow browser_version like latest to match more capacity.
Acceptable version ranges or stable channels to avoid bottlenecks.
See Automate capabilities for supported selectors and options: Automate capabilities

Prefer popular browser/OS combos for bulk runs

For large regression suites, choose widely used desktop browser/OS combinations (for example, Windows + Chrome latest, macOS + Safari latest) to leverage high availability. For mobile‑web tests on real devices, use Tier‑1/common devices with good availability: Devices tiers for Automate and App Automate

Reserve niche browsers, legacy versions, or lower‑tier devices for targeted compatibility tests, not for every regression run.

Right‑size and organize parallels

If many sessions are blocked by “no parallel available”, you have two levers:

Stagger test runs in your CI so you don’t start all suites at exactly the same time, or
Upgrade your parallel capacity to match your real concurrency needs.

Use our Automate plan API or dashboard to understand and organize how many sessions run in parallel: Get group plan information using Automate API

Avoid unnecessary async app signing delays

If you consistently see async_app_not_ready queue reasons, consider:

Using a simpler test build
Contacting support with session IDs so we can optimize signing for you

Start time

Start time is the time from when BrowserStack receives your session creation request until the browser is ready to accept WebDriver commands.

Internally, it includes:

VM provisioning and readiness checks
Browser allocation and startup
Enabling requested features (video, console logs, network logs, HAR)
Setting up Local Testing/VPN tunnels if enabled
Selenium hub handshake and driver initialization so the first command can run

How start time can increase

Common drivers of higher start time:

Many enabled capabilities and features:
- Video recording, console logs, network logs/HAR capture
- Local Testing/VPN tunnels
Non‑default Selenium configurations or unusual browser setups

How you can reduce start time

Use the steps below to explicitly reduce start time for your sessions:

Minimize capabilities and features during start

Disable features you don’t actively use in a given run:

Turn off video, console logs, and network logs/HAR for routine CI runs.
Only enable them for debug builds or on‑failure retries.

Use default Selenium hub settings where possible

Prefer BrowserStack’s default Selenium endpoint and standard browser configurations instead of custom/non‑default setups.

This avoids extra initialization overhead and keeps start time low.

Disable default‑on capabilities if not needed

In your capabilities, explicitly set default‑enabled features to off if you don’t use them:

For example, set browserstack.video = false, browserstack.consoleLogs = errors, or disable browserstack.networkLogs unless required.

Optimize browser setup and session initialization

Reuse stable browser versions and default profiles; avoid heavy custom browser profiles or extensions unless necessary.
Avoid excessive console logging at startup by controlling application log levels in test mode.

Use Local Testing only when required

Set browserstack.local = true only when your site or APIs are truly not reachable publicly.
When possible, test against public or staging endpoints instead of internal environments that require tunnels.
If you must use Local Testing, run the tunnel on a stable, well‑connected host so setup is fast.

Session duration (command execution time on BrowserStack)

Once start time is over and the browser is ready, session duration is the time when your commands are executing on BrowserStack until your test calls driver.quit/session stop.

How can your configuration increase session duration?

Session duration can grow due to:

Many commands, repeated element lookups, long chains of small actions.
Inefficient locator strategies (for example, heavy XPath or brittle CSS selectors).
Long, global implicit waits or many fixed sleeps.
Heavy capabilities: verbose console logging, network logging/HAR, video capture.
High network latency between your CI and BrowserStack region.
Slow site or backend responses.

How can you reduce session duration?

The following strategies help reduce session duration:

Simplify and optimize your test commands

Use Selenium best practices for locators:

Prefer stable IDs/data‑test attributes over heavy XPath.
Avoid deep or brittle XPath chains that are expensive to evaluate; prefer CSS selectors when feasible.

Reduce duplicated commands:

Remove unnecessary navigations or repeated checks.

Fix waits, sleeps and timeouts

Replace long sleeps with explicit waits that end as soon as a condition is met.
Don’t rely on very high global implicit waits; they cause every failed lookup to block.

Handle timeouts correctly:

Avoid repeatedly waiting for elements that never appear.
Fail fast when conditions are unmet, rather than adding more retries.

Reduce logging overhead during CI

For bulk/regression runs:

Turn off or reduce the use of: Network logs/HAR capture, video recording, verbose console logs.
Enable them only on smaller “debug” suites or re‑runs of failed tests.

Improve network path

Avoid unnecessary VPN hops or proxies where possible, or ensure they are well‑provisioned.

Optimize your site & backend for test paths

Use lightweight test configurations where analytics and other heavy background work are toned down for test environments.
Optimize frequently used backend endpoints used in tests.

Miscellaneous time (stop time and other overheads)

The miscellaneous time bucket includes the following:

Stop time is the time from when your script sends a session delete/quit until:

BrowserStack finalizes logs, video and artifacts.
The VM is cleaned up and returned to the pool.

How can you reduce miscellaneous/stop time?

Follow these best practices to reduce miscellaneous time:

Reduce test artifact volume

Keep video and expanded logs disabled for long or very chatty sessions when not needed.

Excessively verbose logging from the app itself will increase the size and processing time of logs at stop.

Stop sessions cleanly

Always end tests with a clean driver.quit/session delete rather than killing the test runner abruptly.

This avoids recovery/cleanup work that can add a bit of time.

Components of user time

User time may be shown as a single bucket, but you can think of it as:

Script‑level waits and retries
Application/backend response time
Network hops between your environment and BrowserStack

Below are the components and what you can do to reduce each.

Script‑level waits, retries and sleeps

Time your test spends waiting by design, outside BrowserStack infrastructure:

Hard sleeps: sleep(10), Thread.sleep(5000), etc.
Retry loops and polling for conditions.
Overly aggressive timeouts while looking for elements or states.

How you can reduce it

Replace fixed sleeps with conditional, explicit waits that end as soon as the UI is ready.
Apply realistic timeouts instead of very high global implicit waits.

Review flaky tests:

Fix fragile locators and race conditions instead of stacking more sleeps.
Ensure you are not masking real issues with extra waiting.

App and backend response times

Time taken by your own application and backend services:

Loading screens, transitions, and in‑app flows
API calls to your services (auth, payments, content, etc.)
Third‑party APIs your app depends on

How you can reduce site and backend response times

Profile and optimize slow flows your tests hit most frequently such as home page load, login, and checkout.
Ensure test/staging environments use configurations that avoid unnecessary heavy background tasks (for example, non‑critical analytics).

Network path between your environment and BrowserStack

Network latency and overhead between your local machine or CI infrastructure and BrowserStack hub region in addition to any VPNs, proxies, SSL inspection layers your traffic passes through contributes to this bucket.

How you can reduce it

Ensure your corporate network/VPN is not rate‑limiting or heavily inspecting traffic to BrowserStack

Capabilities and their performance impact

Some Automate capabilities significantly affect how long sessions take, especially start time and session duration. Below is a summary of high and medium impact capabilities (for Selenium) and guidance on how to use them to keep tests fast.

Capability/Feature	What it does	Main impact area	Impact level	How to reduce time
Local Testing (`browserstack.local = true`)	Creates a secure tunnel so browsers can access sites/APIs hosted in your internal network.	Start time, Session duration, User time (network)	High	Use only when your site/backend are not publicly accessible. Avoid routing unrelated traffic through the same tunnel.
Video recording (`browserstack.video`)	Records a full video of the browser session.	Start time (video setup), Session duration, Stop time	High	Keep video enabled for debugging/small suites, but disable for long, high‑volume CI runs. Common pattern: run once without video; re‑run failed tests with video.
Network logs (`browserstack.networkLogs`/HAR)	Captures detailed network traffic (requests/responses) from the browser.	Session duration, Stop time	High	Enable only when debugging network issues. Turn off for regular regression runs to reduce command overhead and artifact processing.
Console logs (`browserstack.consoleLogs`)	Captures browser console logs.	Session duration, Stop time	Medium	Set to errors or disable for routine CI runs. Enable verbose levels only when investigating failures.
Non‑default Selenium/browser configuration	Uses a non‑default Selenium hub endpoint, custom browser flags, or profiles.	Start time, Session duration	High	Prefer default Selenium endpoint and standard browser configs. Use custom settings only when needed and measured.
Browser extensions or custom profiles	Enables extensions, custom profiles, or DevTools instrumentation.	Start time (extra setup), Session duration	Medium	Turn these on only in tests that explicitly verify these features. Keep them off in standard regression runs.
Local/custom VPN tunnel options	Adds extra steps for custom VPN/tunnel configurations.	Start time	Medium	If possible, use standard Local Testing settings instead of complex custom VPN options.
Orientation changes, resolution & frequent screenshots	Rotation, resolution changes, and frequent screenshot commands (including heavy HAR/DOM snapshots).	Session duration	High	Minimize orientation and resolution changes (only when the test requires them). Limit screenshots to key checkpoints or failures instead of every step.

Did this page help you?

We're sorry to hear that. Please share your feedback so we can do better

Contact our Support team for immediate help while we work on improving our docs.

We're continuously improving our docs. We'd love to know what you liked

This page has exactly what I am looking for
This content & code samples are accurate and up-to-date
The content on this page is easy to understand
Other (please tell us more below)

Any additional feedback?

Thank you for your valuable feedback

Is this page helping you?

Yes

We're sorry to hear that. Please share your feedback so we can do better

Contact our Support team for immediate help while we work on improving our docs.

We're continuously improving our docs. We'd love to know what you liked

This page has exactly what I am looking for
This content & code samples are accurate and up-to-date
The content on this page is easy to understand
Other (please tell us more below)

Any additional feedback?

Thank you for your valuable feedback!