Hvorfor dit site bør sende færre requests, ikke mindre requests

Den bekvemme myte om “bare gør hver fil mindre”

I årevis lød råd om web performance enkle: komprimér alt, minificér alt, gør hvert asset mindre.

Det råd er stadig i store træk korrekt. Et script på 40 KB er som regel bedre end et script på 400 KB. Et optimeret billede er bedre end en rå eksport. Brotli, AVIF, CSS-minificering, tree shaking og font subsetting betyder alt sammen noget.

Men på mange produktionssites er det største problem ikke længere én overdimensioneret fil. Det er antallet af ting, browseren skal bede om, før siden føles brugbar.

En side kan se disciplineret ud i filstørrelser og stadig være langsom, fordi den sender 120 requests: CSS-fragmenter, JavaScript-chunks, tredjepartstags, fontfiler, tracking pixels, icon sprites, JSON-endpoints, preloads, analytics beacons og cache-revalideringer. Hver enkelt kan være “lille.” Tilsammen skaber de et langt, skrøbeligt waterfall.

Den praktiske regel er denne: Når individuelle assets er rimeligt komprimerede, forbedrer det ofte brugeroplevelsen mere at reducere antallet af requests end at skære nogle få kilobyte af hver fil.

Requests er ikke kun bytes

En network request er ikke kun en overførsel af data. Det er en sekvens af arbejde.

Browseren skal opdage ressourcen, beslutte hvornår den skal hentes, planlægge den i forhold til andre ressourcer, sende headers, vente på serveren, modtage headers, parse responsen, ofte dekomprimere den og derefter gøre noget nyttigt med den.

Det “noget nyttigt” kan være dyrt. En JavaScript-fil skal parses, kompileres og eksekveres. En CSS-fil kan blokere rendering. En fontfil kan forsinke læsbar tekst eller forårsage layout shifts. Et billede kan påvirke Largest Contentful Paint-elementet. Et tredjepartsscript kan medbringe sin egen kæde af dependencies.

Derfor betyder antallet af requests stadig noget, selv når filerne er små. Et script på 3 KB kan være værre end et billede på 30 KB, hvis det blokerer rendering, ankommer sent og eksekveres på main thread på det forkerte tidspunkt.

Hvis du læser en Lighthouse-rapport og føler dig straffet af dusinvis af separate advarsler, så begynd med at se på request-waterfallet frem for de enkelte scores. Vi har en praktisk gennemgang i hvordan man læser en Lighthouse-rapport uden at gå i panik, men den korte version er: Find det, der blokerer første render, og det, der forsinker hovedindholdet.

“Men HTTP/2 løste det her,” for det meste ikke

HTTP/2 og HTTP/3 ændrede økonomien i requests. De introducerede multiplexing, header-komprimering og bedre forbindelsesadfærd. Sagt enkelt blev browsere meget bedre til at sende flere requests over færre forbindelser.

Det var en reel forbedring. Det aflivede også nogle gamle vaner, såsom ekstreme CSS sprites og enorme sammenkædede bundles, der kun blev bygget for at undgå forbindelsesgrænser.

Men HTTP/2 gjorde ikke requests gratis.

Multiplexing hjælper, når mange ressourcer deler en forbindelse, men browseren skal stadig prioritere dem. Servere skal stadig svare. Klienten skal stadig behandle hver response. Congestion, packet loss, TLS negotiation, DNS lookup, cache misses og main-thread-pres findes stadig.

HTTP/3 forbedrer noget transportadfærd, især omkring connection migration og head-of-line blocking på transportlaget. Det fjerner ikke omkostningen ved at opdage, planlægge, downloade, parse og eksekvere ressourcer.

Så det moderne mål er ikke “bundle alt i én enorm fil.” Det er “send færre kritiske requests, og gør de resterende requests bevidste.”

Sandheden findes i waterfallet

Performance-problemer annoncerer sjældent sig selv i én enkelt metric. De viser sig som form.

Åbn browserens network panel, og se på de første par sekunder. Spørg:

• Hvor mange requests starter, før hovedindholdet vises?
• Hvilke requests blokerer rendering?
• Bliver vigtige ressourcer opdaget sent?
• Konkurrerer tredjepartsscripts med first-party CSS, fonts eller billeder?
• Returnerer mange filer 304 responses i stedet for at blive serveret direkte fra cache?
• Er ikoner, fonts eller UI-fragmenter opdelt i flere filer, end siden har brug for?

En hurtig side har som regel et kedeligt tidligt waterfall. Et lille antal kritiske ressourcer ankommer tidligt. Ikke-kritiske ressourcer venter. Tredjepartsscripts er forsinket, begrænset eller fjernet. Browseren tvinges ikke til at jonglere med tyve prioriteter, før den kan male siden.

En langsom side har ofte et nervøst waterfall: mange små filer, mange origins og mange sene opdagelser.

Mindre filer betyder stadig noget — bare ikke lige meget

Dette er ikke et argument imod komprimering eller optimering. Det er et argument imod at optimere bytes, mens man ignorerer koordinering.

Mindre filer betyder mest, når ressourcen er stor, render-blocking eller en del af hovedindholdets sti. For eksempel:

• Hero-billedet bør have korrekt størrelse og encoding.
• Render-blocking CSS bør være slank.
• JavaScript, der er nødvendigt for første interaktion, bør være minimalt.
• Fonts bør være subset, komprimerede og begrænset til de weights, der faktisk bruges.

Fonts er et almindeligt eksempel. Teams fokuserer ofte intenst på, om en fontfil er 24 KB eller 31 KB, mens de sender seks weights, to styles og flere families. Den bedre løsning er ikke at skære 7 KB af én fil. Det er at sende færre fontfiler. Hvis typografi er en del af dit performance-arbejde, er web fonts are still one of the easiest wins on most sites en nyttig ressource.

Billeder følger samme mønster. AVIF eller WebP kan spare meningsfulde bytes, men at sende ti dekorative billeder above the fold er stadig en dårlig plan. Vælg bedre formater, ja, men spørg også, om hvert billede overhovedet behøver at blive requested. Til formatbeslutninger er vores guide til when AVIF beats WebP and when it does not et nyttigt supplement til dette arbejde med request count.

De skjulte omkostninger ved mange små filer

Mange små requests har tendens til at skabe problemer, som ikke viser sig, hvis du kun ser på det samlede antal overførte bytes.

1. Sen opdagelse

Browsere kan ikke requeste det, de ikke har opdaget. En CSS-fil kan referere til en font. Et script kan importere et andet script. En component kan requeste JSON efter hydration. Hver dependency skaber endnu et trin i kæden.

Jo dybere kæden er, desto senere starter vigtigt arbejde.

2. Header-overhead

Hver request og response indeholder headers. Header-komprimering hjælper, især over HTTP/2 og HTTP/3, men den eliminerer ikke overhead. Cookies kan gøre dette meget værre. Hvis dit site sender store cookies med hver request, bliver små assets i praksis mindre små.

Det er en af grundene til, at statiske assets ofte bør ligge på cookie-frie paths eller domains, og hvorfor cache headers fortjener opmærksomhed. Hvis headers opfører sig mærkeligt i produktion, er debugging redirects and HTTP headers som regel hurtigere end at gætte.

3. Afbrydelser på main thread

Mange JavaScript-chunks kan skabe gentaget parse- og eksekveringsarbejde. Selv hvis hver chunk er lille, kan browseren blive ved med at stoppe for at evaluere kode. Det kan skade Interaction to Next Paint og få siden til at føles hakkende.

Brugeren er ligeglad med, at hver fil var lille. De går op i, at et tryk på en menu tog 600 millisekunder.

4. Cache-kompleksitet

Opdeling af assets kan forbedre caching, når det gøres omhyggeligt. Et stabilt vendor bundle og et app bundle, der ændrer sig, kan være en god opdeling.

Men overdreven chunking kan give bagslag. Flere filer betyder flere cache lookups, flere muligheder for revalidering, mere versionskoordinering og flere måder utilsigtet at invalidere ressourcer, der ikke behøvede at ændre sig.

Bundling er tilbage, men med dømmekraft

Den første æra af web performance elskede bundling, fordi browsere havde strenge forbindelsesgrænser. Så kom HTTP/2, og mange teams svingede hårdt mod aggressiv code splitting. Noget af det var nyttigt. Noget af det blev til overtro.

Den fornuftige midte er route-aware bundling.

For et typisk marketing-site eller content-site:

• Inline eller load kun den CSS, der er nødvendig for initial rendering.
• Hold global JavaScript lille.
• Undgå at splitte bittesmå modules ud i separate network requests.
• Udskyd interaktive features, der ikke er nødvendige med det samme.
• Fjern tredjepartsscripts, der ikke retfærdiggør deres omkostning.

For en application:

• Split efter route eller større feature, ikke efter hver component.
• Hold delte dependencies stabile og cacheable.
• Preload kun ressourcer, der helt sikkert snart er nødvendige.
• Undgå at loade admin-, dashboard-, editor- eller experiment-kode på offentlige sider.
• Mål interaktionsomkostning, ikke kun bundle size.

Bundling er ikke automatisk godt. Code splitting er ikke automatisk godt. Det nyttige spørgsmål er: Hjælper denne opdeling browseren med at levere den næste meningsfulde brugeroplevelse hurtigere?

Tredjeparts-requests fortjener ekstra mistanke

First-party requests er i det mindste under din kontrol. Tredjeparts-requests er ofte langsommere, mindre forudsigelige og dyrere, end de ser ud.

En enkelt tag manager kan udløse analytics, ads, heatmaps, chat widgets, A/B testing, consent tools og personalization scripts. Hver vendor kan medbringe flere requests. Nogle kører tidligt. Nogle blokerer main thread. Nogle ændrer sig uden din release-proces.

Den bedste tredjepartsoptimering er sletning. Den næstbedste er forsinkelse.

Før du tilføjer et tredjepartsscript, så spørg:

• Skal dette loade, før brugeren ser siden?
• Skal det loade på hver side?
• Kan det loade efter consent, interaktion eller idle time?
• Hvem ejer det internt?
• Hvilken metric beviser, at det er performance-omkostningen værd?

Her bliver performance til governance. Nogen skal have lov til at sige nej.

En praktisk checklist til request-reduktion

Start med de sider, der betyder mest: forside, prisside, produktside, checkout, signup eller de vigtigste landing pages. Gå derefter waterfallet igennem.

Fjern

• Slet ubrugt JavaScript og CSS.
• Fjern gamle experiments, forladte pixels og duplicate analytics.
• Drop ubrugte font weights og icon libraries.
• Erstat dekorative billeder med CSS, hvor det er passende.

Kombinér med omtanke

• Bundle små JavaScript modules, der altid loader sammen.
• Saml små CSS-filer, der blokerer den samme render path.
• Brug SVG sprites eller inline SVG til gentagne ikoner, når det reducerer requests uden at skade maintainability.

Udskyd

• Lazy-load billeder below the fold.
• Forsink ikke-kritiske scripts til efter first paint eller brugerinteraktion.
• Load comments, embeds, maps, chat og video players kun, når de er nødvendige.

Cache korrekt

• Brug langlivet caching til versionerede statiske assets.
• Undgå unødvendig revalidering for filer, der sjældent ændrer sig.
• Hold HTML frisk, men lad hashed assets forblive cached.

Mål igen

Efter hver ændring skal du tjekke waterfallet igen. Målet er ikke en perfekt score. Målet er færre kritiske requests, tidligere nyttig rendering og mindre forstyrrelse af main thread.

Sådan ser godt ud

En sund side har ikke nødvendigvis færrest mulige requests. Den har en lille, bevidst kritisk sti.

Browseren får HTML, essentiel CSS, hovedindholdets billede hvis der er et, måske et lille script, der kræves til navigation eller above-the-fold-interaktion, og det minimale fontsæt, der er nødvendigt for at gøre tekst læsbar. Alt andet venter på sin tur.

Det er forskellen på en side, der blot er optimeret, og en side, der føles hurtig.

Det er stadig værd at gøre filer mindre. Men hvis sitet allerede er rimeligt komprimeret, er den næste performance-gevinst som regel ikke endnu 2 KB sparet fra et bundle. Det er én mindre blokerende request, én mindre fontfil, ét mindre tredjepartsscript, én mindre dependency chain.

Færre requests gør browserens arbejde enklere. Enkelt er oftere hurtigt, end vi bryder os om at indrømme.