Frontend / browser performance test

A frontend performance test uses real or headless browsers to drive user interactions and measure the experience from the browser’s perspective: page load times, Core Web Vitals (LCP, CLS, FID/INP), JavaScript execution, and rendering time. This is fundamentally different from API performance tests — a browser test captures everything the user sees, including render time, third-party scripts, and client-side JavaScript overhead.

Before you start

• You have identified the user journeys to measure (for example, login → dashboard → run detail page).
• Your test environment serves the full frontend stack (not just the API).
• You have a Selenium or browser-compatible test script. MaxoPerf supports Selenium through the Taurus executor.

What is a browser performance test?

Browser performance tests run real browser instances as virtual users. Each browser instance:

1. Navigates to the target URL.
2. Executes the interactions in your test script (click, type, scroll, wait for element).
3. Captures browser-side timing metrics (navigation timing, LCP, CLS, resource load).
4. Reports results back to MaxoPerf as it would any other runner.

When to use browser testing vs API testing

Scenario	Use API test	Use browser test
Benchmark a REST endpoint	✓	✗
Validate a CI performance gate	✓ (faster, cheaper)	Optional
Measure real page load time (with JS render)	✗	✓
Measure Core Web Vitals (LCP, CLS, INP)	✗	✓
Find how many users a backend can handle	✓	✗ (browsers are expensive VUs)
Test an SPA interaction that triggers multiple API calls	Both	✓ (captures the full flow)
Test a third-party checkout widget	✗	✓

Scale expectations

Browser VUs are significantly more resource-intensive than protocol-level VUs. A single browser VU can consume 10× the CPU and memory of a JMeter or k6 VU. Plan accordingly:

• Smoke / sanity: 1–3 browser VUs.
• Journey performance measurement: 5–20 browser VUs.
• Large-scale browser load: use API tests instead; browser-level concurrency at scale is rarely a practical goal.

How to run a browser test in MaxoPerf

Load profile

Parameter	Value
Virtual users (VUs)	5–20 browser VUs
Duration	10–20 min
Ramp-up	2–5 min (browsers take longer to cold-start)
Engine	Selenium (via Taurus selenium executor)
Locations	1–2 managed locations

Console walk-through

1. Write a Taurus YAML using the selenium executor and point to a Python (pytest-selenium) or Java (JUnit) script:

   execution:
     - executor: selenium
       concurrency: 5
       ramp-up: 3m
       hold-for: 10m
       scenario: ui-journey
   
   scenarios:
     ui-journey:
       browser: Chrome
       headless: true
       script: scripts/journey.py
   
   modules:
     selenium:
       chromedriver:
         version: latest

   A minimal scripts/journey.py measuring page load:

   from bzt.modules.selenium import AbstractSeleniumTest
   
   class CheckDashboardLoad(AbstractSeleniumTest):
       def test_dashboard_load(self):
           self.driver.get(self.get_target_url('/'))
           self.wait_for_element('#run-list')
           nav_timing = self.driver.execute_script(
               "return window.performance.timing"
           )
           load_time = nav_timing['loadEventEnd'] - nav_timing['navigationStart']
           self.assertLess(load_time, 3000, "Page load exceeded 3 s")

2. Upload the Taurus YAML and the scripts/journey.py file to the test via the Files tab.

3. In Load profile, set Virtual users to 5, Ramp-up to 3m, Duration to 10m. Select the Selenium engine.

4. Click Run and monitor the live results. Browser VUs are slower to start — expect the first metrics to appear 30–60 s after the run enters running.

How to read the result

After the run reaches finished:

• Response time — each driver interaction (get, click, wait_for) is reported as a separate label. Focus on page-load or navigation-complete labels to see end-to-end browser load times.
• Error rate — assertion failures in your browser script are reported as errors. A high error rate often means a UI element was not found (layout change, slow render).
• Runner health — browser VUs are more likely to saturate runners. Check the Runners tab for any runners in degraded state.
• Core Web Vitals — if your script uses the Web Vitals API (web-vitals JS library) and reports metrics via a custom label, those values will appear in the results breakdown.

Do / don’t

Do	Don’t
Use headless Chrome for reproducible results	Use headed Chrome in a CI environment — it will fail
Keep browser VU counts low (5–20) — they are expensive	Scale browser tests to 500 VUs — use API tests for concurrency
Combine with API tests: browser for journey timing, API for throughput	Replace API tests with browser tests entirely
Assert on observed page state, not just response codes	Assume a 200 response means the page rendered correctly
Run browser tests from a managed location close to the target	Compare browser-test latency numbers against API-test latency numbers directly

Where to go next

• API performance test — benchmark API endpoints without the browser overhead.
• By engine: Selenium browser tests — Selenium executor deep dive, script patterns, and ChromeDriver options.
• Foundations: Core metrics explained — latency, throughput, and error rate in the browser context.
• Best practices: Interpreting results dos and don’ts — how to read browser timing numbers without drawing wrong conclusions.