Por que os navegadores engordam todo ano

O isolamento multiplicou tudo

Desde o endurecimento da era Spectre, o Chromium roda cada site no próprio processo, e o Firefox seguiu com a própria divisão por site. Uma sessão de quinze abas com um par de extensões é facilmente vinte e cinco processos ou mais: o navegador em si, o processo de GPU, o serviço de rede e um renderizador por site. O isolamento por site é segurança de verdade: um renderizador comprometido não consegue ler os dados de outro site. Mas cada processo paga o preço cheio da pilha de renderização, e as mesmas quinze abas que em 2014 viviam num processo hoje pagam a entrada quinze vezes.

Extensões também são processos. Desde o Manifest V3 elas funcionam como service workers orientados a eventos: acordam quando as regras delas pedem e mantêm content scripts injetados em cada página que você abre. Uma dúzia de extensões «pequenas» pesa como várias abas extras, e uma só mal-comportada pode comer mais que todas juntas. O gerenciador de tarefas interno do Chrome (Shift+Esc) mostra o custo por aba e por extensão, com os nomes — cinco minutos lá valem mais que qualquer conselho genérico.

A plataforma só sabe crescer

Um navegador entrega o mesmo binário para todo mundo, e dentro dele vai tudo o que a web moderna sabe fazer: WebGPU, WebAssembly, WebRTC, WebCodecs, service workers, aplicativos instaláveis. Tirar uma funcionalidade é quase impossível — em algum lugar um banco ou uma intranet ainda depende da API de 2013 — então o motor só acumula. Cada versão ainda atualiza componentes em segundo plano: codecs, a pilha de rede, as listas de navegação segura; o navegador que você não reiniciou ontem se corrigiu sozinho três vezes.

As próprias páginas web engordaram no mesmo ritmo. Uma página média despeja megas de JavaScript antes de mostrar qualquer conteúdo, publicidade e analytics viajam por cima, e um site de notícias «leve» carrega cem scripts sem esforço. O navegador é honesto sobre cujo peso ele carrega — abra o gerenciador de tarefas interno e compare uma página de documentação com uma loja. O motor engordou, mas a carga cresceu mais rápido.

• Um engine de JavaScript completo com JIT — cada processo paga o compilador, não só os sites carregados de script
• Composição por GPU e codecs — cada renderizador carrega a sua fatia do pipeline gráfico
• Service workers — os sites mantêm lógica rodando em segundo plano sem aba visível
• PWAs instaláveis — um web app ganha o próprio runtime, indistinguível de um navegador pequeno
• Extensões — um processo cada, mais content scripts injetados em cada página que você abre

O que de verdade reduz a conta

O primeiro passo honesto é suspender abas, e ele já vem de fábrica: as abas em suspensão do Edge congelam as de fundo num temporizador que você controla, e o Memory Saver do Chrome descarrega as inativas e as restaura no clique. Os dois recuperam memória de verdade, e os dois deixam fixar exceções para os sites que você quer sempre acordados. O segundo passo é auditar extensões: apague as que você não reconhece, desative as que servem uma vez por semana em vez de uma vez por hora, e compare os números do gerenciador de tarefas antes e depois.

O que não funciona: caçar navegadores «leves». Qualquer um que rode no mesmo engine carrega a mesma arquitetura por processo e o mesmo peso de plataforma — você troca compatibilidade ou atualizações de segurança por um erro de arredondamento. Os forks velhos sobre motores abandonados são piores que pesados: são superfície de ataque sem correção. Mais RAM é a correção sem glamour que acompanha a curva de verdade — o navegador é um sistema operacional para a web, e ninguém roda um SO no requisito mínimo.

Perguntas e respostas

Continue lendo