Browser performance testing
Protocol-level load testing tells you how many requests per second your server can handle. Browser performance testing tells you what a real user actually experiences: page load time, JavaScript render, Core Web Vitals, and every network call a modern SPA makes. This section explains the difference, when real browsers add value, and how MaxoPerf fits into each approach.
What each approach measures
Section titled “What each approach measures”Protocol load (HTTP simulation)
Section titled “Protocol load (HTTP simulation)”Protocol load tools — JMeter, k6, Taurus native — send raw HTTP requests directly from the runner process. There is no browser, no JavaScript engine, and no rendering. The runner measures:
- Raw HTTP response time from first byte to last byte.
- Throughput (requests per second).
- Error rates by HTTP status code.
This is fast and cheap: a single runner CPU core can sustain thousands of protocol VUs. Protocol load is the right tool for answering “how many concurrent users can my server handle?”
Real-browser testing
Section titled “Real-browser testing”Browser VUs drive actual Chromium or Firefox instances. Each browser:
- Fetches the HTML document.
- Parses and executes JavaScript (including framework boot, hydration, SPA routing).
- Renders the page, loads web fonts, images, and third-party scripts.
- Reports browser-side timing: Navigation Timing, Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Interaction to Next Paint (INP), Time to First Byte (TTFB).
This is expensive: a single browser VU can use 10× the CPU and memory of a protocol VU. Browser testing is the right tool for answering “what does a user actually experience?”
When to use real browsers
Section titled “When to use real browsers”Use browser-level testing when the question cannot be answered with protocol metrics alone:
- Core Web Vitals measurement — LCP, CLS, INP, TTFB require a real browser rendering pipeline.
- SPA correctness under load — client-side routing, lazy-loaded chunks, and hydration failures are invisible at the protocol level.
- Third-party script impact — analytics, chat widgets, and A/B testing scripts add load only a browser can measure.
- Front-end regression gate — verifying that a backend slowdown does not push LCP past your SLO.
- User-journey timing — measuring the full login → dashboard → key action flow end-to-end, including render time.
Use protocol load for everything else: raw throughput, breakpoint capacity, soak endurance, and large-scale concurrency. Protocol load is 10–100× more efficient per VU.
MaxoPerf’s role
Section titled “MaxoPerf’s role”MaxoPerf runs real-browser tests through the Taurus selenium executor (and the wdio executor for JavaScript-based scripts). Taurus manages browser lifecycle, parallelism, and result collection. MaxoPerf handles the runner fleet, result storage, and the run-detail dashboard.
In MaxoPerf you can:
- Run a Taurus YAML with
executor: seleniumand a Python WebDriver script. - Use a Selenium IDE
.siderecording as the entrypoint — MaxoPerf detects the executor automatically. - Use the
wdioexecutor for WebdriverIO JavaScript scripts. - Combine a small number of browser VUs with a large protocol load run (the hybrid pattern).
Playwright is the leading browser-automation and web-vitals measurement library for scripting user journeys. It is not a Taurus executor — you use Playwright scripts as the authoring and web-vitals measurement layer outside a MaxoPerf run, and pair those measurements with MaxoPerf’s scale-out protocol load for backend capacity. See Playwright performance testing for the full pattern.
Decision table
Section titled “Decision table”Use this table to choose the right approach for your goal.
| Goal | Approach | In MaxoPerf |
|---|---|---|
| Find server throughput ceiling | Protocol load | JMeter, k6, Taurus native executor |
| Measure LCP / CLS / INP / TTFB | Browser run | Taurus selenium executor |
| Validate an SPA journey renders correctly under load | Browser run | Taurus selenium executor |
| Test API endpoints in CI | Protocol load | k6 or Taurus HTTP |
| Combine UX check + backend scale test | Hybrid (browser VUs + protocol VUs) | Two executors coordinated in MaxoPerf |
| Author a browser script + capture web vitals | Playwright script (authoring layer) | Run Playwright locally; pair with MaxoPerf protocol load |
| Soak / endurance over hours | Protocol load | Any protocol executor |
| Pre-release web-vitals gate | Browser smoke (low VUs) | Taurus selenium, 2–5 VUs |
What this section covers
Section titled “What this section covers”| Page | What you will learn |
|---|---|
| Selenium performance testing | Running browser journeys under Taurus selenium in MaxoPerf — YAML, Python scripts, scaling VUs |
| Playwright performance testing | Capturing Core Web Vitals with Playwright scripts; pairing with MaxoPerf protocol load |
| Browser vs protocol load | Full tradeoff analysis — accuracy, cost, scale, and what each catches |
| Frontend web vitals under load | Measuring LCP/CLS/INP while the backend is under protocol stress |
| Hybrid load architecture | Combining many protocol VUs + a few browser VUs in one coordinated MaxoPerf run |
| Daily browser performance scenarios | Pre-release gates, checkout journeys, login regressions, marketing-launch checks |
| Browser performance do / don’t | Patterns that work; common mistakes that waste money or produce misleading data |
Where to go next
Section titled “Where to go next”- Selenium performance testing — start here to run your first browser test in MaxoPerf.
- By engine: Selenium browser tests — deep dive on the Taurus
seleniumexecutor. - Test types: Frontend browser performance test — test-type context and load profile guidance.
- Foundations: Core metrics explained — latency, throughput, and error rate as a starting point.