Hvorfor nettstedet ditt bør sende færre forespørsler, ikke bare mindre filer

Den behagelige myten om «bare gjør hver fil mindre»

I mange år hørtes rådene om webytelse enkle ut: komprimer alt, minifiser alt, gjør hver ressurs mindre.

Det rådet er fortsatt i hovedsak riktig. Et skript på 40 KB er som regel bedre enn et skript på 400 KB. Et optimalisert bilde er bedre enn en rå eksport. Brotli, AVIF, CSS-minifisering, tree shaking og font-subsetting betyr fortsatt noe.

Men på mange produksjonsnettsteder er det største problemet ikke lenger én overdimensjonert fil. Det er antallet ting nettleseren må be om før siden føles brukbar.

En side kan se disiplinert ut når det gjelder filstørrelser og likevel være treg fordi den sender 120 forespørsler: CSS-fragmenter, JavaScript-biter, tredjepartstagger, fontfiler, sporingspiksler, ikon-sprites, JSON-endepunkter, preloads, analytics-beacons og cache-revalideringer. Hver av dem kan være «liten». Sammen skaper de et langt og skjørt vannfall.

Den praktiske regelen er denne: Når enkeltressurser er rimelig komprimert, gir det ofte bedre brukeropplevelse å redusere antall forespørsler enn å barbere noen få kilobyte av hver fil.

Forespørsler er ikke bare bytes

En nettverksforespørsel er ikke bare en overføring av data. Den er en sekvens av arbeid.

Nettleseren må oppdage ressursen, bestemme når den skal hentes, planlegge den opp mot andre ressurser, sende headere, vente på serveren, motta headere, parse svaret, ofte dekomprimere det, og deretter gjøre noe nyttig med det.

Dette «noe nyttig» kan være kostbart. En JavaScript-fil må parses, kompileres og kjøres. En CSS-fil kan blokkere gjengivelse. En fontfil kan forsinke lesbar tekst eller føre til layoutendringer. Et bilde kan påvirke Largest Contentful Paint-elementet. Et tredjepartsskript kan ta med seg sin egen avhengighetskjede.

Derfor betyr antall forespørsler fortsatt noe, selv når filene er små. Et skript på 3 KB kan være verre enn et bilde på 30 KB hvis det blokkerer gjengivelse, kommer sent og kjøres på hovedtråden på feil tidspunkt.

Hvis du leser en Lighthouse-rapport og føler deg straffet av dusinvis av separate advarsler, bør du begynne med å se på forespørselsvannfallet i stedet for enkeltscorer. Vi har en praktisk gjennomgang i hvordan lese en Lighthouse-rapport uten panikk, men kortversjonen er: finn det som blokkerer første gjengivelse, og det som forsinker hovedinnholdet.

«Men HTTP/2 fikset dette», stort sett ikke

HTTP/2 og HTTP/3 endret økonomien i forespørsler. De introduserte multipleksing, header-komprimering og bedre tilkoblingsatferd. Enkelt sagt ble nettlesere mye bedre til å sende flere forespørsler over færre tilkoblinger.

Det var en reell forbedring. Det tok også livet av noen gamle vaner, som ekstreme CSS-sprites og enorme sammenkjedede bundles laget bare for å unngå tilkoblingsgrenser.

Men HTTP/2 gjorde ikke forespørsler gratis.

Multipleksing hjelper når mange ressurser deler en tilkobling, men nettleseren må fortsatt prioritere dem. Servere må fortsatt svare. Klienten må fortsatt behandle hvert svar. Overbelastning, pakketap, TLS-forhandling, DNS-oppslag, cache-miss og press på hovedtråden finnes fortsatt.

HTTP/3 forbedrer noe transportatferd, særlig rundt tilkoblingsmigrering og head-of-line blocking på transportlaget. Det fjerner ikke kostnaden ved å oppdage, planlegge, laste ned, parse og kjøre ressurser.

Det moderne målet er derfor ikke «bundle alt i én enorm fil». Det er «send færre kritiske forespørsler, og gjør de gjenværende forespørslene bevisste».

Det er i vannfallet sannheten ligger

Ytelsesproblemer annonserer sjelden seg selv i én enkelt måleverdi. De viser seg som form.

Åpne nettverkspanelet i en nettleser og se på de første sekundene. Spør:

• Hvor mange forespørsler starter før hovedinnholdet vises?
• Hvilke forespørsler blokkerer gjengivelse?
• Oppdages viktige ressurser sent?
• Konkurrerer tredjepartsskript med førsteparts-CSS, fonter eller bilder?
• Returnerer mange filer 304-svar i stedet for å bli servert direkte fra cache?
• Er ikoner, fonter eller UI-fragmenter splittet opp i flere filer enn siden trenger?

En rask side har som regel et kjedelig tidlig vannfall. Et lite antall kritiske ressurser kommer tidlig. Ikke-kritiske ressurser venter. Tredjepartsskript er forsinket, begrenset eller fjernet. Nettleseren blir ikke tvunget til å sjonglere tjue prioriteringer før den kan tegne siden.

En treg side har ofte et nervøst vannfall: mange små filer, mange origins og mange sene oppdagelser.

Mindre filer betyr fortsatt noe — bare ikke like mye overalt

Dette er ikke et argument mot komprimering eller optimalisering. Det er et argument mot å optimalisere bytes mens man ignorerer koordinering.

Mindre filer betyr mest når ressursen er stor, blokkerer gjengivelse eller er en del av hovedinnholdets kritiske vei. For eksempel:

• Hero-bildet bør ha riktig størrelse og koding.
• CSS som blokkerer gjengivelse, bør være slank.
• JavaScript som trengs for første interaksjon, bør være minimalt.
• Fonter bør være subsettet, komprimert og begrenset til vektene som faktisk brukes.

Fonter er et vanlig eksempel. Team blir ofte opphengt i om en fontfil er 24 KB eller 31 KB, samtidig som de leverer seks vekter, to stiler og flere familier. Den bedre løsningen er ikke å barbere 7 KB av én fil. Det er å sende færre fontfiler. Hvis typografi er en del av ytelsesarbeidet ditt, er webfonter fortsatt en av de enkleste gevinstene på de fleste nettsteder.

Bilder følger samme mønster. AVIF eller WebP kan spare meningsfulle bytes, men å sende ti dekorative bilder over folden er fortsatt en dårlig plan. Velg bedre formater, ja, men still også spørsmål ved om hvert bilde trenger å bli forespurt i det hele tatt. For formatvalg er guiden vår til når AVIF slår WebP, og når det ikke gjør det et nyttig supplement til dette arbeidet med antall forespørsler.

De skjulte kostnadene ved mange små filer

Mange små forespørsler har en tendens til å skape problemer som ikke vises hvis du bare ser på totalt overførte bytes.

1. Sen oppdagelse

Nettlesere kan ikke be om det de ikke har oppdaget. En CSS-fil kan referere til en font. Et skript kan importere et annet skript. En komponent kan be om JSON etter hydrering. Hver avhengighet skaper et nytt steg i kjeden.

Jo dypere kjeden er, desto senere starter viktig arbeid.

2. Header-kostnad

Hver forespørsel og hvert svar inkluderer headere. Header-komprimering hjelper, særlig over HTTP/2 og HTTP/3, men den eliminerer ikke kostnaden. Cookies kan gjøre dette mye verre. Hvis nettstedet ditt sender store cookies med hver forespørsel, blir små ressurser mindre små i praksis.

Dette er én grunn til at statiske ressurser ofte bør ligge på cookie-frie stier eller domener, og til at cache-headere fortjener oppmerksomhet. Hvis headere oppfører seg merkelig i produksjon, er feilsøking av redirects og HTTP-headere som regel raskere enn å gjette.

3. Avbrudd på hovedtråden

Mange JavaScript-biter kan skape gjentatt parse- og kjørearbeid. Selv om hver bit er liten, kan nettleseren stadig måtte stoppe opp for å evaluere kode. Dette kan skade Interaction to Next Paint og få siden til å føles urolig.

Brukeren bryr seg ikke om at hver fil var liten. De bryr seg om at det tok 600 millisekunder å trykke på en meny.

4. Cache-kompleksitet

Å splitte ressurser kan forbedre caching når det gjøres med omtanke. En stabil vendor-bundle og en app-bundle som endrer seg, kan være en god inndeling.

Men overdreven chunking kan slå tilbake. Flere filer betyr flere cache-oppslag, flere muligheter for revalidering, mer versjonskoordinering og flere måter å utilsiktet invalidere ressurser som ikke trengte å endres.

Bundling er tilbake, men med skjønn

Den første epoken innen webytelse elsket bundling fordi nettlesere hadde strenge tilkoblingsgrenser. Så kom HTTP/2, og mange team svingte kraftig mot aggressiv code splitting. Noe av det var nyttig. Noe av det ble overtro.

Den fornuftige mellomtingen er rutebevisst bundling.

For et typisk markedsføringsnettsted eller innholdsnettsted:

• Inline eller last bare CSS-en som trengs for første gjengivelse.
• Hold global JavaScript liten.
• Unngå å splitte små moduler i separate nettverksforespørsler.
• Utsett interaktive funksjoner som ikke trengs umiddelbart.
• Fjern tredjepartsskript som ikke rettferdiggjør kostnaden sin.

For en applikasjon:

• Splitt etter rute eller hovedfunksjon, ikke etter hver komponent.
• Hold delte avhengigheter stabile og cachebare.
• Preload bare ressurser som definitivt trengs snart.
• Unngå å laste admin-, dashboard-, editor- eller eksperimentkode på offentlige sider.
• Mål interaksjonskostnad, ikke bare bundle-størrelse.

Bundling er ikke automatisk bra. Code splitting er ikke automatisk bra. Det nyttige spørsmålet er: hjelper denne splitten nettleseren med å levere den neste meningsfulle brukeropplevelsen raskere?

Tredjepartsforespørsler fortjener ekstra skepsis

Førstepartsforespørsler er i det minste under din kontroll. Tredjepartsforespørsler er ofte tregere, mindre forutsigbare og dyrere enn de ser ut.

Én enkelt tag manager kan utløse analytics, annonser, heatmaps, chat-widgets, A/B-testing, samtykkeverktøy og personaliseringsskript. Hver leverandør kan ta med flere forespørsler. Noen kjører tidlig. Noen blokkerer hovedtråden. Noen endrer seg utenom release-prosessen din.

Den beste tredjepartsoptimaliseringen er sletting. Den nest beste er utsettelse.

Før du legger til et tredjepartsskript, spør:

• Må dette lastes før brukeren ser siden?
• Må det lastes på hver side?
• Kan det lastes etter samtykke, interaksjon eller inaktiv tid?
• Hvem eier det internt?
• Hvilken måleverdi beviser at det er verdt ytelseskostnaden?

Det er her ytelse blir styring. Noen må ha lov til å si nei.

En praktisk sjekkliste for å redusere forespørsler

Start med sidene som betyr mest: forside, prisside, produktside, checkout, registrering eller de viktigste landingssidene. Gå deretter gjennom vannfallet.

Fjern

• Slett ubrukt JavaScript og CSS.
• Fjern gamle eksperimenter, forlatte piksler og duplisert analytics.
• Dropp ubrukte fontvekter og ikonbiblioteker.
• Erstatt dekorative bilder med CSS der det passer.

Kombiner med omtanke

• Bundle små JavaScript-moduler som alltid lastes sammen.
• Slå sammen små CSS-filer som blokkerer den samme gjengivelsesveien.
• Bruk SVG-sprites eller inline SVG for gjentatte ikoner når det reduserer forespørsler uten å skade vedlikeholdbarheten.

Utsett

• Lazy-load bilder under folden.
• Utsett ikke-kritiske skript til etter første paint eller brukerinteraksjon.
• Last kommentarer, embeds, kart, chat og videospillere bare når de trengs.

Cache riktig

• Bruk langlivet caching for versjonerte statiske ressurser.
• Unngå unødvendig revalidering for filer som sjelden endres.
• Hold HTML fersk, men la hashede ressurser forbli cachet.

Mål på nytt

Etter hver endring, sjekk vannfallet igjen. Målet er ikke en perfekt score. Målet er færre kritiske forespørsler, tidligere nyttig gjengivelse og mindre forstyrrelse på hovedtråden.

Slik ser bra ut

En sunn side har ikke nødvendigvis færrest mulig forespørsler. Den har en liten og bevisst kritisk vei.

Nettleseren får HTML, essensiell CSS, hovedinnholdsbildet hvis det finnes et, kanskje et lite skript som kreves for navigasjon eller interaksjon over folden, og det minimale fontsettet som trengs for å gjøre tekst lesbar. Alt annet venter på tur.

Det er forskjellen på en side som bare er optimalisert, og en side som føles rask.

Å krympe filer er fortsatt verdt å gjøre. Men hvis nettstedet allerede er rimelig komprimert, er neste ytelsesgevinst som regel ikke ytterligere 2 KB spart fra en bundle. Det er én blokkerende forespørsel mindre, én fontfil mindre, ett tredjepartsskript mindre, én avhengighetskjede mindre.

Færre forespørsler gjør nettleserens jobb enklere. Enkelt er raskt oftere enn vi liker å innrømme.