Inchaço de JavaScript em 2024

Artigo original ↗ Discussão no Hacker News ↗

Os websites modernos enviam rotineiramente vários megabytes de JavaScript — mesmo para páginas relativamente simples — com exemplos que vão de ~1–3 MB no lado mais leve a 10–60 MB para serviços como Gmail, Figma e Jira. Comentadores argumentam que este inchaço resulta de frameworks pesados, code-splitting deficiente, tracking de terceiros e incentivos organizacionais, e observam que compressão e cache não eliminam os custos de CPU, memória e bateria, especialmente em dispositivos de baixo custo ou ligações lentas. Alguns veem bundles grandes como aceitáveis para aplicações web ricas, desde que a navegação seja rápida após o carregamento inicial, enquanto outros apontam sites leves e abordagens sem dependências como prova de que designs muito mais eficientes são possíveis.

Comparações de tamanho de headlines e surpresas

  • Comentadores destacam enormes payloads de JS: Gmail e Figma ~20 MB, YouTube ~12 MB de JS + 2,5 MB de CSS, Jira ~58 MB, e algumas landing pages com vários MB “só para mostrar texto e imagens”.
  • Sites pornôs (por exemplo, Pornhub) são repetidamente citados como relativamente leves (≈1–1,4 MB), apesar de serem intensivos em mídia.
  • Vários devs relatam os seus próprios apps complexos com 1–4 MB e ficam intrigados com o facto de empresas muito maiores enviarem 10–50 MB.

Compressão, parsing e limitações do dispositivo

  • Há debate sobre olhar para tamanhos comprimidos vs. não comprimidos: a compressão reduz a transferência, mas não o custo de parse/execução.
  • Dispositivos Android mais antigos e de baixo custo são apontados como os que mais sofrem com bundles grandes e trabalho pesado no DOM.
  • Alguns argumentam que o tamanho por si só é uma proxy grosseira; a análise de desempenho mostra que renderização do DOM, layout, reatividade ineficiente e waterfalls muitas vezes dominam.

Fontes de inchaço: SPAs, frameworks e tracking

  • Muitos culpam frameworks de SPA e arquiteturas sobredimensionadas por transformarem sites simples em apps.
  • Outros dizem que muitos bytes são analytics, tag managers, AB-testing e widgets de suporte ao cliente operados pelo marketing, às vezes injetados sem supervisão da equipa de desenvolvimento.
  • Scripts de tracking de terceiros podem, por si só, ter vários MB e muitas vezes carregam de CDNs externas.

Experiência do utilizador: rápido para alguns, inutilizável para outros

  • Relatos mistos: alguns acham YouTube, GitHub, Discord, etc. “rápidos”; outros veem atrasos e bloqueios notáveis, especialmente em hardware médio/antigo ou no mobile.
  • Pessoas em ligações limitadas (rural, roaming, 2 Mbps ou plafonds de dados baixos como 15 GB/mês) descrevem muitos sites modernos como praticamente inutilizáveis sem bloqueadores.
  • A UX offline/com má conectividade de apps como Spotify e Gmail é fortemente criticada.

Debate: bundles grandes são realmente um problema?

  • Um lado: “Menos JS = melhor” é uma heurística útil; 10–50 MB para UIs básicas é desperdício claro e prejudica os utilizadores medianos.
  • Outro lado: o custo é aceitável em ligações “normais”; é melhor otimizar a UX geral (cache, navegação rápida dentro da app) do que perseguir métricas de tamanho do bundle.
  • Alguns argumentam que devemos corrigir caching/PWA e problemas da plataforma em vez de obsessão com kilobytes.

Críticas à metodologia e nuances

  • Vários comentários apontam problemas de medição no artigo:
    • Olhar apenas para loads a frio e tamanhos não comprimidos.
    • Cache desativado exagerando downloads repetidos (por exemplo, sandboxes da documentação do React).
    • Algumas páginas que parecem “estáticas” são na verdade portas de entrada para webapps com várias ferramentas (por exemplo, Outlook, Translate).
  • Outros contrapõem que, mesmo com estas ressalvas, diferenças de ordem de grandeza e a lentidão observada no mundo real mostram um problema genuíno de inchaço.

Alternativas, ferramentas e práticas

  • Mitigações sugeridas: code-splitting, lazy loading, listas virtuais, evitar nós DOM desnecessários e ferramentas de análise de bundles (por exemplo, analisadores Webpack/Rollup).
  • Alguns defendem abordagens sem dependências ou com dependências mínimas, navegação estilo HTMX/PJAX, ou frameworks mais recentes “resumables” (por exemplo, Qwik).
  • Tema recorrente forte: os incentivos organizacionais (marketing, rapidez de desenvolvimento) favorecem acumular JS; o desempenho tem poucos defensores.