Slow test execution start on local

[rkgour7492]

I've recently started noticing very slow execution when running tests with npx codeceptjs run --steps --grep.

If I rerun immediately after a slow run, it's faster — but if I wait a few minutes and run again, it starts slow again. I also tried running with --verbose, but there's nothing meaningful logged before actual execution starts.

Environment:

Node: 24.16.0
OS: Windows 11 10.0.26200
CPU: (24) x64 12th Gen Intel(R) Core(TM) i9-12950HX
Chrome: Not Found
Edge: Chromium (151.0.4129.93)
Firefox: undefined
Safari: N/A

[AlakhiarovSalekh]

The "slow once, fast again immediately, then slow again after some idle time" pattern makes me suspect the startup layer rather than the test itself.

I would isolate it in this order.

First, bypass npx completely on Windows:

.\node_modules.bin\codeceptjs.cmd run --steps --grep "..."

If that is consistently fast while:

npx codeceptjs run --steps --grep "..."

is slow, the delay is in npm/npx resolution rather than CodeceptJS.

If both are slow, try a command that initializes CodeceptJS but does not start the browser/tests, and time that separately. If the delay still happens before CodeceptJS prints its normal startup output, check Windows Defender / endpoint security scanning of the project and node_modules. Cold filesystem/AV scanning can produce exactly the "first run slow, immediate rerun fast" pattern.

I would not disable Defender globally. As a diagnostic, temporarily test with the project directory excluded (if your environment allows it) and compare timings.

Also compare Node 24 with the current Node LTS supported by your project. If the issue disappears on LTS, that gives you a useful reproduction point.

In short:

1. bypass npx;
2. separate CodeceptJS startup from browser/test startup;
3. compare warm vs cold filesystem/Defender behaviour;
4. compare Node versions.

The fact that --verbose shows nothing during the delay is useful evidence: the stall is likely happening before normal test execution logging starts.

[Icaro0310]

That slow-then-fast-then-slow pattern on Windows is almost always real-time AV scanning, not CodeceptJS. Defender rescans node_modules and each spawned node process, and the results get cached briefly, which is why an immediate rerun is fast but waiting a few minutes makes it cold again.

Add an exclusion for the project folder (elevated PowerShell):

Add-MpPreference -ExclusionPath "C:\path\to\project"

Two other things worth trying: skip npx, since on Windows it goes through a cmd shim and adds noticeable startup time, and call the bin directly with node node_modules/codeceptjs/bin/codecept.js run --steps. You can also set NODE_COMPILE_CACHE to a writable dir so Node reuses its compile cache between runs. If it's still slow after that, time how long the helper's browser launch takes, since Playwright startup can dominate on a cold boot too.

—
Check out my Repositories: github.com/Icaro0310 · Website: icaro0310.github.io