Nuxt•9mo ago

Question about consistently increasing number of nodes, listeners and heap? Is this a memory leak?

Was doing some performance profiling because I was experiencing the memory leak issue in nuxt/devtools with Node V22. (this issue https://github.com/nuxt/devtools/issues/761#issuecomment-2545569905). So the following observations are with dev tools turned OFF in local development. Or in a deployed production environment.

My question is why are the number of nodes, and therefore listeners and heap size consistently increasing? See memory profile screenshots from chrome devtools.

I'm not saying this is a problem because the experience of using the website is still fast and snappy. But I'm curious if this would technically be a memory leak because the heap is still trending upwards as you can see in the screenshots.

Out of curiosity I profiled the deployed site on ui.nuxt.com and observed the same pattern.

First photo is my application in local dev, with devools turned off.

Second photo is the production ui.nuxt.com website as a sanity check. Displays same pattern of consistently increasing nodes and heap size.

The way I tested was just using the site and clicking a bunch of random links and buttons.

Let me know if there is more profiling info you need.

GitHub

fix: devtools is causing a severe memory leak · Issue #761 · nuxt/d...

The bug Creating a bare Nuxt project with npx nuxi@latest init project and starting it with npm run dev causes severe memory leak (most of the time). This happens on Windows with Node v22+. This ...

kapa.ai•3/24/25, 2:34 AM

Hi @AGill. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base.

kapa.ai•3/24/25, 2:34 AM

----------------------
Based on your observations about increasing nodes, listeners, and heap size in both your Nuxt application and the ui.nuxt.com site, this does appear to be a known memory management issue in Nuxt applications.

What you're experiencing is likely related to several memory management challenges that have been documented in the Nuxt ecosystem:

Memory leaks in development mode: There's a known issue with Node v22 and Nuxt devtools causing memory leaks, as you mentioned in the GitHub issue you referenced. However, you're seeing this behavior even with devtools turned off, which suggests a more fundamental issue.
Server-side memory management: Nuxt applications can experience memory growth over time, especially in server-side rendering (SSR) mode. This has been reported in several issues, including one where users had to restart their PM2 instances regularly because memory usage kept growing on GitHub Issue #31180.
Sourcemap and build process issues: Some memory issues are related to how Nuxt handles sourcemaps between Vite and Nitro builds, as discussed in a recent pull request.
Payload caching: A recent performance improvement in Nuxt addressed how payloads are cached, noting that "previously the payload cache was never cleared and just increased in memory" in PR #31379.

The pattern you're observing (increasing nodes and heap size) is consistent with what others have reported. Some users have found that memory usage in Nuxt applications continues to grow until they need to restart their servers, particularly in production environments using PM2 on Linux systems.

kapa.ai•3/24/25, 2:34 AM

For production deployments, some users have reported "out of memory" errors during builds on platforms like Netlify, as seen in GitHub Issue #21023.

While the continuous growth in nodes and heap size could technically be considered a memory leak, it might also be related to how Nuxt handles caching, component lifecycle, or route changes. The Nuxt team has been working on several improvements to address memory management issues, including better payload caching and fixing memory leaks in components like as seen in PR #26928.

If you're concerned about this behavior, you might want to:

Create a minimal reproduction case and report it on the Nuxt GitHub repository
Consider downgrading to Node 20 as a temporary workaround (as suggested for similar issues)
Implement regular server restarts if you're using PM2 in production

Would you like more specific guidance on any of these approaches?
----------------------
Note: you can ask me a follow up question by @ mentioning me again

----------------------

kapa.ai•3/24/25, 2:34 AM

@508382519146709018 Kapa.ai is still learning and improving, please let me know how I did by reacting below.

AGillOP•3/24/25, 2:37 AM

@kapa.ai can you give me more details on point number 3 and 4 above? Sourcemap + build process issues and payload caching.

Because I'm trying to understand increasing heap size in Chrome devtools. So the issue is memory on the client side and not server side.

kapa.ai•3/24/25, 2:37 AM

Let me check the knowledge base for you again. One moment!

kapa.ai•3/24/25, 2:38 AM

----------------------
I'll provide more details on the sourcemap/build process issues and payload caching as they relate to client-side memory usage in Nuxt applications.

Sourcemap & Build Process Issues

Sourcemaps in Nuxt can affect client-side memory usage because they're included in the browser bundle when enabled. By default, Nuxt configures sourcemaps differently for client and server:

However, you can enable client-side sourcemaps in your

nuxt.config.ts

nuxt.config.ts

file:

When client sourcemaps are enabled, they can significantly increase memory usage in the browser because:

The browser needs to load and parse these additional files
The sourcemaps themselves can be quite large, especially for complex applications
They remain in memory for debugging purposes

As noted in a GitHub PR about preserving sourcemaps, Nuxt has two build processes (Vite/webpack build followed by Nitro build), which can lead to inefficient sourcemap handling. While this PR focused on server-side sourcemaps, similar issues can affect client-side builds.

Payload Caching

This is likely the more significant factor in your observed client-side memory growth. The payload in Nuxt (sometimes referred to as ) contains data that's transferred from server to client during hydration.

A recent performance improvement in PR #31379 addressed a critical issue: "previously the payload cache was never cleared and just increased in memory." This means that as users navigated through your application:

kapa.ai•3/24/25, 2:38 AM

Each new page's payload was fetched and stored in memory
These payloads were never garbage collected
Memory usage would continuously grow with each navigation

Alexander Lichter created a detailed video about this issue titled "Reduce the size of your payload and NUXT

Nuxt Performance in Depth"

which explains how the payload can grow and how to optimize it.

The PR mentioned above changed how Nuxt handles payloads to use browser caching instead of keeping everything in memory. This allows the browser to manage the cache and clean it up when needed.

How This Affects Client-Side Memory

When you observe increasing heap size in Chrome DevTools while navigating a Nuxt application, you're likely seeing:

Accumulated payloads: Each page navigation adds data to memory that isn't properly cleaned up
Component instances: Vue components that aren't properly destroyed
Event listeners: Listeners that remain attached even after components should be unmounted

The increasing node count you observed suggests that DOM elements or Vue component instances aren't being properly garbage collected. This is consistent with memory management issues in the payload system.

If you're using a recent version of Nuxt (3.8+), some of these issues may have been addressed. If not, you might want to:

Update to the latest Nuxt version
Minimize the size of your payloads (avoid storing large objects in or )
Consider implementing manual cleanup in components with large data structures

Would you like more specific guidance on optimizing payload size or debugging memory issues in your specific application?
----------------------
Note: you can ask me a follow up question by @ mentioning me again

----------------------

kapa.ai•3/24/25, 2:38 AM

@508382519146709018 Kapa.ai is still learning and improving, please let me know how I did by reacting below.