Beide reduzieren das JavaScript, das Nutzer herunterladen. Code Splitting zerlegt das Bundle in bei Bedarf geladene Chunks; Tree Shaking entfernt Code, den du nie verwendest. Sie ergänzen sich: teile auf, was geladen wird, und schüttle toten Code in jedem Chunk heraus.
Statt eines großen Bundles wird die App so aufgeteilt, dass jede Route oder jedes schwere Feature ein separater Chunk ist, der nur bei Bedarf abgerufen wird:
// 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();
};
Der dynamische import() ist das Signal — der Bundler erzeugt an dieser Grenze eine separate Datei.
Der Bundler analysiert die import/export von ES-Modulen statisch und verwirft Exports, die von nichts referenziert werden. Es funktioniert nur mit ESM (statisch, analysierbar) — nicht mit CommonJS require:
import { debounce } from "utils"; // only debounce is kept; throttle, etc. are shaken out
Es setzt auf "sideEffects": false in der package.json und Per-Funktion-Imports; Barrel Files oder Module mit Seiteneffekten können es aushebeln.
Das sind die beiden Hebel hinter „weniger JS ausliefern“. Interviewer wollen, dass du weißt: Code Splitting entscheidet, was wann geladen wird, Tree Shaking entscheidet, was überhaupt enthalten ist, und dass Tree Shaking von statischem ESM abhängt — ein Detail, das jene, die tatsächlich ein Bundle optimiert haben, von jenen unterscheidet, die nur darüber gelesen haben.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden