Varför din webbplats bör skicka färre förfrågningar, inte mindre sådana

Den bekväma myten om att ”bara göra varje fil mindre”

I åratal lät råden om webbprestanda enkla: komprimera allt, minifiera allt, gör varje resurs mindre.

Det rådet är fortfarande i stort sett korrekt. Ett script på 40 KB är oftast bättre än ett script på 400 KB. En optimerad bild är bättre än en rå export. Brotli, AVIF, CSS-minifiering, tree shaking och font-subsetting spelar alla roll.

Men på många produktionssajter är det större problemet inte längre en enda överdimensionerad fil. Det är antalet saker som webbläsaren måste be om innan sidan känns användbar.

En sida kan se disciplinerad ut i filstorlekar och ändå vara långsam eftersom den skickar 120 förfrågningar: CSS-fragment, JavaScript-chunks, tredjepartstaggar, fontfiler, trackingpixlar, ikonsprites, JSON-slutpunkter, förinläsningar, analytics beacons och cacheomvalideringar. Var och en kan vara ”liten”. Tillsammans skapar de ett långt, skört vattenfall.

Den praktiska regeln är denna: när enskilda resurser är rimligt komprimerade förbättrar färre förfrågningar ofta användarupplevelsen mer än att skala bort några kilobyte från varje fil.

Förfrågningar är inte bara bytes

En nätverksförfrågan är inte bara en dataöverföring. Den är en sekvens av arbete.

Webbläsaren måste upptäcka resursen, avgöra när den ska hämtas, schemalägga den i förhållande till andra resurser, skicka headers, vänta på servern, ta emot headers, tolka svaret, ofta dekomprimera det och sedan göra något användbart med det.

Det där ”något användbart” kan vara dyrt. En JavaScript-fil måste parsas, kompileras och köras. En CSS-fil kan blockera rendering. En fontfil kan försena läsbar text eller orsaka layoutförskjutningar. En bild kan påverka Largest Contentful Paint-elementet. Ett tredjepartsscript kan ta med sig sin egen kedja av beroenden.

Det är därför antalet förfrågningar fortfarande spelar roll även när filerna är små. Ett script på 3 KB kan vara värre än en bild på 30 KB om det blockerar rendering, kommer sent och körs på huvudtråden vid fel tillfälle.

Om du läser en Lighthouse-rapport och känner dig bestraffad av dussintals separata varningar, börja med att titta på förfrågningsvattenfallet i stället för enskilda poäng. Vi har en praktisk genomgång i hur man läser en Lighthouse-rapport utan att få panik, men den korta versionen är: hitta vad som blockerar första renderingen och vad som fördröjer huvudinnehållet.

”Men HTTP/2 löste det här,” mestadels inte

HTTP/2 och HTTP/3 förändrade ekonomin kring förfrågningar. De introducerade multiplexing, header-komprimering och bättre anslutningsbeteende. Enkelt uttryckt blev webbläsare mycket bättre på att skicka flera förfrågningar över färre anslutningar.

Det var en verklig förbättring. Det tog också död på vissa gamla vanor, som extrema CSS-sprites och enorma sammanfogade bundles byggda enbart för att undvika anslutningsgränser.

Men HTTP/2 gjorde inte förfrågningar gratis.

Multiplexing hjälper när många resurser delar en anslutning, men webbläsaren måste fortfarande prioritera dem. Servrar måste fortfarande svara. Klienten måste fortfarande bearbeta varje svar. Trängsel, paketförlust, TLS-förhandling, DNS-uppslagning, cachemissar och tryck på huvudtråden finns fortfarande.

HTTP/3 förbättrar visst transportbeteende, särskilt kring anslutningsmigrering och head-of-line-blockering på transportlagret. Det tar inte bort kostnaden för att upptäcka, schemalägga, ladda ned, parsa och köra resurser.

Det moderna målet är alltså inte ”paketera allt i en enorm fil”. Det är ”skicka färre kritiska förfrågningar och gör de återstående förfrågningarna avsiktliga”.

Vattenfallet är där sanningen finns

Prestandaproblem avslöjar sig sällan i ett enda mätvärde. De visar sig som en form.

Öppna webbläsarens nätverkspanel och titta på de första sekunderna. Fråga:

• Hur många förfrågningar startar innan huvudinnehållet visas?
• Vilka förfrågningar blockerar rendering?
• Upptäcks viktiga resurser sent?
• Konkurrerar tredjepartsscript med förstaparts-CSS, fonter eller bilder?
• Returnerar många filer 304-svar i stället för att levereras direkt från cache?
• Är ikoner, fonter eller UI-fragment uppdelade i fler filer än sidan behöver?

En snabb sida har oftast ett tråkigt tidigt vattenfall. Ett litet antal kritiska resurser anländer tidigt. Icke-kritiska resurser väntar. Tredjepartsscript fördröjs, begränsas eller tas bort. Webbläsaren tvingas inte jonglera tjugo prioriteringar innan den kan måla sidan.

En långsam sida har ofta ett nervöst vattenfall: många små filer, många ursprung och många sena upptäckter.

Mindre filer spelar fortfarande roll — bara inte lika mycket

Det här är inte ett argument mot komprimering eller optimering. Det är ett argument mot att optimera bytes och samtidigt ignorera samordning.

Mindre filer spelar störst roll när resursen är stor, renderingsblockerande eller en del av vägen till huvudinnehållet. Till exempel:

• Hero-bilden bör ha rätt storlek och kodning.
• Renderingsblockerande CSS bör vara slimmad.
• JavaScript som behövs för första interaktionen bör vara minimalt.
• Fonter bör vara subset:ade, komprimerade och begränsade till de vikter som faktiskt används.

Fonter är ett vanligt exempel. Team fastnar ofta i om en fontfil är 24 KB eller 31 KB, samtidigt som de skickar sex vikter, två stilar och flera familjer. Den bättre lösningen är inte att skala bort 7 KB från en fil. Det är att skicka färre fontfiler. Om typografi är en del av ditt prestandaarbete är webbfonter fortfarande en av de enklaste vinsterna på de flesta sajter.

Bilder följer samma mönster. AVIF eller WebP kan spara meningsfulla mängder bytes, men att skicka tio dekorativa bilder i den direkt synliga delen är fortfarande en dålig plan. Välj bättre format, ja, men ifrågasätt också om varje bild behöver begäras alls. För formatbeslut är vår guide till när AVIF slår WebP och när det inte gör det ett användbart komplement till arbetet med antal förfrågningar.

De dolda kostnaderna med många små filer

Många små förfrågningar tenderar att skapa problem som inte syns om du bara tittar på den totala mängden överförda bytes.

1. Sen upptäckt

Webbläsare kan inte begära något de inte har upptäckt. En CSS-fil kan referera till en font. Ett script kan importera ett annat script. En komponent kan begära JSON efter hydration. Varje beroende skapar ytterligare ett steg i kedjan.

Ju djupare kedjan är, desto senare börjar viktigt arbete.

2. Header-overhead

Varje förfrågan och svar innehåller headers. Header-komprimering hjälper, särskilt över HTTP/2 och HTTP/3, men den eliminerar inte overhead. Cookies kan göra detta mycket värre. Om din webbplats skickar stora cookies med varje förfrågan blir små resurser mindre små i praktiken.

Detta är en anledning till att statiska resurser ofta bör ligga på cookie-fria sökvägar eller domäner, och till att cache-headers förtjänar uppmärksamhet. Om headers beter sig märkligt i produktion är felsökning av redirects och HTTP-headers oftast snabbare än att gissa.

3. Avbrott på huvudtråden

Många JavaScript-chunks kan skapa upprepat parsnings- och exekveringsarbete. Även om varje chunk är liten kan webbläsaren behöva stanna upp om och om igen för att utvärdera kod. Det kan skada Interaction to Next Paint och få sidan att kännas ryckig.

Användaren bryr sig inte om att varje fil var liten. De bryr sig om att ett tryck på en meny tog 600 millisekunder.

4. Cache-komplexitet

Att dela upp resurser kan förbättra cachelagring när det görs omsorgsfullt. Ett stabilt vendor bundle och ett föränderligt app bundle kan vara en bra uppdelning.

Men överdriven chunking kan slå tillbaka. Fler filer betyder fler cacheuppslag, fler tillfällen för omvalidering, mer versionssamordning och fler sätt att av misstag invalidiera resurser som inte behövde ändras.

Bundling är tillbaka, men med omdöme

Den första eran av webbprestanda älskade bundling eftersom webbläsare hade strikta anslutningsgränser. Sedan kom HTTP/2 och många team svängde hårt mot aggressiv code splitting. En del av det var användbart. En del blev vidskepelse.

Den rimliga mitten är ruttmedveten bundling.

För en typisk marknadsföringssajt eller innehållssajt:

• Inline:a eller ladda bara den CSS som behövs för initial rendering.
• Håll global JavaScript liten.
• Undvik att dela upp minimoduler i separata nätverksförfrågningar.
• Fördröj interaktiva funktioner som inte behövs omedelbart.
• Ta bort tredjepartsscript som inte motiverar sin kostnad.

För en applikation:

• Dela upp efter rutt eller större funktion, inte efter varje komponent.
• Håll delade beroenden stabila och cachebara.
• Förinläs bara resurser som definitivt behövs snart.
• Undvik att ladda admin-, dashboard-, editor- eller experimentkod på publika sidor.
• Mät interaktionskostnad, inte bara bundle-storlek.

Bundling är inte automatiskt bra. Code splitting är inte automatiskt bra. Den användbara frågan är: hjälper den här uppdelningen webbläsaren att leverera nästa meningsfulla användarupplevelse tidigare?

Tredjepartsförfrågningar förtjänar extra misstänksamhet

Förstapartsförfrågningar står åtminstone under din kontroll. Tredjepartsförfrågningar är ofta långsammare, mindre förutsägbara och dyrare än de ser ut.

En enda tag manager kan trigga analytics, annonser, heatmaps, chattwidgetar, A/B-testning, samtyckesverktyg och personaliseringsscript. Varje leverantör kan ta med fler förfrågningar. Vissa körs tidigt. Vissa blockerar huvudtråden. Vissa förändras utan din releaseprocess.

Den bästa tredjepartsoptimeringen är borttagning. Den näst bästa är fördröjning.

Innan du lägger till ett tredjepartsscript, fråga:

• Måste detta laddas innan användaren ser sidan?
• Måste det laddas på varje sida?
• Kan det laddas efter samtycke, interaktion eller idle time?
• Vem äger det internt?
• Vilket mätvärde bevisar att det är värt prestandakostnaden?

Det är här prestanda blir styrning. Någon måste få säga nej.

En praktisk checklista för att minska förfrågningar

Börja med de sidor som spelar störst roll: startsida, prissida, produktsida, checkout, registrering eller de viktigaste landningssidorna. Arbeta sedan igenom vattenfallet.

Ta bort

• Ta bort oanvänd JavaScript och CSS.
• Ta bort gamla experiment, övergivna pixlar och duplicerad analytics.
• Slopa oanvända fontvikter och ikonbibliotek.
• Ersätt dekorativa bilder med CSS där det är lämpligt.

Kombinera med eftertanke

• Bundla små JavaScript-moduler som alltid laddas tillsammans.
• Slå samman små CSS-filer som blockerar samma renderingsväg.
• Använd SVG-sprites eller inline SVG för återkommande ikoner när det minskar förfrågningar utan att skada underhållbarheten.

Skjut upp

• Lazy-loada bilder nedanför den direkt synliga delen.
• Fördröj icke-kritiska script till efter första målningen eller användarinteraktion.
• Ladda kommentarer, embeds, kartor, chatt och videospelare bara när de behövs.

Cachelagra rätt

• Använd långlivad cachelagring för versionshanterade statiska resurser.
• Undvik onödig omvalidering för filer som sällan ändras.
• Håll HTML färskt, men låt hashade resurser förbli cachelagrade.

Mät igen

Efter varje ändring, kontrollera vattenfallet igen. Målet är inte en perfekt poäng. Målet är färre kritiska förfrågningar, tidigare användbar rendering och mindre störning på huvudtråden.

Så ser bra ut

En sund sida har inte nödvändigtvis så få förfrågningar som möjligt. Den har en liten, avsiktlig kritisk väg.

Webbläsaren får HTML, nödvändig CSS, huvudinnehållets bild om det finns en, kanske ett litet script som krävs för navigation eller interaktion i den direkt synliga delen, och den minsta fontuppsättningen som behövs för att text ska vara läsbar. Allt annat väntar på sin tur.

Det är skillnaden mellan en sida som bara är optimerad och en sida som känns snabb.

Att krympa filer är fortfarande värt att göra. Men om webbplatsen redan är rimligt komprimerad är nästa prestandavinst oftast inte ytterligare 2 KB sparade från ett bundle. Det är en blockerande förfrågan mindre, en fontfil mindre, ett tredjepartsscript mindre, en beroendekedja mindre.

Färre förfrågningar gör webbläsarens jobb enklare. Enkelt är snabbare oftare än vi gärna vill erkänna.