Bundle size: o que cortar e o que não vale a pena cortar

O problema

Discussão de bundle size costuma cair em dois extremos ruins.

Um lado ignora completamente:

“Hoje todo mundo tem internet boa.”

O outro lado vira obsessão:

“Precisamos economizar 3 kB custe o que custar.”

Os dois erram porque confundem número com impacto.

Bundle size importa.

Mas importa pelo efeito real no caminho crítico do usuário, não pelo prazer abstrato de ver o número menor.

Modelo mental

JavaScript não custa uma vez só.

Ele custa em várias etapas:

• download
• parse
• compilação
• execução
• disputa por main thread

Então a pergunta não é apenas:

Quantos kB eu tenho?

A pergunta melhor é:

Quanto código eu faço o usuário baixar, interpretar e executar antes de ele conseguir usar o que importa?

Essa mudança de pergunta melhora muito a priorização.

Quebrando o problema

Primeiro separe código crítico de código adiantado demais

Nem todo JavaScript precisa estar no primeiro pacote.

Tem código que é realmente necessário no primeiro paint ou na primeira interação.

Tem código que pode:

• carregar depois
• carregar sob demanda
• nem ir para o cliente

Boa parte do ganho real vem dessa separação, não de minúcia em cada função.

Depois procure os grandes blocos, não as migalhas

Quase sempre existem alguns suspeitos óbvios:

• biblioteca grande para um uso pequeno
• componente pesado carregado em toda página
• utilitário duplicado
• dependência inteira puxada por causa de uma função
• código de terceiro cedo demais

É comum perder tempo em cortes cosméticos enquanto um pacote grande continua dominante.

Lembre que peso não é só rede

Mesmo quando o download parece aceitável, o custo de parse e execução pode continuar alto, especialmente em dispositivo mais fraco.

Por isso bundle size conversa diretamente com:

• INP
• tempo de hidratação
• travadas de interação

Quando cortar não vale a pena

Nem toda redução compensa a complexidade adicionada.

Exemplos:

• trocar uma dependência estável por solução caseira mais frágil por alguns kB
• dificultar manutenção para economizar um valor sem impacto real
• espalhar lazy loading demais e aumentar complexidade de fluxo

O número menor precisa pagar a conta em experiência ou em custo operacional.

Se não paga, pode ser só vaidade.

Exemplo simples

Imagine uma página de dashboard que carrega:

• editor rico
• biblioteca de gráficos
• tabela virtualizada
• analytics

Tudo no bundle inicial.

O time decide otimizar removendo helpers pequenos e refatorando funções utilitárias.

Talvez até economize alguns kB.

Mas o ganho real provavelmente viria antes de perguntas como:

• o editor precisa carregar na tela inicial?
• todos os gráficos precisam entrar antes da primeira interação?
• esse pacote grande de analytics precisa estar tão cedo?

Esse é o ponto.

Bundle size bom não é só bundle menor.

É código grande fora do caminho crítico quando não precisa estar nele.

Erros comuns

• Tratar todo kB como se tivesse o mesmo peso no fluxo real.
• Micro-otimizar utilitários enquanto dependência enorme continua intacta.
• Olhar só para download e ignorar parse e execução.
• Fazer lazy load em excesso sem pensar em UX e complexidade.
• Cortar dependência boa por economia irrelevante.

Como um senior pensa

Quem pensa melhor sobre bundle size costuma priorizar assim:

• qual código entra cedo demais?
• qual dependência realmente domina custo?
• esse peso afeta rede, CPU ou ambos?
• o que posso tirar do caminho crítico com baixo risco?

Essa forma de pensar é melhor do que perseguir “bundle pequeno” como identidade.

Senioridade aqui é saber que nem toda economia compensa, mas também saber reconhecer quando o app está claramente pagando caro por JavaScript demais cedo demais.

O que o entrevistador quer ver

Ele quer ver se você:

• entende por que bundle size importa
• sabe ligar tamanho a download, parse e execução
• prioriza corte grande e relevante antes de corte cosmético
• fala de caminho crítico em vez de falar só de número

Se a sua resposta for “eu procuraria o que está sendo carregado cedo demais e qual dependência realmente domina o custo”, isso já mostra julgamento melhor do que uma lista genérica de otimizações.

O melhor corte de bundle costuma ser o código que nem precisava estar ali tão cedo.

Performance boa não vem de contar kB com obsessão. Vem de mover peso para fora da hora errada.