Memory Usage Increase in SvelteKit Apps After Multiple Navigations

[lightr4in]

Describe the bug

Hello,

I am writing to report an issue I have observed with SvelteKit applications, specifically regarding increased memory usage after navigating between a sub-page and the home page multiple times.

Issue Summary:

After navigating multiple times between a sub-page and the home page, there appears to be an increase in memory usage. This issue has been consistently reproduced in both svelte4 and svelte5 skeleton projects. While small increases in memory usage may not be a problem, working with larger amounts of data or strings in the app could make this issue more significant.

Expected Behavior:

Memory usage should remain relatively stable, with occasional spikes for garbage collection.

Observed Behavior:

Memory usage increases after multiple navigation events and does not appear to decrease, even after garbage collection. This increase is observed across various metrics, including compiled code, functions, objects, and strings.

Additional Information:

• I have tested this behavior in multiple browsers to ensure it is not an isolated issue.
• I understand that the application's memory usage may increase after initially calling the sub-page (once), but it seems that the increased usage continues to grow.
• The issue persists even after waiting minutes doing nothing, so garbage should definitely be collected.
• I tested adapter-auto and adapter-static, both seem affected.
• I am unable to determine if this issue is specific to SvelteKit or if it is related to another dependency.

I would appreciate any assistance in resolving this issue or guidance on further troubleshooting steps. Thank you for your attention to this matter.

Best regards, lightr4in

Reproduction

See the following repos: https://github.com/lightr4in/sveltekit-memory-leak-test It contains two folders memoryleak-bare-js (for svelte4) and memoryleak-bare-js-svelte5. While creating the projects, I disabled typescript and selected JSDoc as a compromise.

Preconditions: Clone the repo and open one of the directories mentioned above. Make sure you've run npm run build and npm run preview for testing this. You should probably run an isolated browser instance to avoid additional heap size due to the behavior of some extensions.

1. Clone the provided repository using git clone https://github.com/lightr4in/sveltekit-memory-leak-test. Move into either the memoryleak-test-bare-js or memoryleak-test-bare-js-svelte5 directory.
2. Run npm install; npm run build; npm run preview.
3. Open the application in a clean Chrome instance, typically at http://localhost:4173/.
4. Open the Memory tab inside DevTools (Ctrl + Shift + i).
5. Navigate multiple times between the sub-page and the home page, returning to the home page each time.
6. Wait approximately 10 seconds for garbage collection to occur.
7. Create a heap snapshot.
8. Monitor the memory usage of the application.
9. Repeat steps 5-8 multiple times and observe the deltas.

Logs

No response

System Info

System:
    OS: Linux 6.1 LMDE 6 (faye) 6 (faye)
    CPU: (16) x64 AMD Ryzen 7 3800XT 8-Core Processor
    Memory: 16.19 GB / 31.26 GB
    Container: Yes
    Shell: 5.9 - /usr/bin/zsh
  Binaries:
    Node: 22.1.0 - ~/.nvm/versions/node/v22.1.0/bin/node
    npm: 10.7.0 - ~/.nvm/versions/node/v22.1.0/bin/npm
    pnpm: 9.4.0 - ~/.nvm/versions/node/v22.1.0/bin/pnpm
  npmPackages:
    @sveltejs/adapter-auto: ^3.0.0 => 3.2.2 
    @sveltejs/kit: ^2.0.0 => 2.5.17 
    @sveltejs/vite-plugin-svelte: ^3.0.0 => 3.1.1 
    svelte: ^4.2.7 => 4.2.18 
    vite: ^5.0.3 => 5.3.2 

  Browsers:

    Ungoogled Chromium: 126.0.6478.126
    LibreWolf (FF derivative): 127.0.2-1

Severity

blocking all usage of SvelteKit

Additional Information

Some may consider this more of an annoyance than a critical issue, but as a developer focused on building stable and complex web applications that can run for extended periods, I believe it is important to address memory robustness in web technologies. Ensuring that applications maintain stable memory usage is crucial for providing a reliable user experience, especially for long-running and frequently used applications.