Exclude domains from load test reports

Filter out third-party domains from Load Testing metrics to focus on the performance of your application

What it does

A load test usually loads third-party domains you did not write and are not benchmarking: analytics, auth providers, CDNs, chat widgets. Domain exclusion keeps those out of your report, so the browser metrics show only the domains you care about.

You give a list of domains and, for each, how to match it. Anything matching is left out.

Affected report data, the browser metrics:

• Page Load Times
• Web Vitals
• Network requests

Where it applies

Domain exclusion is available on browser load tests (a browser test, or the browser side of a hybrid test) running Playwright, Selenium, WebdriverIO, or Nightwatch. For Playwright, both Playwright - NodeJS and Playwright - Robot are supported.

It does not apply to API-only tests, which produce no browser page or network metrics. On a hybrid test the rules affect the browser side only. The API side is untouched.

When exclusion happens

Rules are applied at capture time, inside the browser, before metrics are stored. Excluded data is never written anywhere. That means:

• Your report, charts, tables and CSV exports all reflect the exclusion consistently. There is nothing to filter afterwards.
• Excluded data cannot be recovered for a completed run. Changing the rules affects future runs only.

If you are unsure whether a rule will do what you want, run once without it and compare the two reports. That is the only way to see what a rule would have removed.

What your rule is matched against

Your rule matches against the hostname component of the URL only. This distinction is critical to correct rule configuration.

Take a request the browser made:

https://cdn.jsdelivr.net:443/npm/lodash@4.17.21/package.json
scheme  hostname          port  path

Your rule is compared against the hostname (cdn.jsdelivr.net), and nothing else. The scheme, port, path and query string are all discarded before any comparison happens.

Hostname is not the same as domain name

Zoom into the hostname cdn.jsdelivr.net: cdn is the subdomain, jsdelivr the name, net the top-level domain.

• Hostname: cdn.jsdelivr.net. The full address of one specific machine, including every subdomain label.
• Domain name: jsdelivr.net. The name the organisation registered. They can create any number of hostnames under it: cdn., www., api. and so on.

The two conditions

Both match against the hostname, as described above. Both are case-insensitive, so Microsoft and microsoft behave identically.

Contains checks whether the hostname contains your text, not whether the full URL does. The comparison runs one way round: your text has to fit inside the hostname. Entering a whole URL such as https://cdn.jsdelivr.net/npm/lodash@4.17.21/package.json can therefore never match, because the scheme and path it carries do not exist anywhere in a hostname. Enter cdn.jsdelivr.net, or a fragment of it like jsdelivr.

Rules combine with OR: a row is excluded as soon as any rule matches. Each rule stands alone, with no way to express “exclude A only when B”.

Add domains

You can add exclusion rules using the UI Builder dashboard or by editing your CLI configuration file. Choose the method that fits your workflow.

browserstack load run -cf ./browserstack-load.yml

Invalid domain 'https://www.example.com/search' in 'excludeDomains'.
Please provide a bare hostname, without scheme, path, port or credentials.

What gets excluded, exactly

Each rule is checked against two things: the URL of each page, and the URL of each network request.

• Page Load Times and Web Vitals rows are matched on the page’s own URL.
• Network rows are matched on the request’s URL and on the URL of the page that issued it.

That second point produces the one behaviour worth understanding:

Excluding a page also removes the network calls that page made. Exclude checkout.example.com and you lose that page’s Page Load Times and Web Vitals and every request it issued, including requests to other domains. This is deliberate because leaving those behind would show network activity belonging to a page that is no longer in the report.

Excluding a network call does not remove the page that made it. Exclude analytics.vendor.com and every page that called it keeps all of its own metrics. Only the calls to that vendor disappear.

A worked example: a test visits two pages, each calling the same vendor:

A practical consequence: excluding a page can remove more than you expect. On a verified run, excluding one search engine also removed its analytics and bot-challenge requests to four unrelated hostnames, because that page had requested them.

Common configuration mistakes

Most confusion arises from two patterns. Understanding them upfront saves troubleshooting later.

Exact hostname matching with Equals

The Equals condition performs exact string comparison on the full hostname, including all subdomains. If a site’s pages are served from www.example.com, a rule of example.com with Equals excludes nothing because the two hostnames are different strings.

No validation error occurs when this mismatch happens. The test completes normally and the report appears unchanged, as if no exclusion rule were set. To diagnose rules that produce no effect, verify this condition first.

Hostname format validation

Domain values must be bare hostnames without URL components. A scheme (https://), port (:443), path (/path), or trailing slash (/) prevents the rule from matching on both Equals and Contains conditions.

Real-world case: A test attempted to exclude a jsDelivr request using four separate rules, yet the request remained in the report. The matching operation compared only the hostname cdn.jsdelivr.net against each rule:

All four represent the same format error. A correct rule, cdn.jsdelivr.net with either Equals or Contains excludes the request.

This principle applies symmetrically: a request whose URL contains your domain in a non-hostname context is not excluded. For example, a redirect to https://login.example-idp.com/oauth?redirect_uri=https://www.example.com/ originates from login.example-idp.com, so a rule for example.com does not match. This behavior is correct: the actual request was made to the identity provider host, not your site.

Limits

Domain exclusion is subject to the following constraints:

A rule set that saves is the rule set that runs. Nothing is silently dropped or truncated. If any entry is invalid the whole test is rejected rather than partially applied.

Reasons an entry is rejected:

• more than 10 entries
• domain missing or empty
• domain longer than the maximum length
• condition is anything other than contains or equals
• an entry contains keys other than domain and condition

If a domain you excluded is still showing

If a domain you set a rule for continues to appear in the report, follow these steps to diagnose the issue:

If everything is missing from the report, your rules most likely matched every domain the test visited. That run is treated as an ordinary empty report. It is not flagged as a special case, and the data cannot be recovered. Widen or remove a rule and run again.