Optimize execution time and performance on App Automate

Broaden device/OS selection where possible

Instead of a single strict device, use:

• Device groups or DDA (Dynamic Device Allocation). Refer to this doc for required config changes: Use regular expression to specify device attributes
• OS version ranges (e.g. >= 13.0), so that the request can match more devices and avoid bottlenecks.

Prefer Tier‑1/common devices for bulk runs

For large regression suites, choose Tier‑1/common devices with good availability. Refer to this page to understand which tier your device belongs to: BrowserStack - Devices tiers for Automate and App Automate

Reserve new and 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 App Automate plan API or App Automate dashboard to understand and organize how many sessions run in parallel.

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

Minimize capabilities and features during start

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

• Turn off video, device logs, and network logs for routine CI runs.
• Only enable them for debug builds or on‑failure retries.
• Avoid extra device features (battery mocks, heavy custom logging) unless you specifically test them.

Use default Appium where possible

Prefer BrowserStack’s default Appium instead of a non‑default/custom Appium configuration.

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:

E.g. browserstack.video = false, browserstack.deviceLogs = false, etc.

Optimize your app for cloud install

• Reduce app size (remove unused assets/debug symbols where possible).
• Re‑use previously uploaded apps instead of re‑uploading the same app frequently.
• Avoid test builds that log excessively on startup (it can slow initial boot and logging setup).

Use Local Testing only when required

• Set browserstack.local = true only when your app 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.

Simplify and optimize your test commands

Use Appium best practices for locators:

• Prefer ID/accessibility ID over heavy XPath.
• Avoid deep or brittle XPath chains that are expensive to evaluate.

Reduce duplicated commands:

• Remove unnecessary navigations or repeated checks.
• If you’re using watchers or custom hooks (especially on Android), make sure they are not running excessively

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, Video recording, Device 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 app & backend for test paths

• Use a lightweight test build where crash reporting, analytics and other heavy background work are toned down for test environments.
• Optimize frequently used backend endpoints used in tests

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.

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 script‑level waits:

• 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 app and backend response times:

• Profile and optimize slow flows your tests hit most frequently such as home screen load, login screens, etc.
• Ensure test/staging environments use test configurations that avoid unnecessary heavy background tasks (e.g., 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 network path delays:

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

Look at your time split

If BrowserStack time is high:

• Focus on Start time, Queuing, and capabilities you’re enabling.

If User time is high:

• Focus on reducing waits, optimising application and third party API calls and remove unnecessary logging

Start with the biggest lever

• If queues dominate - optimise parallels and choose Tier‑1/broader device sets.

• If start time dominates - trim capabilities and app size, limit Local Testing usage to only when necessary.

• If execution dominates - clean up test code, locator strategies, and reduce logs.

Make one change at a time and measure

After each change (e.g. disabling network logs for CI), compare the following parameters using the App Automate dashboard:

• Average start time
• Queuing time
• Session duration