O inchaço do JavaScript em 2024

O problema do tamanho do JavaScript

• Eu estava um pouco por fora do desenvolvimento frontend moderno e me lembrava de artigos sobre o inchaço da web, com páginas chegando a vários megabytes.
• Fiquei com a impressão de que, se uma página web média tem 3 MB, então o bundle de JavaScript deve ter algo em torno de 1 MB.
• Fiz um experimento para verificar quanto isso realmente representa.

Método

• Uso do Firefox no macOS (deve ser igual em outros navegadores)
• Modo normal, não anônimo (queria ver os números dentro do app e achei que ficaria mais próximo da experiência real)
• Todas as extensões desativadas
• Medição apenas de JavaScript
• Sem compressão
• Service workers ativados (para uma situação mais realista)
• Todo o cache desativado (carregamento do zero)

Landing pages

• Exemplo de página comum com um pouco de interação: Wikipedia, 0,2 MB
• Exemplo de página um pouco inflada: Linear, 3 MB
• Exemplos de landing page ruins: Zoom, 6 MB; Vercel, 6 MB; Gitlab, 13 MB

Sites majoritariamente estáticos

• Não dá para ser mais simples do que mostrar uma parede de texto estático.
• Mesmo assim, o Medium precisa de 3 MB para isso.
• O Substack precisa de 4 MB, o Quora de 4,5 MB, o Pinterest de 10 MB e o Patreon de 11 MB.

Busca

• A interação do app se limita principalmente à busca.
• O StackOverflow precisa de 3,5 MB, o NPM de 4 MB, o Airbnb de 7 MB e o Booking.com de 12 MB.
• O Google precisa de 9 MB para mostrar um simples campo de texto e uma lista de links.

Apps de interação única

• O Google Translate precisa de 2,5 MB para duas caixas de texto.
• O ChatGPT precisa de 7 MB para uma única caixa de texto.

Vídeo

• O Loom precisa de 7 MB, o YouTube de 12 MB.
• O Pornhub, um site que se preocupa com desempenho, precisa de apenas 1,4 MB.

Áudio

• SoundCloud e Spotify precisam ambos de 12 MB.

E-mail

• O Google Mail precisa de 20 MB.
• O FastMail entrega a mesma funcionalidade com apenas 2 MB.

Produtividade

• O Todoist precisa de 9 MB, o Dropbox de 10 MB, o 1Password de 13 MB e o Trello de 13,5 MB.
• O Discord precisa de 21 MB para chat.

Edição de documentos

• O Google Docs precisa de 13,5 MB e o Notion de 16 MB.

Redes sociais

• O Twitter precisa de 11 MB, o Facebook de 12 MB, o TikTok de 12,5 MB, o Instagram de 16 MB e o LinkedIn de 31 MB.

Categoria gigante

• O Jira precisa de quase 50 MB e o Slack de 55 MB.
• O react.dev começa com 2 MB no início, mas pode crescer indefinidamente conforme você rola a página.

Está piorando cada vez mais rápido?

• Em 2015, o tamanho médio de uma página web já se aproximava da versão shareware de Doom 1 (2,5 MB).
• Em 2024, o Slack ocupa 55 MB, o que equivale ao tamanho original de Quake 1 só em JavaScript.

Quão grande é 10 MB?

• Hoje, 10 MB já não parece algo tão grande ou especial.
• Assumindo uma média de 65 caracteres por linha, isso significa que cada site está enviando cerca de 150.000 linhas de código.
• O Google Maps tem 4,5 MB, o que é relativamente modesto para os padrões atuais.

Conclusão

• O problema não é só o tamanho do download.
• O navegador precisa fazer parsing do JavaScript, mantê-lo na memória e executá-lo.
• Acredito que o conteúdo deveria superar o tamanho do código.
• O Gitlab precisa de 13 MB de código, mais de 500 mil linhas de JS, só para exibir uma landing page estática.

Opinião do GN⁺:

1. Um diagnóstico realista do estado atual do desenvolvimento web, que ajuda a entender o impacto do tamanho do JavaScript dos sites na experiência do usuário e no desempenho.
2. Relembra aos desenvolvedores frontend a importância da otimização e chama atenção para evitar o uso de recursos além do necessário.
3. Fornece dados interessantes que podem estimular discussões na comunidade de desenvolvedores sobre desempenho de sites.

[GN⁺]

Comentários do Hacker News

• Sites adultos são, na prática, um caso de quem realmente se importa com desempenho: o Pornhub carrega apenas 1,4 MB de dados. Isso é muito superior ao desempenho mostrado por algumas grandes empresas de tecnologia. O Pornhub quase nunca erra no básico de UI/UX ou na entrega de conteúdo.
• Ao usar roaming em uma área rural da Nova Zelândia, a experiência de usar a web foi muito ruim. A experiência offline do usuário (UX) do Spotify também precisa melhorar.
• Foi levantada a dúvida sobre por que estamos olhando para dados não compactados. Apps dinâmicos como Spotify e Gmail podem ser perdoados se permitirem navegação rápida após o carregamento da página. Alguns sites estão focando demais no carregamento inicial e prejudicando a experiência do usuário.
• O software reflete a organização que o criou. A maior parte da transferência de dados não é JavaScript necessário para o funcionamento real da página, mas sim analytics e scripts de terceiros. As equipes de marketing ignoram isso ou não se importam.
• Faltou uma análise do tamanho dos arquivos JavaScript das aplicações web. Por exemplo, o Google Translate não é um app de interação simples e inclui muitos recursos, mas mesmo assim 2,5 MB ainda é excessivo.
• Todas as páginas do site Wordsandbuttons.online têm menos de 64 KB, apesar das animações e interações. Isso é graças a uma política sem dependências de terceiros.
• É preciso discutir não só o uso excessivo de JavaScript, mas também a quantidade de scripts de rastreamento.
• Há uma comparação da quantidade de JavaScript carregada por sites populares. Por exemplo, o Pornhub carrega cerca de 10 vezes menos JavaScript que o YouTube.
• O estado atual da web é muito triste. Quem usa conexão de internet rápida não percebe o quanto a web ficou lenta. É impensável não usar bloqueadores de anúncios/rastreadores.
• Criam frameworks e abstrações complexas para facilitar a manutenção, mas muitos desenvolvedores nem conhecem o básico de JavaScript. Fazem engenharia demais nas aplicações web e criam camadas demais que escondem a linguagem real. Aprender o próprio JavaScript e usar JavaScript puro em vez de frameworks pode reduzir bastante o tamanho de uma codebase em JavaScript.