When running lhci autorun (specifically npm run lighthouse:assert) against a SvelteKit application with Server-Side Rendered (SSR) routes, the process rapidly exhausts available system Memory/RAM and crashes the development environment (IDE/Node background processes).
Even after explicitly throttling the Chrome instances using --concurrency=1 and limiting the URL pool, the headless Chrome subprocesses spawned by Lighthouse consume anomalous amounts of system resources before timing out or forcing an OS-level kill.
Steps to Reproduce
Initialize a SvelteKit 5 project with multiple SSR dynamic routes.
Configure .lighthouserc.cjs to target ~20 authenticated routing paths.
Utilize a puppeteerScript proxy to handle authentication state.
Run npx @lhci/cli autorun --config=./.lighthouserc.cjs --concurrency=1 inside the IDE terminal (e.g. VSCode, Cursor) or standard bash.
Observe task manager: node and headless Google Chrome for Testing instances stack indefinitely without garbage collection, leading to an Out-Of-Memory (OOM) crash.
Expected Behavior
When using the --concurrency=1 flag, lhci should strictly open a single Chrome tab, complete the audit, flush the memory/close the Chromium instance, and sequentially move to the next URL without bringing down the host OS or IDE terminal.
Current Behavior
Chrome/Node processes stack and hold memory between route audits until the entire environment crashes, making local lighthouse:assert checks impossible on standard development hardware.
Environment Information:
@lhci/cli version: 0.15.1
Framework: SvelteKit 2 / Svelte 5
Node Version: 22.19.0
OS: macOS
Puppeteer version: 24.37.5
When running lhci autorun (specifically npm run lighthouse:assert) against a SvelteKit application with Server-Side Rendered (SSR) routes, the process rapidly exhausts available system Memory/RAM and crashes the development environment (IDE/Node background processes).
Even after explicitly throttling the Chrome instances using --concurrency=1 and limiting the URL pool, the headless Chrome subprocesses spawned by Lighthouse consume anomalous amounts of system resources before timing out or forcing an OS-level kill.
Steps to Reproduce
Initialize a SvelteKit 5 project with multiple SSR dynamic routes.
Configure .lighthouserc.cjs to target ~20 authenticated routing paths.
Utilize a puppeteerScript proxy to handle authentication state.
Run npx @lhci/cli autorun --config=./.lighthouserc.cjs --concurrency=1 inside the IDE terminal (e.g. VSCode, Cursor) or standard bash.
Observe task manager: node and headless Google Chrome for Testing instances stack indefinitely without garbage collection, leading to an Out-Of-Memory (OOM) crash.
Expected Behavior
When using the --concurrency=1 flag, lhci should strictly open a single Chrome tab, complete the audit, flush the memory/close the Chromium instance, and sequentially move to the next URL without bringing down the host OS or IDE terminal.
Current Behavior
Chrome/Node processes stack and hold memory between route audits until the entire environment crashes, making local lighthouse:assert checks impossible on standard development hardware.
Environment Information:
@lhci/cli version: 0.15.1
Framework: SvelteKit 2 / Svelte 5
Node Version: 22.19.0
OS: macOS
Puppeteer version: 24.37.5