Desconstruindo o Build: Chunks, Raio-X e a Anatomia do Navegador

#angular #typescript #frontend #braziliandevs

Fala, comunidade dev! 👋

No nosso último artigo sobre a desconstrução do build, mostrei como reduzimos o pacote do nosso YMS de 40MB para 15MB através de Standalone Components e Tree-Shaking. Mas, como bons engenheiros, não paramos por aí. 15MB ainda é muita coisa.

Sempre que rodamos o comando ng build, o terminal nos joga uma sopa de letrinhas com centenas de arquivos (chunks) e tamanhos variados. Mas o que exatamente o Angular está gerando? Como o navegador "mastiga" essa pasta de build? E, mais importante, como descobrimos o que está escondido dentro desses megabytes?

Hoje, vamos abrir a caixa preta da compilação, entender a matemática da performance e fazer um Raio-X da nossa aplicação.

1. Como o navegador entende a sua pasta de Build?

Quando você programa em Angular, você escreve TypeScript, usa SCSS e cria templates dinâmicos. Mas o navegador (Chrome, Edge, Safari) é "burro" para isso. Ele só entende o tripé sagrado da web: HTML, CSS e JavaScript puro.

O papel do seu Bundler (no Angular 21, o Esbuild) é traduzir a sua engenharia complexa para esse formato básico. O resultado cai na pasta dist/. Mas como o navegador lê isso?

A Porta de Entrada: O navegador baixa o index.html. Ele é um arquivo minúsculo que não tem quase nada na tela, mas contém as tags <link> para o seu CSS e <script> para o seu JavaScript.
O Download e o Bloqueio: O navegador começa a baixar o seu arquivo principal (main.js). É aqui que a mágica (ou a tragédia) acontece. Diferente de uma imagem de 2MB que apenas aparece na tela, um arquivo JavaScript de 2MB precisa ser Baixado, Interpretado (Parsed), Compilado e Executado pela Main Thread (a linha de execução principal) do navegador.

A Tela Branca: Enquanto o navegador está executando esse JavaScript pesado, ele "trava". Nenhuma interface é desenhada e nenhum clique funciona. É o famoso gargalo de TTI (Time to Interactive). É por isso que arquivos grandes são mortais. O peso do JS custa caro na rede (download) e caríssimo na CPU do celular ou do computador do usuário (execução).

2. Lendo o Terminal: O que são os "Chunks"?

Sabendo que arquivos gigantes travam o navegador, o Angular usa a tática de "dividir para conquistar". Quando rodamos o build do nosso YMS, recebemos o seguinte log:

Initial chunk files                 | Names       | Raw size
styles.css                          | styles      | 1.10 MB 
main.js                             | main        | 19.33 kB 
chunk-DXO7V6OT.js                   | -           | 26.94 kB 
                                    | Initial total | 1.18 MB

Lazy chunk files                    | Names                       | Raw size
chunk-QPFHIJ3Z.js                   | -                           | 513.35 kB 
editar.component-US2MQII7.js        | editar-component            | 342.09 kB 
painel.component-CX2TJGIN.js        | painel-component            | 281.48 kB 
...and 390 more lazy chunks files. Use "--verbose" to show all the files.

Para um desenvolvedor desavisado, ver "390 arquivos" gerados pode parecer um erro. Na verdade, é a prova de uma arquitetura de sucesso.

O que é um Chunk? É um fragmento isolado do seu sistema. O código alfanumérico no nome (DXO7V6OT) serve para o Cache Busting: se você alterar apenas esse arquivo no futuro, o nome muda, forçando o navegador a baixar a nova versão e reaproveitar o resto que está intocado no cache.

Initial Chunk Files (O Kit de Sobrevivência): Essa é a métrica mais importante do seu Front-end. O nosso Initial total deu 1.18 MB. Esse é o pacote absoluto que o navegador precisa baixar e executar para exibir a primeira tela (como o Login). Manter isso baixo é o que garante que o usuário não fique olhando para uma tela branca.
Lazy Chunk Files (A Sobremesa sob Demanda): O Angular pegou nossa tela gigantesca de painel.component, isolou as dependências dela e gerou um arquivo separado de 281 kB. O navegador nunca fará o download desses 281 kB a menos que o usuário clique no botão para acessar o painel. Dividimos 15MB em fatias cirúrgicas de carregamento!

3. Qual é o "Tamanho Ideal" e os Performance Budgets?

Com base em tudo isso, definimos limites estritos (Performance Budgets). No Angular, você pode configurar isso no angular.json para que o build "quebre" (falhe no CI/CD) se você passar do limite.

O nosso alvo corporativo:

O Initial Bundle deve ficar abaixo de 2MB (descompactado). Isso garante que, mesmo em um armazém logístico com internet 3G oscilante, a tela de login apareça em menos de 3 segundos.
Os Lazy Chunks devem ter no máximo 500KB. Se um componente Lazy passa disso, significa que a tela está fazendo coisas demais e precisa ser quebrada em sub-rotas ou blocos @defer no HTML.

4. O Raio-X do Bundle: Achando a "Gordura"

Tínhamos os limites definidos, tínhamos 15MB totais divididos em 390 chunks, mas queríamos saber: o que exatamente tem dentro desses chunks mais pesados?

Na era do Angular 16 (Webpack), usávamos a biblioteca source-map-explorer. Mas com o Esbuild (Angular 17+), a compilação é tão agressiva que as ferramentas antigas quebram.

A solução oficial agora é gerar o relatório nativo do compilador:

ng build --configuration production --stats-json

Depois, basta jogar esse arquivo stats.json no site oficial do Esbuild Bundle Analyzer (esbuild.github.io/analyze). O resultado é um mapa visual interativo que mostra cada byte do sistema. Ao rodar essa auditoria no YMS, encontramos três "vazamentos" clássicos de sistemas corporativos que estavam devorando nossos megabytes:

A Guerra dos Gráficos: Estávamos empacotando TRÊS bibliotecas de gráficos simultaneamente em telas diferentes: ECharts (~1MB), ApexCharts (~1MB) e Chart.js (~190KB). Padronizar a empresa para usar apenas uma delas limparia 1.2MB numa tacada só.
O Mistério do Service Gigante: Achamos um serviço (modelo-carroceria.service.ts) pesando inacreditáveis 500KB. Serviços normais têm 2KB! O motivo? Um JSON estático gigantesco (uma base de dados de caminhões) estava "chumbado" direto no código TypeScript, em vez de vir via API ou de um arquivo JSON estático na pasta assets.
Geradores de PDF Duplicados: O sistema importava a biblioteca jspdf isoladamente, mas também importava um componente pronto de terceiros que já trazia o jspdf embutido. O compilador não conseguiu unificar os dois, cobrando o peso em dobro.

Conclusão

Saber codificar telas bonitas é o básico do desenvolvimento web. Mas entender a anatomia do navegador, dominar a geração de chunks e saber medir o impacto de cada importação usando o Esbuild Analyzer é o que separa "fazer código" de Engenharia de Software.

Você já abriu a caixa preta do build no seu projeto Angular mais recente? Tomou algum susto com o tamanho de alguma biblioteca escondida? Compartilhem as experiências nos comentários! 👇