Two steps consume 187 of the 198 seconds in Playwright's default CI run

Start with where the 198 seconds went. The browser install step took 42 seconds and the test step took 2m 25s ^[5][6], which is 187 of the 198 seconds in the baseline run ^[21]. Checkout, Node setup and `npm ci` came in at a second or two each and account for the remaining 11 ^[8][22]. Two config edits therefore sit on top of about 94 percent of the measured time in that repo ^[21].

Whether the split transfers depends on the shape of your suite. The download is a fixed cost: Chromium, Firefox and WebKit plus their system libraries, on every run, whether or not the browsers changed ^[5]. On a suite that takes 20 minutes, that same 42 seconds is roughly 3.5 percent of wall clock ^[24], and worker count is the only setting left that changes wall clock much.

Playwright puts its binaries in `~/.cache/ms-playwright`, which on the Linux runner resolves to `/home/runner/.cache/ms-playwright`, and that directory is what `actions/cache@v6` restores ^[14][15]. The key is `runner.os` plus a hash of `package-lock.json`, which the post calls a proxy for the Playwright version ^[15]. Any change to the lockfile produces a new key, so a bump to an unrelated dependency buys you a fresh browser download ^[27]. On a hit the workflow still runs `npx playwright install-deps`, because the restored binaries need system libraries that were never in the cache ^[16]. The original 42 seconds covered the download and those libraries together, so the recovered time is smaller than 42 seconds; the published excerpt does not report a measured time for the fixed run ^[5][30].

The generated config pins CI to one worker with `workers: process.env.CI ? 1 : undefined`, so the suite runs close to one test at a time even with idle cores ^[7]. The fix is one line. The recommended value is `"50%"`, scaled to the runner, with a comment in the config telling you to measure and raise from there ^[9]. `fullyParallel: true` belongs next to it, since it parallelises tests within a file and not only across files ^[10]. Under one worker, `fullyParallel` does nothing for wall clock ^[23].

Two other defaults push against the five-minute target. `retries: 2` in CI lets a flaky test run three times inside the same budget ^[11][28], and `trace: "on-first-retry"` means the attempt that first fails produces no trace to look at ^[12][29]. `forbidOnly` I would keep whatever it costs: with CI set, a committed `test.only` fails the build instead of passing a suite of one ^[13].

The five-minute promise deserves a check against the baseline. 3m 18s was already under five minutes before either edit landed ^[3][26], and the post says to treat that figure as "a fixed number for comparing fixes, not a prediction of your own run times" ^[4].