Les deux réduisent le JavaScript que les utilisateurs téléchargent. Le code splitting découpe le bundle en chunks chargés à la demande ; le tree shaking supprime le code que vous n'utilisez jamais. Ils sont complémentaires : découpez ce qui se charge, secouez pour éliminer le code mort dans chaque chunk.
Au lieu d'un seul gros bundle, l'app est découpée pour que chaque route ou fonctionnalité lourde soit un chunk séparé récupéré uniquement au besoin :
// Découpage par route : le code du dashboard n'est pas téléchargé tant que vous ne le visitez pas
const Dashboard = lazy(() => import("./routes/Dashboard")); // son propre chunk
// Découpage par composant : éditeur lourd chargé à l'interaction
button.onclick = async () => {
const { openEditor } = await import("./editor"); // récupéré au clic
openEditor();
};
L'import() dynamique est le signal — le bundler émet un fichier séparé à cette frontière.
Le bundler analyse statiquement les import/export des modules ES et supprime les exports que rien ne référence. Cela ne fonctionne qu'avec les ESM (statiques, analysables) — pas avec le require de CommonJS :
import { debounce } from "utils"; // seul debounce est conservé ; throttle, etc. sont éliminés
Cela repose sur "sideEffects": false dans package.json et sur des imports par fonction ; les barrel files ou les modules à effets de bord peuvent le mettre en échec.
Ce sont les deux leviers derrière « livrer moins de JS ». Les recruteurs veulent que vous sachiez que le code splitting décide ce qui se charge et quand, que le tree shaking décide ce qu'il y a dedans tout court, et que le tree shaking dépend d'ESM statiques — un détail qui distingue ceux qui ont réellement optimisé un bundle de ceux qui n'en ont fait que la lecture.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don