why are chromium browsers so slow

[mortenbj-statnett]

This is in a container running ubuntu 24.04LTS under WSL on windows11.

Full mode for msedge,chromium and chrome are very slow on setup, the browser pops up but it stand for 20sec before anything happens, same on shutdown:

        "@vitest/browser-playwright": "^4.1.12",
        "@vitest/coverage-v8": "^4.1.11",
        "@vitest/ui": "^4.1.12",

sqlite> SELECT *,
       unixepoch(endTime) - unixepoch(startTime) AS duration_seconds
FROM testconfig
ORDER BY duration_seconds DESC;
+----+---------------------+---------------------+--------+----------+---------------+----------+--------+------------------+
| id |      startTime      |       endTime       |   ng   | browser  |    version    | runtype  | branch | duration_seconds |
+----+---------------------+---------------------+--------+----------+---------------+----------+--------+------------------+
| 3  | 2026-11-03 12:30:13 | 2026-11-03 12:38:29 | 22.2.4 | chrome   | 156.0.8078.47 | full     | main   | 496              |
| 2  | 2026-11-03 12:19:40 | 2026-11-03 12:27:54 | 22.2.4 | msedge   | 156.0.4314.58 | full     | main   | 494              |
| 7  | 2026-11-03 13:06:36 | 2026-11-03 13:14:46 | 22.2.4 | chromium | 156.0.8078.4  | full     | main   | 490              |
| 5  | 2026-11-03 12:42:13 | 2026-11-03 12:44:07 | 22.2.4 | firefox  | 157.0         | full     | main   | 114              |
| 6  | 2026-11-03 12:46:14 | 2026-11-03 12:48:05 | 22.2.4 | firefox  | 157.0         | headless | main   | 111              |
| 4  | 2026-11-03 12:40:06 | 2026-11-03 12:41:40 | 22.2.4 | chrome   | 156.0.8078.47 | headless | main   | 94               |
| 1  | 2026-11-03 12:17:59 | 2026-11-03 12:19:29 | 22.2.4 | msedge   | 156.0.4314.58 | headless | main   | 90               |
| 8  | 2026-11-03 13:15:09 | 2026-11-03 13:16:34 | 22.2.4 | chromium | 156.0.8078.4  | headless | main   | 85               |
+----+---------------------+---------------------+--------+----------+---------------+----------+--------+------------------+

Any idea how to debug this?

[amys94fr]

Interesting that Firefox is basically the same headed or headless while all 3 Chromium builds go from 90s to 490s. That makes me think it's Chromium + WSLg in the container rather than Vitest.

First thing I'd do is run with DEBUG=pw:browser, it logs Chromium's stderr with timestamps so you can see where it sits for those 20s:

DEBUG=pw:browser npx vitest --browser.headless=false

If the pause is right after something like Failed to connect to the bus, it's D-Bus. Chromium makes some D-Bus calls on startup and shutdown and if the bus is broken in the container they each hang until the 25s timeout, which would match what you're seeing. You can check by running it under its own bus (needs the dbus package):

dbus-run-session -- npx vitest --browser.headless=false

If it's not that, I'd try --disable-gpu, and then --ozone-platform=x11 / --ozone-platform=wayland, through the provider:

provider: playwright({
  launchOptions: { args: ['--disable-gpu'] },
}),

Also worth knowing: Vitest creates a new context per test file, and headed Chromium opens a window for each one. So if window creation is slow under WSLg you pay it once per file, not just at start/end. That's probably why the difference is 400s and not 40s.

[MAKHMUDuz]

Two details in your own data already point where to look, before touching Vitest at all.

What your table is telling you

• Headless is fine (85-94s) and Firefox headed is fine too (114s). Only Chromium-family headed explodes (490-496s, ~+400s).
• Your gap 7 vs 4 files is ~22 files at ~400s delta → roughly ~18-20s of overhead per test file in headed Chromium.
• That syncs exactly with your two observations (20s sitting idle at startup, similar stall at shutdown).

25s is the default D-Bus method-call timeout in libbus/libdbus, and amys94fr's D-Bus theory matches that number suspiciously well: a chromium family build that can't reach a session bus stalls right around 20-25s at startup and again at teardown. Firefox apparently doesn't hard-stall on a broken/absent session bus, which is why it's flat between headed and headless in your table. So: Chromium + container without a usable D-Bus session is the leading suspect — not Vitest, and not the browser itself.

Bisect it in two minutes (outside Vitest)

Before any config changes, isolate launch/shutdown from Vitest entirely. I've written and syntax-checked a tiny timing script (playwright-core only, let it use the same browsers the provider already downloads):

// bisect-launch.mjs  — npm i playwright-core (no browser download needed)
import { chromium, firefox } from 'playwright-core';
import { performance } from 'node:perf_hooks';

const round = async (name, launch) => {
  const t0 = performance.now();
  const b = await launch();               const t1 = performance.now();
  await b.close();                        const t2 = performance.now();
  console.log(`${name.padEnd(10)} launch=${((t1-t0)/1000).toFixed(1)}s shutdown=${((t2-t1)/1000).toFixed(1)}s`);
};

const args = process.argv[2] ? process.argv[2].split(' ') : [];
await round('chromium', () => chromium.launch({ headless: false, args }));
await round('firefox',  () => firefox.launch({  headless: false, args }));

Run it three ways:

node bisect-launch.mjs                          # baseline inside WSLg
dbus-run-session -- node bisect-launch.mjs      # fresh, private session bus (apt install dbus)
Xvfb :99 & DISPLAY=:99 node bisect-launch.mjs   # No WSLg window at all

If plain shows launch≈20s shutdown≈20s and dbus-run-session collapses it to ~1s, you're done diagnosing: it was the session bus, every time, for every file — that's your 400s.

Fixes, in order of least effort

1. Wrap the whole run in a private session bus — one command, no Vitest config:

dbus-run-session -- npx vitest --browser.headless=false

Chromium only needs a bus; it doesn't care that nothing is listening on it.

2. If dbus-run-session fixes the stall but headed Chromium still feels slow, the cost actually sits in WSLg's windowing (RDP per-window). Give the container its own X server instead:

Xvfb :99 -screen 0 1920x1080x24 & DISPLAY=:99 npx vitest --browser.headless=false

You keep full mode (identical semantics to headed for Vitest's purposes) with none of the WSLg per-window penalty. This is also the standard trick for CI "headed" parity on Linux.

3. If you want chromium-only knobs (they never hurt Firefox's numbers in your table anyway — it's already flat), pass them through the provider as amys94fr showed, e.g. --ozone-platform=x11 matters because WSLg bills you per window; forcing X11 inside its RDP pipeline is often the difference between 20s and instant.

Full credit to amys94fr for the D-Bus pointer; this reply just adds the numbers off your table (≈20s × 22 files ≈ your 400s), the 25s default D-Bus timeout that matches your observed stall, and the two bisect commands that tell you in two minutes whether it's the bus or WSLg. If the dbus-run-session run collapses to ~1s launch/shutdown and those are the numbers your CI sees, a vitest-level fix won't exist — there is nothing in Vitest to fix.

[mortenbj-statnett]

Thanks for the sum up. we switched from x11 to wslg a few weeks ago, because the x11 window-manager keeps crashing, but I try explicitly fixing it. We never need the full mode for other than debugging.