Ambos reduzem o JavaScript que os usuários baixam. O code splitting quebra o bundle em chunks carregados sob demanda; o tree shaking remove código que você nunca usa. Eles são complementares: divida o que carrega, remova por sacudida o código morto dentro de cada chunk.
Em vez de um único bundle grande, o app é dividido para que cada rota ou funcionalidade pesada seja um chunk separado buscado apenas quando necessário:
// Divisão por rota: o código do dashboard não é baixado até você visitá-lo
const Dashboard = lazy(() => import("./routes/Dashboard")); // seu próprio chunk
// Divisão por componente: editor pesado carregado na interação
button.onclick = async () => {
const { openEditor } = await import("./editor"); // buscado no clique
openEditor();
};
O import() dinâmico é o sinal — o bundler emite um arquivo separado naquela fronteira.
O bundler analisa estaticamente os import/export de módulos ES e descarta os exports que nada referencia. Só funciona com ESM (estático, analisável) — não com require do CommonJS:
import { debounce } from "utils"; // só debounce é mantido; throttle, etc. são removidos
Ele depende de "sideEffects": false no package.json e de imports por função; barrel files ou módulos com efeitos colaterais podem derrotá-lo.
Esses são os dois alavancas por trás de "envie menos JS." Entrevistadores querem que você saiba que o code splitting decide o que carrega e quando, o tree shaking decide o que sequer está lá dentro, e que o tree shaking depende de ESM estático — um detalhe que separa quem de fato afinou um bundle de quem só leu a respeito.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar