Por qué Chrome devora la RAM: las razones reales de su apetito

Un proceso por sitio: toda la historia en una línea

Chromium divide el navegador en muchos procesos del sistema: renderizadores para las pestañas, uno por sitio (el aislamiento de sitios reparte sitios distintos en procesos distintos incluso dentro de una misma pestaña), un proceso de GPU, un servicio de red, un servicio de almacenamiento y un proceso por cada extensión cargada. El objetivo es contener el daño: un renderizador que cae se lleva una pestaña, no el navegador, y un renderizador comprometido no tiene acceso directo a otros sitios. El costo es que cada proceso arrastra su propia sobrecarga, así que veinte sitios abiertos son veinte mini-Chromium, cada uno con su parte de bibliotecas, montones JIT y búferes de renderizado.

La suma crece más rápido de lo que se espera, porque en la cifra no solo entran las pestañas:

• Un proceso renderizador por sitio — diez sitios en diez pestañas, más los incrustados desde otros dominios
• Cada extensión activada mantiene su propio proceso en segundo plano, incluso en reposo
• El proceso de GPU guarda imágenes decodificadas, teselas y fotogramas — una pestaña de YouTube en 4K es sobre todo esto
• Los service workers siguen vivos tras cerrar su pestaña, listos para las apps offline
• Las páginas precargadas de las sugerencias de la omnibox y el prerender ocupan memoria antes incluso de que las visites

Por qué Chrome no devuelve la memoria

La segunda razón es el asignador de Chromium, PartitionAlloc, que cachea las páginas liberadas dentro de cada proceso para reutilizarlas al instante en lugar de devolverlas a Windows. El Administrador de tareas muestra ese grupo como parte de la huella de Chrome aunque técnicamente está libre, y la cifra asusta más de lo que presiona al sistema. Bajo presión real el navegador sí suelta memoria — por eso Chrome «se recupera» al cerrar una app pesada —, pero en una máquina ociosa retiene a propósito lo que ya ha pagado.

Parte de esa memoria retenida es caché en el sentido honesto: la caché de avance/retroceso conserva páginas renderizadas para que el botón Atrás sea instantáneo, y las asignaciones del caché de disco evitan releer archivos. Por eso un navegador que lleva días abierto pesa más que uno recién iniciado: simplemente ha cacheado más cosas que valen la pena conservar. Es el argumento de «la RAM sin usar es RAM desperdiciada», y por una vez es técnicamente cierto: la alternativa es volver a renderizar cada página que revisitas.

Lo que de verdad encoge la huella

Activa el Ahorro de memoria en chrome://settings/performance: duerme las pestañas inactivas y libera sus renderizadores, la palanca más grande en una sesión con muchas pestañas. Después audita a los culpables reales: pulsa Shift+Esc para abrir el propio administrador de tareas de Chrome y ordena por memoria — en la mayoría de los casos un solo sitio pesado (una IDE web, una videollamada, un webmail hinchado) o una extensión pesa más que cuarenta pestañas normales. Las extensiones merecen sospecha especial: cada una añade un proceso a cada ventana y muchas corren sin parar.

Después de eso, la respuesta honesta es aritmética y no magia: menos pestañas dormidas, menos extensiones, ningún panel anclado para siempre que nadie lee. Alternar la aceleración por hardware cambia memoria de GPU por carga de CPU — a veces gana con una gráfica integrada débil, a veces al revés. Lo que no funciona: los «limpiadores de RAM» que recortan a la fuerza los conjuntos de trabajo; la cifra baja y el navegador tartamudea mientras rebusca lo recortado.

Preguntas y respuestas

Sigue leyendo