Browser vs protocol load — the tradeoff

Protocol load testing and browser-level load testing answer different questions. Using the wrong approach for your question wastes money (browser VUs are expensive), produces misleading data (protocol metrics miss client-side failures), or both. This page gives you the full tradeoff so you can choose — or combine — with confidence.

Before you start

• Read Browser performance testing overview for the foundational distinction between what each approach measures.
• Read Selenium performance testing to understand how browser VUs work in MaxoPerf.

The tradeoff table

Dimension	Protocol load (JMeter / k6 / Taurus HTTP)	Real-browser (Taurus selenium / wdio)
What it measures	Raw HTTP response time — server processing + network	Full end-user experience — server + render + JS + third-party
VU cost	Low — thousands of VUs per CPU core	High — 1 full Chrome process per VU; 10–100× more resource-intensive
Max practical VU count	Hundreds to thousands on a single runner	5–50 VUs per runner before CPU/memory saturates
Startup time	Near-instant	10–30 s per Chrome instance cold-start
Realism	Simulated — only HTTP-level fidelity	High — JS execution, rendering, third-party scripts, web fonts
Core Web Vitals	Not available — no browser pipeline	Available — LCP, CLS, INP, TTFB from the browser
JavaScript errors	Not detected	Detected as assertion failures or uncaught exceptions
SPA hydration correctness	Not testable	Testable
Third-party script impact	Not captured	Captured
Scenario complexity	High — multi-step flows, correlation, data parameterization	High — full browser scripting with explicit waits
Result interpretation	Straightforward — response time = server time	More nuanced — response time includes render; compare to protocol baseline
CI suitability	Excellent — fast, deterministic, low cost	Moderate — slower start, more resource-intensive, less deterministic
Best for	Throughput ceiling, soak/endurance, API regression	UX truth, Core Web Vitals gate, SPA journey correctness

What each approach catches

Protocol load catches

• Throughput ceiling — the maximum RPS the server can sustain before latency climbs or errors appear.
• Latency under concurrency — how server-side response time degrades as VU count increases.
• Error rate at scale — HTTP 4xx/5xx rates under realistic or peak load.
• Database / queue / cache bottlenecks — these surface as latency increases in protocol metrics.
• API regression — whether a new deploy changed response time vs a baseline.

Protocol load does not catch rendering failures, JavaScript errors, slow LCP caused by a large hero image, or the 500 ms a third-party chat widget adds to TTI.

Browser testing catches

• Real page load time — including JS parsing, hydration, and render.
• Core Web Vitals — LCP, CLS, INP, TTFB as a real browser sees them.
• Front-end regressions — a new JS bundle size or layout change that pushes LCP past your SLO.
• SPA navigation correctness — client-side route transitions, lazy-loaded chunks, hydration mismatches.
• Third-party script overhead — analytics, chat widgets, consent banners, A/B testing scripts.
• Visual bugs under load — elements that fail to render when the API slows down.

Browser testing does not scale to high VU counts economically. It is not the right tool for finding the server throughput ceiling.

When protocol load is the right choice

• You want to know how many concurrent users the API can handle.
• You are running a soak or endurance test over hours.
• You are finding the breakpoint / capacity ceiling.
• You need 500+ VUs.
• CI time budget is tight (< 5 min).
• Your application is primarily a JSON API consumed by a mobile app or another service.

When browser testing is the right choice

• You need to measure or gate on Core Web Vitals.
• Your application is a content-heavy SPA where rendering time is significant.
• You need to validate that a user journey completes correctly (not just that HTTP returns 200).
• You have third-party scripts that matter for UX and cannot be simulated.
• You want a pre-release UX gate at low VU count (2–10 browsers).

When to use both

The hybrid load architecture pattern uses both simultaneously: many protocol VUs stress the backend while a small number of browser VUs sample the front-end experience. This answers both questions — “how much load can the server handle?” and “what does a user see during peak load?” — in a single coordinated MaxoPerf run.

Recommended split

Test type	Protocol VUs	Browser VUs	Rationale
Pre-release UX gate	0	3–5	Pure browser check, no load needed
Hybrid peak simulation	200–500	3–10	Backend stress + UX measurement
Core Web Vitals baseline	0	2–3	Minimal browser runs for reliable CWV data
Throughput / breakpoint	200–2000	0	Pure capacity — browser adds no value here
SPA journey regression	0	5–10	Correctness check, not a throughput measurement

Do / don’t

Do:

• Use browser VUs specifically when the question is about UX or Core Web Vitals.
• Start with protocol load for any scale or throughput question — it is faster, cheaper, and more stable.
• Use the hybrid pattern when you need both answers in one run.

Don’t:

• Run 100+ browser VUs trying to generate load — use protocol VUs for that.
• Compare browser test response times directly against protocol test response times — they measure different things.
• Drop browser testing entirely just because it is expensive — 3–5 browser VUs give you real UX data that protocol tests cannot provide.

Where to go next

• Hybrid load architecture — the canonical pattern for combining browser and protocol VUs.
• Frontend web vitals under load — how to measure Core Web Vitals while the backend is stressed.
• Selenium performance testing — how to run browser VUs in MaxoPerf.
• Test types: Frontend browser performance test — test type context and load profile guidance.