The JavaScript memory heap is a region of memory where objects, strings, closures, and other dynamic data are stored during script execution. Unlike the call stack (which handles function calls with LIFO), the heap is an unstructured memory pool managed by the garbage collector. When you create objects with new, declare variables, or define functions, memory is allocated on the heap.

performance.memory is a non-standard Chrome-specific API that provides real-time information about the JavaScript heap. It exposes three properties: usedJSHeapSize (currently used memory), totalJSHeapSize (total allocated heap, including free space within the heap), and jsHeapSizeLimit (maximum heap size the browser allows). This API is available in Chromium-based browsers like Chrome, Edge, and Opera.

usedJSHeapSize reflects the memory actively occupied by live objects and data. totalJSHeapSize is larger because it includes free space that the heap has reserved from the operating system but hasn't yet filled. The gap between them represents memory that the heap can use without requesting more from the OS. If usedJSHeapSize approaches totalJSHeapSize, the browser will expand the heap (up to jsHeapSizeLimit).

Common memory leak sources include: 1) Forgotten timers or intervals (setInterval without clearInterval); 2) Detached DOM elements still referenced in JavaScript variables; 3) Global variables that accumulate data over time; 4) Closures that retain references to large outer-scope objects; 5) Event listeners not removed when elements are destroyed; 6) Large caches or collections that grow without bound; 7) WebSocket or subscription callbacks not unsubscribed. Use this tool to monitor if heap usage continuously climbs without dropping — that's a strong leak indicator.

JavaScript does not expose a standard GC trigger. In Chrome, you can use window.gc() only if Chrome was launched with the flag --js-flags="--expose-gc". For regular browsing, the best approach is to open Chrome DevTools (F12), go to the Performance or Memory tab, and click the trash icon 🗑️ to force a garbage collection cycle. Alternatively, reducing references to large objects naturally allows the GC to reclaim memory on its next automatic cycle.

A healthy ratio of usedJSHeapSize to jsHeapSizeLimit is typically below 50-60%. If usage consistently exceeds 75%, consider optimizing your code. However, the absolute numbers matter more than ratios — a small app using 20 MB is fine, while a complex web app might use 200+ MB normally. Watch for trends: if memory climbs steadily without ever dropping, you likely have a leak.

Strategies to reduce heap usage: 1) Use object pooling for frequently created/destroyed objects; 2) Avoid storing large datasets in memory — use pagination, streaming, or IndexedDB; 3) Nullify references when objects are no longer needed; 4) Use WeakMap and WeakSet for caches that should not prevent GC; 5) Break large closures into smaller scopes; 6) Clean up event listeners and observers; 7) Use typed arrays (ArrayBuffer) efficiently and release them with .transfer() or by nullifying.

Currently, only Chromium-based browsers support performance.memory: Google Chrome, Microsoft Edge, Opera, Brave, Vivaldi, and Arc. Firefox and Safari do not expose this API. For cross-browser memory profiling, use the browser's built-in DevTools (Memory tab in Chrome/Edge, Performance tab in Firefox, or the Web Inspector in Safari).