Kort fortalt: Når bundleren kan bevise at en funktion eller eksport aldrig bruges i applikationen, kan den fjernes fra output - det kaldes tree shaking (død kode elimineres). Jo mere statisk jeres import/eksport-struktur er, jo bedre virker shaking.
Tree shaking vs minification
- Minification forkorter navne, fjerner whitespace og lignende - samme kode, mindre tekst.
- Tree shaking fjerner hele grene og moduler der ikke nås fra entry points.
Begge er nødvendige for små produktionsbundter; de løser forskellige problemer.
Hvad blokerer god shaking?
- Sideeffekter i top-level af moduler uden korrekt
"sideEffects"-felt ipackage.jsonfor biblioteker - bundleren må beholde kode “for en sikkerheds skyld”. - Dynamiske
require()eller conditional imports uden klare mønstre bundleren kan forudsige. - Import af hele biblioteker i stedet for enkelte funktioner - klassisk lodash-eksempel.
- Utilsigtet global tilstand ved import - så kan filen ikke droppes uden at ændre adfærd.
sideEffects-feltet i npm
Biblioteksforfattere markerer sideEffects: false når filer trygt kan droppes. I jeres applikation skal I være ærlige: registrerer en fil globale listeners ved import, kan den ikke fjernes ved et trylleslag - arkitekturen skal laves om.
Relation til code splitting
Code splitting opdeler det der er tilbage efter shaking i chunks der loades efter behov. Først reducerer I død kode, derefter flytter I resten til de rigtige navigations- eller interaktionsøjeblikke.
Relaterede begreber
FAQ
Kan jeg måle effekten af tree shaking?
Ja - sammenlign bundleanalyse før og efter (rollup-plugin-visualizer, webpack bundle stats). Kig på både rå bytes og gzipped størrelse; sidstnævnte er tættere på hvad brugeren downloader.
Virker tree shaking for CSS?
Ikke på samme måde som for ES-moduler. Til CSS bruger I typisk purge/unused-css værktøjer der forstår jeres klassebrug - det er et parallelt spor.
Hvorfor bliver min kode ikke shaken væk?
Sideeffekter i top-level, dynamiske imports bundleren ikke kan statisk løse, eller biblioteker markeret uden sideEffects kan stadig trække store grene ind. Tjek import-stil (fx lodash per funktion) og package.json sideEffects.
Er tree shaking nok uden code splitting?
Nej. Shaking gør hvert bundt mindre; code splitting bestemmer hvilke dele der loades hvornår. Begge er ofte nødvendige på store apps.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Fjern eller udsæt tunge tredjeparts scripts uden at ødelægge funktionalitet
Følg en praktisk guide til at finde, vurdere og udsætte tredjeparts scripts, så de ikke ødelægger LCP, INP og den samlede brugeroplevelse.
Sådan finder du lange tasks i DevTools og forbedrer INP
Lær hvordan du bruger DevTools til at finde lange tasks, tunge event handlers og JavaScript der gør siden træg at bruge.
Optimer cookie banner uden CLS og INP problemer
Lær hvordan du bygger eller justerer cookie bannere, så de ikke skubber indhold, blokerer interaktion eller gør siden tungere end nødvendigt.
Hvordan tredjeparts scripts gør din hjemmeside langsom
Få overblik over hvordan chat widgets, tracking, consent, video embeds og andre tredjeparts scripts påvirker LCP, INP, CLS og TTFB.
Cookie banner og Core Web Vitals: den oversete årsag til dårlig brugeroplevelse
Se hvordan cookie bannere og consent scripts kan påvirke load, layout og interaktion, og lær hvordan du undgår at de ødelægger brugeroplevelsen.
Sådan læser du en waterfall og finder flaskehalse i load
Lær at læse en waterfall korrekt og find problemer med TTFB, LCP, render blocking og tredjepart, så du kan prioritere den rigtige optimering.
