La pestaña del navegador de tu usuario se congela después de treinta minutos. La interfaz de usuario presenta tirones. Luego el navegador se cierra con un error de memoria insuficiente

Your user's browser tab freezes after thirty minutes. The UI stutters. Then the browser crashes with an out-of-memory error.

You review the component code line by line and see nothing wrong. That is the maddening part of memory leaks in React. The bug does not live in your JSX syntax or your hook logic. It lives in the gap between your component and the browser's garbage collector. A stray event listener or a long-lived closure stops the collector from reclaiming memory. You unmount a component, but a single lingering reference keeps the entire tree alive in the heap. You cannot find these leaks by just reading code. The problem stays hidden under the surface, invisible to the eye and silent in unit tests.

Why Leaks Hide in Plain Sight

JavaScript engines like V8 manage memory automatically. When no reference path exists from the root to an object, the engine marks that object as garbage and reclaims the space. This process works well until a hidden reference survives longer than you intended.

In React, the danger often appears at the boundary between components and the DOM. You might attach a resize listener to the window inside a modal, or subscribe to a WebSocket in a dashboard widget. When the user closes the modal or navigates away, the component unmounts. If the subscription survives, the engine sees a valid reference from the global window object down to your handler, and from your handler back into the component's closure. The component, its props, its state, and its entire subtree of DOM nodes stay pinned in memory. Over hundreds of interactions, these pinned objects accumulate. Memory usage climbs in a sawtooth pattern that never fully drops back down.

The Enterprise Dashboard Problem

This happens most in enterprise dashboards where users stay on one page for hours. Think of monitoring panels, analytics views, or ticketing systems. A user opens a detail modal, filters a large dataset, or switches tabs within a single-page app. Each individual interaction feels fine. Over time, though, orphaned nodes and detached listeners accumulate. The application slows not because of a single expensive render, but because the heap grows large enough to trigger frequent and expensive garbage collection pauses.

Stop guessing about your useEffect hooks. The only way to know if a leak exists is to measure the heap directly. Chrome DevTools gives you that visibility.

Hunting Leaks with Chrome DevTools

You need a reproducible sequence and a few minutes of focused attention. Open your application in Chrome, launch DevTools, and navigate to the Memory tab.

Record a baseline. Select Heap snapshot and click Take snapshot. This captures every object currently living in the JavaScript heap and shows you the starting memory. Do this after the page has settled into its initial idle state, not during initial load, so you measure only the growth caused by user actions.

Trigger the action. Perform the exact UI interaction you suspect causes the leak. Open and close a modal, toggle a complex chart, or change a route and navigate back. Once finished, return the app to its original visual state. This step is crucial. You want the UI to look identical to how it looked during the baseline. If the heap has grown despite the UI appearing empty, you have strong evidence of a leak.

Force garbage collection. Click the trash can icon in the Memory tab. This triggers a full GC cycle and clears temporary objects that legitimately survived until the next collection. What remains are the real leaks, objects that should have been collected but were held alive by accidental references.

Take a second snapshot. Click Take snapshot again. You now have two photographs of the heap taken under the same UI conditions.

Compare results. Change the view from Summary to Comparison. Set the baseline to your first snapshot and the compared snapshot to the second. The Comparison view lists every object category and shows you the delta, the net change in object counts between the two captures.

Sort by Delta. Look for categories that increased significantly. Focus especially on Detached HTMLElement and React fiber nodes. A detached HTML element is a DOM node that is no longer attached to the active document tree, yet some JavaScript reference still holds it. These are smoking guns. They should not exist after you have closed a modal or unmounted a component.

Reading the Retaining Path

Cuando seleccionas un elemento desvinculado en la instantánea, Chrome muestra la ruta de retención en el panel inferior. Esta ruta es una cadena de referencias desde la raíz hasta el objeto seleccionado. Síguela con cuidado. A menudo encontrarás un listener de eventos, un IntersectionObserver, un ID de setInterval o un closure que apunta a una línea específica de tu componente.

Busca nombres que reconozcas. Si ves un listener conectado a window con un nombre de función de tu base de código, habrás encontrado el ancla. El objeto que contiene ese listener está manteniendo vivo todo tu componente. A veces, la cadena pasa a través de una librería de terceros. En esos casos, comprueba si la librería espera una llamada de desmantelamiento (teardown) explícita que olvidaste invocar en una función de limpieza (cleanup function).

Corregir las causas raíz

Una vez que identifiques la ruta de retención, la solución suele ser mecánica, pero requiere disciplina en todo el equipo.

Usa funciones de limpieza. Devuelve siempre una función de limpieza en useEffect cuando añadas listeners a window o document. Si tu efecto se suscribe a un evento de redimensionamiento (resize), elimina esa suscripción antes de que el componente se desmonte. La limpieza se ejecuta cuando React desmantela el componente, lo que te proporciona un hook garantizado para cortar las conexiones externas.

Estabiliza las referencias. Envuelve tus manejadores (handlers) en useCallback. Esto asegura que pases exactamente la misma referencia de función a removeEventListener que pasaste originalmente a addEventListener. Si registras una función en línea como window.addEventListener('resize', () => { ... }) e intentas eliminarla más tarde con otra función en línea, las referencias no coincidirán. El listener permanecerá conectado. El closure en su interior mantiene vivo el estado de tu componente. useCallback con un array de dependencias estable evita este desajuste de identidad.

Corta los enlaces globales. Recuerda que los objetos de destino de eventos del navegador, como window y document, viven durante toda la vida de la página. Cualquier referencia desde ellos hacia tu componente actúa como un ancla global. Eliminar el listener rompe ese ancla y permite que el motor V8 elimine el estado del componente y los nodos del DOM durante el siguiente ciclo de recolección de basura (garbage collection).

Considera un modal que rastrea el ancho de la ventana. Sin una función de limpieza, cada vez que el usuario abre el modal, se conecta un nuevo listener. Los antiguos nunca se desconectan porque las instancias del componente a las que pertenecen han desaparecido, pero las funciones en sí eran anónimas y se perdieron. Usar un manejador con nombre envuelto en useCallback, además de una función de limpieza que llame a removeEventListener, cierra el ciclo de forma limpia.

Una conclusión real

Las fugas de memoria (memory leaks) en React rara vez se anuncian con un mensaje de error claro. Se anuncian con una pestaña que se vuelve más pesada cuanto más tiempo permanece abierta. No pierdas tiempo especulando sobre qué hook es el culpable. Abre la pestaña Memory, fuerza la recolección de basura y compara las instantáneas (snapshots). Deja que el heap profiler te muestre la ruta de retención exacta. Luego, escribe la función de limpieza, estabiliza la referencia del callback y corta el enlace global. Tus usuarios no notarán la corrección directamente, pero notarán que el dashboard sigue funcionando sin problemas al final del día.