Bundle-optimering för Next.js: Tree-shaking, code splitting och lazy loading

JavaScript ar dyrt pa ett satt som ar latt att glomma. Varje kilobyte maste laddas ner, tolkas och koras innan sidan blir interaktiv, och det arbetet kanns mest pa de billiga telefoner och langsamma uppkopplingar som en stor del av besokarna faktiskt anvander. Nar en sida kanns trog att klicka pa ar boven ofta att det skickas alldeles for mycket kod. Har gar jag igenom hur jag mater vad en Next.js-bundle faktiskt skickar och hur man far ner det utan att forlora funktioner.

Mat innan du ror nagot

Forsta steget ar alltid att se vad som faktiskt finns i din bundle. Moderna byggverktyg kan generera en visualisering som visar hur stor varje del ar och vilka beroenden som tar mest plats. Det dar diagrammet brukar vara en uppenbarelse. Nio ganger av tio hittar man ett par tunga bibliotek som star for en oproportionerligt stor andel och som man knappt minns att man la in.

Utan den har matningen blir optimering bara gissningar. Med den vet man exakt var de stora vinsterna finns och slipper lagga tid pa att spara nagra fa byte har och dar nar det sitter ett enda bibliotek pa flera hundra kilobyte i andra andan.

Dela upp koden sa att den laddas vid behov

En vanlig miss ar att hela applikationen packas ihop till en enda stor fil som laddas direkt, aven om besokaren bara ska se startsidan. Code splitting later dig dela upp koden sa att varje sida bara laddar det den behover, och resten hamtas forst nar det faktiskt behovs.

• Dela per sida eller rutt sa att forsta laddningen bara innehaller det som syns direkt.
• Ladda tunga komponenter som modaler eller diagram forst nar de faktiskt ska visas.
• Skjut upp kod som inte behovs for det forsta intrycket, som chattwidgetar och sparning.

Effekten ar ofta dramatisk just for forsta intrycket, eftersom det ar da besokaren ar som mest otalig. Det som laddas senare marks sallan, medan en tung forsta laddning marks varje gang.

Tree shaking och varfor det ibland inte fungerar

Tree shaking ar nar byggverktyget tar bort kod som aldrig anvands. I teorin ska du kunna importera en enda funktion fran ett stort bibliotek och bara fa med just den. I praktiken fungerar det bara om biblioteket ar skrivet pa ett satt som tillater det. Aldre bibliotek drar ofta in hela paketet aven om du bara anvander en liten del.

Nar jag granskar en bundle tittar jag darfor pa hur beroenden importeras. Att byta ut ett tungt bibliotek mot ett mindre alternativ, eller att importera bara den del man behover, ger ofta storre vinst an nagon annan optimering. Ibland visar det sig att man drar in ett helt datumbibliotek for att formatera ett enda datum, nagot som man kan gora sjalv med nagra rader.

Ta bort kod som ingen anvander

Over tid samlar varje kodbas pa sig beroenden som lades in for nagot som sedan plockades bort, men sjalva biblioteket blev kvar. Jag brukar ga igenom listan over beroenden och fraga rakt ut om var och en faktiskt behovs. Det ar forvanansvart ofta man kan ta bort flera utan att nagot slutar fungera.

Samma sak galler polyfills och stod for gamla webblasare. Mycket kod skickas fortfarande for att stodja webblasare som knappt nagon anvander langre. Att titta pa sin egen statistik och anpassa vilka webblasare man faktiskt stodjer kan banta bundlen rejalt utan att nagon riktig besokare marker skillnad.

Lat inte bundlen vaxa tillbaka

Det jag ser oftast ar att ett team gor en stor insats, far ner bundlen och sedan later den krypa tillbaka allt eftersom nya funktioner laggs till. Losningen ar att gora storleken synlig. Jag brukar satta upp en grans for hur stor en bundle far bli och lata bygget varna nar den overskrids. Da blir en oavsiktlig okning nagot man upptacker direkt i stallet for forst nar sidan borjat kannas trog igen.

Konkreta exempel pa hur sadana har bantningar har sett ut, med siffror fore och efter, finns i var casebook.

Bilder och typsnitt glomms ofta bort

Nar man pratar om att skicka mindre till webblasaren fastnar man latt vid JavaScript, men bilder och typsnitt ar minst lika ofta boven. En enda ooptimerad hjaltebild kan vaga mer an hela din JavaScript-bundle tillsammans. Att skicka bilder i moderna format, i ratt storlek for skarmen och forst nar de behovs ger ofta storre vinst an manga timmar av kodbantning.

Samma sak galler typsnitt. Att ladda in flera teckensnitt i flera vikter kostar bade i nedladdning och i hur snabbt texten visas. Jag brukar ga igenom vilka vikter som faktiskt anvands och skala bort resten. Poangen ar att se hela det som skickas till webblasaren som en helhet, inte bara koden, eftersom besokarens enhet maste ladda ner allt oavsett vad det ar for sorts fil.

Tank pa de svaga enheterna

Det ar latt att glomma att man sjalv utvecklar pa en snabb dator med snabb uppkoppling, medan en stor del av besokarna sitter pa en flera ar gammal telefon pa ett halvdant mobilnat. Det ar pa de enheterna som tung JavaScript gor mest ont, eftersom arbetet med att tolka och kora koden tar langre tid ju svagare processorn ar. En bundle som kanns omedelbar pa min skarm kan ge flera sekunders vantan pa en billig telefon.

Darfor brukar jag testa pa just sadana forhallanden, antingen med en riktig billig enhet eller genom att i webblasaren strypa bade processor och natverk. Det ger en mycket arligare bild av hur sidan faktiskt upplevs an om man bara litar pa hur snabbt det gar pa utvecklingsdatorn. Att optimera for den svagaste rimliga besokaren gor sidan battre for alla, och det ar dessutom dar de storsta vinsterna brukar finnas.

Relaterat

• Web Performance Audit: 15 åtgärder som ger 90+ Lighthouse-poäng
• Teknisk skuld-inventering: Metrik, prioritering och 90-dagarsplan
• Database query-optimering: 12 mönster som eliminerar N+1-problem

Vill du ta det vidare?

Om din applikation kanns tung att ladda och du vill veta vad du faktiskt skickar till webblasaren kan vi ta ett forutsattningslost samtal. Las garna mer om hur jag jobbar med optimering eller titta i var casebook for konkreta exempel.