Electron gets a reputation, fair or not, as a memory hog. "It's just a browser tab pretending to be an app" is the usual jab, and there's truth buried in the joke: every Electron app bundles a full Chromium renderer and a Node.js runtime, so the baseline cost of "hello world" is already higher than a native toolkit. But the gap between a lean Electron app and a bloated one is enormous, and almost all of it comes down to decisions developers make, not limitations of the framework itself. This article walks through where that memory actually goes and what you can do about it.

Where the Memory Goes

An Electron app is really two runtimes stitched together: the main process, which is a Node.js environment with access to the OS, and one or more renderer processes, each of which is a full Chromium browser tab. Every BrowserWindow you create spins up a new renderer, and each renderer carries its own V8 heap, its own DOM, its own layout and paint pipeline. Open five windows and you're not paying for one Chromium instance five times more efficiently — you're paying for five nearly-independent Chromium instances.

On top of that baseline, three things tend to inflate memory usage in practice:

1. Unbounded renderer count. Apps that spawn a hidden BrowserWindow per background task, per notification, or per preview thumbnail accumulate renderers that never get destroyed.

2. Node integration in renderers. Enabling nodeIntegration gives every renderer a full Node.js context alongside Chromium's own JS engine overhead, and it's also a security liability (more on that below).

3. Leaky listeners across IPC. Main-process listeners registered per-window via ipcMain.on and never removed on window-closed keep references alive indefinitely, pinning down whatever closures they captured.

Practical Steps That Actually Move the Needle

Treat BrowserWindows like a scarce resource

Don't create a window to do work that doesn't need a screen. If you need HTML-to-PDF rendering or headless scraping, consider BrowserWindow with show: false only when unavoidable, and destroy it explicitly with win.destroy() the moment the task finishes rather than trusting garbage collection to catch a still-referenced object.

js

const win = new BrowserWindow({ show: false });
await win.loadURL(url);
const pdf = await win.webContents.printToPDF({});
win.destroy(); // don't wait for GC

Turn off what you don't need

contextIsolation: true and nodeIntegration: false should be your defaults in every webPreferences block. Beyond the well-documented security benefits, isolating the renderer's JS context from Node means Chromium's V8 instance isn't also dragging along Node's module system and global objects in every window.

js

new BrowserWindow({
webPreferences: {
    contextIsolation: true,
    nodeIntegration: false,
    sandbox: true,
    preload: path.join(__dirname, 'preload.js'),
},
});

Expose only the specific functions the renderer needs via contextBridge in your preload script, instead of the whole ipcRenderer object.

Clean up IPC listeners on window close

Every ipcMain.on or ipcMain.handle registered inside a window-creation function should have a matching teardown when that window closes. A common pattern is to namespace listeners per window and strip them in the closed event:

js

win.on('closed', () => {
ipcMain.removeAllListeners(`window-${win.id}-update`);
});

Use webContents.forcefullyCrashRenderer() sparingly, and will-navigate guards liberally

Renderers that load arbitrary or attacker-influenced URLs can balloon in memory usage if left unchecked, and they're also your biggest attack surface. Restrict navigation with will-navigate and setWindowOpenHandler so a stray window.open() from a webpage doesn't spawn a new full Chromium process you never intended to create.

Profile with the tools Chromium already gives you

Electron exposes Chromium's DevTools memory profiler for free. Open DevTools on any renderer (win.webContents.openDevTools()), go to the Memory tab, and take heap snapshots before and after a suspected leak scenario — opening and closing a modal, switching views, etc. Diffing two snapshots is usually enough to spot detached DOM trees or retained closures. For the main process, process.memoryUsage() logged on an interval, or a tool like electron-log combined with Node's built-in --inspect flag, gets you most of the way to a native Node debugging workflow.

Consider V8's --max-old-space-size only as a last resort

You can cap V8's heap size per renderer via command-line switches, but this doesn't reduce actual memory needs — it just forces more aggressive garbage collection, which trades memory for CPU and can introduce jank. Treat it as a stopgap while you find the real leak, not a fix.

The Bigger Picture

None of this makes an Electron app as lean as a native Cocoa or Win32 binary, and it isn't meant to. The tradeoff you're making by choosing Electron is developer velocity and cross-platform reach in exchange for a heavier baseline footprint. What separates a well-regarded Electron app (VS Code, Slack in its better days, Obsidian) from a maligned one is almost always process discipline: fewer renderers, tighter isolation, and listeners that get cleaned up as diligently as they get created. The framework gives you the tools to be efficient. Whether you use them is a separate question.