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 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 where MaxoPerf fits in 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 straight 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 answers “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 answers “what does a user experience?”
When to use real browsers
Section titled “When to use real browsers”Use browser-level testing when protocol metrics alone cannot answer the question:
- Core Web Vitals measurement. LCP, CLS, INP and TTFB need a real browser rendering pipeline.
- SPA correctness under load. Protocol tests cannot see client-side routing, lazy-loaded chunks or hydration failures.
- Third-party script impact. Analytics, chat widgets and A/B testing scripts add load that only a browser can measure.
- Front-end regression gate. Checking 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, playwright and wdio executors. Taurus manages the 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. - Upload a Playwright spec or library script (with your own
playwright.configif you have one) for theplaywrightexecutor. - 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. MaxoPerf runs Playwright scripts as browser VUs with the playwright executor on Chrome, Edge and Firefox. Pair a few of them 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: 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: the Taurus
seleniumexecutor in detail. - 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.