Por que o Chrome devora RAM: as razões reais por trás da fome

Um processo por site: a história toda numa linha

O Chromium reparte o navegador em muitos processos do sistema: renderizadores para as abas — um por site (o isolamento de sites coloca sites diferentes em processos diferentes mesmo dentro de uma única aba) —, um processo de GPU, um serviço de rede, um serviço de armazenamento e um processo por extensão carregada. O objetivo é conter o estrago: um renderizador que cai leva uma aba, não o navegador, e um renderizador comprometido não tem acesso direto aos outros sites. O custo é a sobrecarga de cada processo, então vinte sites abertos são vinte mini-Chromium, cada um com sua fatia de bibliotecas, heaps de JIT e buffers de renderização.

A soma cresce mais rápido do que se espera, porque no número não entram só as abas:

• Um processo renderizador por site — dez sites em dez abas, mais os embutidos de outros domínios
• Cada extensão ativada mantém um processo próprio em segundo plano, mesmo em repouso
• O processo de GPU segura imagens decodificadas, ladrilhos e quadros de vídeo — uma aba de YouTube em 4K é basicamente isso
• Os service workers continuam vivos depois que você fecha a aba deles, prontos para os apps offline
• As páginas pré-carregadas das sugestões da omnibox e o pré-render ocupam memória antes mesmo da visita

Por que o Chrome não devolve a memória

A segunda razão é o alocador do Chromium, o PartitionAlloc, que põe em cache as páginas liberadas dentro de cada processo para reaproveitar na hora, em vez de devolvê-las ao Windows. O Gerenciador de Tarefas mostra esse pool como parte da pegada do Chrome embora ele esteja tecnicamente livre — o número parece mais assustador do que a pressão real no sistema. Sob pressão de verdade o navegador solta memória sim — por isso o Chrome se recupera quando você fecha um app pesado —, mas numa máquina ociosa ele segura de propósito o que já pagou.

Parte da memória retida é cache no sentido honesto: o cache de avanço/retorno guarda páginas renderizadas para o botão Voltar ser instantâneo, e os mapeamentos do cache de disco evitam reler arquivos. Por isso um navegador aberto há dias pesa mais que um recém-iniciado: ele simplesmente cacheou mais coisas que valem a pena guardar. É o argumento da RAM parada é RAM desperdiçada, e por uma vez ele é tecnicamente verdadeiro — a alternativa é renderizar de novo cada página que você revisita.

O que realmente encolhe a pegada

Ative a Economia de memória em chrome://settings/performance: ela põe as abas inativas para dormir e libera os renderizadores delas — a maior alavanca que existe numa sessão cheia de abas. Depois audite os culpados reais: aperte Shift+Esc para abrir o gerenciador de tarefas do próprio Chrome e ordene por memória — na maioria das vezes um único site pesado (uma IDE web, uma chamada de vídeo, um webmail inchado) ou uma extensão pesa mais que quarenta abas comuns. Extensões merecem suspeita especial: cada uma adiciona um processo a cada janela, e muitas rodam sem parar.

Depois disso, a resposta honesta é aritmética, não mágica: menos abas dormindo, menos extensões, nenhum painel fixado para sempre que ninguém lê. Alternar a aceleração de hardware troca memória de GPU por carga de CPU — às vezes ganha com uma gráfica integrada fraca, às vezes o contrário. O que não funciona: os limpadores de RAM que cortam à força os conjuntos de trabalho — o número cai e o navegador engasga enquanto busca de novo o que foi cortado.

Perguntas e respostas

Continue lendo