Ambos reducen el JavaScript que los usuarios descargan. El code splitting divide el bundle en chunks cargados bajo demanda; el tree shaking elimina el código que nunca usas. Son complementarios: divides qué se carga, sacudes fuera el código muerto dentro de cada chunk.
En lugar de un solo bundle grande, la app se divide de modo que cada ruta o funcionalidad pesada sea un chunk separado que se obtiene solo cuando se necesita:
// Route-based split: the dashboard code isn't downloaded until you visit it
const Dashboard = lazy(() => import("./routes/Dashboard")); // its own chunk
// Component-based split: heavy editor loaded on interaction
button.onclick = async () => {
const { openEditor } = await import("./editor"); // fetched on click
openEditor();
};
El import() dinámico es la señal: el bundler emite un archivo separado en ese límite.
El bundler analiza estáticamente los import/export de módulos ES y descarta los exports que nada referencia. Solo funciona con ESM (estático, analizable), no con require de CommonJS:
import { debounce } from "utils"; // only debounce is kept; throttle, etc. are shaken out
Depende de "sideEffects": false en package.json y de imports por función; los barrel files o los módulos con efectos secundarios pueden frustrarlo.
Estas son las dos palancas detrás de "enviar menos JS". Los entrevistadores quieren que sepas que el code splitting decide qué se carga cuándo, el tree shaking decide qué hay dentro en absoluto, y que el tree shaking depende de ESM estático, un detalle que separa a quienes realmente han afinado un bundle de quienes solo han leído sobre ello.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar