k6 Browser Module and HTTP Scenarios in One Run: Safe to Co-Locate VUs?

Short answer

Co-locating is allowed but not isolated. k6 provides no built-in mechanism to cap CPU or memory per scenario — all VUs, browser or HTTP, share the same host process and machine. A Chromium-backed browser VU can therefore starve the cheap HTTP VUs and inflate http_req_duration percentiles in the very summary you wanted to trust. For anything beyond a small smoke run, the reliable options are separate runs, or external isolation (containers/cgroups, separate generators).

What k6 actually offers

Within one script you can mix executors freely — e.g. constant-vus for HTTP and a browser scenario using the browser executor — and both metric families (http_req_duration, browser_web_vital_*) land in one end-of-test summary. That part works. What does not exist:

• No per-scenario CPU/memory quota in k6 configuration.
• No per-scenario resource metrics in the output; k6 cannot tell you which scenario consumed what.
• No scheduling priority between executors.

So \"isolation\" must come from outside k6: run the browser scenario in its own container with --cpus/--memory limits, or split into two runs (possibly against the same environment simultaneously, from separate generators).

If you co-locate anyway: saturation signals

Since k6 won't flag generator overload for you, watch for these patterns:

• System metrics first: CPU pegged near 100%, memory pressure or swap activity on the generator (htop, docker stats). This is the primary indicator.
• HTTP distribution shift: compare http_req_duration p90/p95 with and without the browser scenario active. A significant rise, or much wider spread between mean and p95, suggests contention rather than a slower backend.
• Dropped/late iterations: if a scenario can't sustain its configured arrival rate or VU schedule, that's a strong sign the generator — not the system under test — is the bottleneck.
• Web-vital noise: browser metrics degrading in proportion to HTTP load (rather than to backend changes) also points at local CPU starvation of Chromium.

A practical verification: run 1 browser VU alongside your HTTP load, then 5, and plot HTTP percentiles at each step. The load level where percentiles bend upward is your generator's co-location ceiling.

Version boundary

The browser module landed as experimental in k6 v0.34.0 with an older API surface, and the current API — import { chromium } from 'k6/browser' with an async, per-iteration browser context — stabilized around v0.37.0. Scripts written for 0.34–0.36 are not syntax-compatible with the current module. This answer assumes k6 ≥ v0.37; because the module has a history of breaking changes, confirm executor and option names against the release notes of the exact version you pin, and pin one explicitly in CI rather than tracking latest.

Recommendation

Use a single co-located run only for low-VU functional checks where absolute timings don't matter. For load results you intend to act on, run browser and HTTP scenarios as separate executions (or separate containers with cgroup limits) and merge the reports afterward — you keep one logical test campaign without letting Chromium's appetite contaminate your HTTP measurements.