O Que É Code Splitting? Carregando JavaScript Sob Demanda
O code splitting divide um bundle grande em múltiplos chunks para que o navegador baixe apenas o código necessário para a visualização atual.
Enviar todo o seu app como um único arquivo JavaScript significa que os usuários esperam por código que talvez nunca executem. O code splitting divide o bundle em chunks que carregam quando necessário, como ao visitar uma rota. É uma das formas mais eficazes de melhorar o tempo de carregamento inicial, e o bundler faz o trabalho pesado em tempo de build.
Como o splitting acontece
Um import() dinâmico informa ao bundler para criar um chunk separado que carrega em runtime em vez de logo de início. O splitting baseado em rotas é o padrão mais comum: cada página vira seu próprio chunk, buscado quando o usuário navega até ela.
Chunks compartilhados
Os bundlers detectam código compartilhado entre múltiplos entry points e o fatoram em chunks comuns para que não seja duplicado. Um chunk de vendor para bibliotecas de terceiros é um resultado típico, mantido estável para que seu cache sobreviva entre deploys.
Os benefícios
- Carregamento inicial da página mais rápido a partir de um primeiro download menor.
- O código de páginas raramente visitadas nunca é buscado, a menos que seja necessário.
- Chunks compartilhados estáveis permanecem em cache entre releases.
Os trade-offs
Chunks minúsculos demais adicionam overhead de requisições e podem prejudicar a performance. O splitting também faz do prefetching e dos estados de carregamento algo que você precisa projetar, já que um chunk pode chegar depois de o usuário clicar.
Code splitting no CI/CD
O splitting muda quantos arquivos de saída o build produz e como eles são hasheados. Cada chunk recebe um content hash para que a CDN possa mantê-lo em cache para sempre, e apenas os chunks alterados são baixados novamente após um deploy. O pipeline faz upload de toda a saída em chunks como um único artifact.
Principais conclusões
- O code splitting carrega código sob demanda via imports dinâmicos, muitas vezes por rota.
- Chunks compartilhados e de vendor evitam duplicação e permanecem em cache entre deploys.
- Cada chunk recebe um content-hash, então um deploy só invalida o que mudou.