Os navegadores estão ficando mais inchados

Publicado em 28/08/2026

Atualizado em 31/08/2026

Os navegadores modernos estão entre os softwares mais complexos do mundo e são basicamente sistemas operacionais disfarçados de aplicativos. Eles são tão complexos que escrever um do zero não é viável nem mesmo para uma empresa como a Microsoft.

Os fornecedores de navegadores precisam continuar adicionando novos recursos para acompanhar os padrões cada vez maiores da web. Isso tem um custo de aumento da complexidade da base de código e aumento do tamanho binário. O inchaço do tamanho binário é uma preocupação de engenharia no Chrome, Firefox e WebKit/Safari sobre a qual poucas pessoas falam.

Para ilustrar o problema do inchaço, compilei as alterações de tamanho do Chrome nos últimos 5 anos:

Na sua forma instalada, o Chrome passou de aproximadamente 250 MiB para mais de 420 MiB em 5 anos.

OK, as pessoas podem dizer que não é problema, espaço em disco é barato, certo? Bem, as equipes de navegadores se preocupam com isso também por razões que vão além do tamanho do disco. Um binário maior também significa mais:

• Pressão do cache de instruções
• Falhas de página
• Mapeamentos de memória
• Trabalho de realocação (o trabalho que o carregador do sistema operacional deve realizar ao carregar um executável ou biblioteca compartilhada cujo código/dados contém endereços que não podem ser finalizados até o momento do carregamento)
• Partida a frio OI
• Baixar largura de banda
• Dificuldade de geração de patch
• Superfície de ataque e carga de manutenção

Todos os fornecedores de navegadores se preocupam com esses problemas. Por exemplo, a Mozilla possui infraestrutura de desempenho automatizada que rastreia regressões de tamanho do instalador. Em maio de 2025, os sistemas automatizados do Firefox abriram um bug de regressão de desempenho porque uma mudança aumentou o tamanho do instalador em 11,1%.

Uma investigação do WebKit descobriu que a redução do código produzia um benefício de desempenho inesperadamente grande. A explicação deles era que os binários estavam crescendo mais rápido do que os caches da CPU e o desempenho da memória podiam compensar, aumentando as perdas no cache de instruções, TLB
erros e falhas de página.

Devido à complexidade insana, algum crescimento é genuinamente o custo de implementação de uma plataforma web em contínua expansão. Quando temos mecanismos CSS poderosos o suficiente para implementar um emulador x86, isso não é nenhuma surpresa.

Há também um efeito de “tragédia dos comuns”. Um engenheiro adiciona um recurso que adiciona 200 KiB ao binário e conclui razoavelmente que 200 KiB é irrelevante. Enquanto isso, outra equipe adiciona 500 KiB, outra biblioteca adiciona 1,2 MiB, outro recurso de UI adiciona 300 KiB e assim por diante. O efeito acumulado é agora enorme.

Talvez devêssemos desacelerar a expansão dos padrões web e focar apenas nas coisas mais essenciais. Sempre precisamos adicionar outro pequeno recurso CSS interessante em vez de delegar para bibliotecas/frameworks? Na verdade, houve alguns recursos recentes fundamentais que posso apreciar, como:

Mas o número total de recursos CSS é impressionante e assustador, basta olhar para a API Houdini. O mesmo se aplica a algumas outras coisas. Estou preocupado que isso possa começar a entrar em colapso lentamente em algum momento… Tanto do ponto de vista de manutenção quanto de desempenho.

Temos apenas três principais mecanismos de navegador independentes (os outros são em grande parte derivados ou projetos antigos/com falta de pessoal que não são competitivos): Chrome, Firefox e Safari. Devido às complexidades insanas dos padrões web modernos, é improvável que vejamos navegadores com mecanismos totalmente novos. A diversidade de mecanismos de navegador pode até diminuir se um mecanismo de navegador existente ficar subfinanciado e/ou perder um número crítico de usuários/desenvolvedores web, como o Firefox. E isso não é bom…

Até mais.