Kort fortalt: Et JavaScript bundle er den pakke af JavaScript som browseren downloader for at gøre dit site interaktivt. Jo større bundle, jo mere tid bruges der på download, parsing og execution.
Hvorfor betyder størrelsen noget?
- Mere download + parse + execute på main thread
- Kan skabe long tasks og dårlig interaktivitet
Hvilken indflydelse har et stort bundle?
Store bundles påvirker typisk:
- INP: interaktioner føles langsomme, fordi main thread er optaget
- LCP: CPU-arbejde kan skubbe rendering
- stabilitet: variation på mobil og langsomme enheder bliver større
Det er især tydeligt på lav-end mobil, hvor parsing/execution kan tage lang tid.
Hvornår blev bundling standard?
Bundling blev standard, da webapps begyndte at bruge:
- modules
- transpilation
- dependencies og frameworks
I dag er bundling stadig nyttigt, men det skal balanceres: for store bundles giver dårlig interaktivitet, mens for mange små chunks kan give overhead. Målet er ikke “færrest filer”, men “rigtigt indhold i rigtigt tidspunkt”.
Typiske forbedringer
- Code splitting (route-/component-level)
- Fjern unødvendige dependencies
- Brug mindre libraries hvor det giver mening
Konkrete metoder (praktisk)
1) Start med at finde hvad der fylder
Du vil typisk:
- se bundle-analyse (hvad fylder mest)
- identificere de største dependencies
Ofte er det:
- UI frameworks og komponentbiblioteker
- charts/editors
- date libraries
- tracking/AB test scripts
2) Code splitting efter routes og features
Konkrete eksempler:
- load editor/charts kun på sider der bruger dem
- load søgning/filter UI først når det åbnes
3) Fjern eller erstat tunge dependencies
Spørg:
- bruger du 5% af et bibliotek?
- kan du løse det med en mindre helper?
4) Flyt tredjepart ud af critical path
Hvis tredjepart loader tidligt, bliver dit bundle (og CPU) ofte tungere.
5) Begræns client-side rendering/hydration
Hvis store dele af sitet er statisk, kan du ofte reducere JS drastisk ved at begrænse hydration til små islands.
Sådan tester du om bundle-størrelse er problemet
- DevTools Performance: long tasks og script evaluation tid
- Lighthouse: “Reduce JavaScript execution time”
- Network: hvor meget JS downloades ved første load?
Tjekliste
- Bundle-analyse gennemført: top 5 største dependencies identificeret
- Code splitting implementeret for features/routes
- Tredjepart udskudt hvor muligt
- INP testet på mobil
Hvorfor bundle-størrelse rammer mobil hårdest
På desktop med hurtig CPU kan store bundles virke “acceptable”. På mobil er billedet anderledes:
- lavere CPU-kapacitet giver langsommere parsing og execution
- termisk throttling kan gøre situationen værre over tid
- netværk er ofte mere ustabilt
Derfor bør optimering altid valideres på mobil, ikke kun i desktop-labtest.
Sammenhæng med Core Web Vitals
Store bundles kan påvirke flere målepunkter:
- INP: interaktioner køres sent pga. main-thread pres
- LCP: render kan blive udskudt af script-arbejde
- TBT (lab): stiger ved lange tasks
Hvis du reducerer bundle og samtidig begrænser hydration, vil forbedringer ofte kunne ses på flere metrics på én gang.
Praktisk prioritering af indsats
En realistisk prioritering i teams:
- Fjern det åbenlyst unødvendige.
- Split det der kun bruges på få sider.
- Udskyd tredjepart.
- Finjustér framework/hydration.
Den rækkefølge giver ofte størst effekt hurtigst.
Eksempler på “dyre” mønstre
- Et stort komponentbibliotek globalt, selv om kun få komponenter bruges.
- Rich text editor importeret på sider uden redigering.
- Store chart-biblioteker på sider hvor grafer er sekundære.
- Flere tracking scripts i critical path.
I alle tilfælde er målet at flytte kode til “senere” eller “kun når nødvendigt”.
Sådan dokumenterer du effekt korrekt
Efter hver ændring:
- mål JS transfer size ved første load
- mål script evaluation/long tasks i trace
- mål interaktionsrespons (INP-lignende scenarier)
Uden før/efter dokumentation er det svært at vide hvilke ændringer der faktisk flyttede noget.
Udvidet tjekliste
- Ubrugte dependencies fjernet
- Route-level code splitting aktiv
- Feature-level lazy imports på tunge komponenter
- Tredjeparts scripts flyttet ud af critical path
- Mobilmålinger viser forbedret interaktion
- Regressionstest af funktionalitet er gennemført
FAQ
Skal man altid bundle alt i én fil?
Nej. På moderne sites er det ofte bedre med en balance: kritisk kode tidligt, resten senere.
Én stor fil kan være nem at deploye, men den kan skade INP, fordi download/parsing/execution bliver tung – især på mobil.
Er færre requests altid bedre?
Ikke nødvendigvis. HTTP/2/3 gør mange requests billigere, og for INP er det ofte vigtigere at reducere CPU-arbejde end at presse alt ned i én fil.
For mange små chunks kan stadig give overhead, så målet er “rigtigt indhold på rigtigt tidspunkt” – ikke “færrest filer”.
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.
INP vs FID: hvorfor INP erstattede FID og hvad du skal optimere
Lær hvorfor INP har erstattet FID, hvad forskellen betyder i praksis, og hvordan du finder og løser JavaScript-problemer, der gør siden tung at bruge.
