Waarom je site minder requests moet versturen, niet kleinere

De comfortabele mythe van “maak gewoon elk bestand kleiner”

Jarenlang klonk webperformance-advies eenvoudig: comprimeer alles, minify alles, maak elke asset kleiner.

Dat advies is nog steeds in grote lijnen juist. Een script van 40 KB is meestal beter dan een script van 400 KB. Een geoptimaliseerde afbeelding is beter dan een ruwe export. Brotli, AVIF, CSS-minificatie, tree shaking en font subsetting doen er allemaal toe.

Maar op veel productiesites is het grotere probleem niet langer één te groot bestand. Het is het aantal dingen waar de browser om moet vragen voordat de pagina bruikbaar aanvoelt.

Een pagina kan er gedisciplineerd uitzien qua bestandsgroottes en toch traag zijn omdat hij 120 requests verstuurt: CSS-fragmenten, JavaScript-chunks, third-party tags, fontbestanden, trackingpixels, icon sprites, JSON-endpoints, preloads, analytics beacons en cache-revalidaties. Elk daarvan kan “klein” zijn. Samen vormen ze een lange, kwetsbare waterfall.

De praktische regel is dit: zodra individuele assets redelijk gecomprimeerd zijn, verbetert het verminderen van het aantal requests vaak de gebruikerservaring meer dan een paar kilobytes van elk bestand afschaven.

Requests zijn niet alleen bytes

Een network request is niet alleen een overdracht van data. Het is een reeks handelingen.

De browser moet de resource ontdekken, bepalen wanneer die opgehaald moet worden, hem inplannen ten opzichte van andere resources, headers versturen, op de server wachten, headers ontvangen, de response parsen, die vaak decomprimeren, en er vervolgens iets nuttigs mee doen.

Dat “iets nuttigs” kan duur zijn. Een JavaScript-bestand moet worden geparset, gecompileerd en uitgevoerd. Een CSS-bestand kan rendering blokkeren. Een fontbestand kan leesbare tekst vertragen of layout shifts veroorzaken. Een afbeelding kan invloed hebben op het Largest Contentful Paint-element. Een third-party script kan zijn eigen keten van afhankelijkheden meebrengen.

Daarom blijft het aantal requests belangrijk, zelfs wanneer bestanden klein zijn. Een script van 3 KB kan slechter zijn dan een afbeelding van 30 KB als het rendering blokkeert, laat aankomt en op het verkeerde moment op de main thread wordt uitgevoerd.

Als je een Lighthouse-rapport leest en je gestraft voelt door tientallen losse waarschuwingen, begin dan met kijken naar de request waterfall in plaats van naar afzonderlijke scores. We hebben een praktische walkthrough in hoe je een Lighthouse-rapport leest zonder in paniek te raken, maar de korte versie is: vind wat de eerste render blokkeert en wat de hoofdcontent vertraagt.

“Maar HTTP/2 heeft dit opgelost,” meestal niet

HTTP/2 en HTTP/3 hebben de economie van requests veranderd. Ze introduceerden multiplexing, header compression en beter verbindingsgedrag. Simpel gezegd: browsers werden veel beter in het versturen van meerdere requests over minder verbindingen.

Dat was een echte verbetering. Het maakte ook een einde aan enkele oude gewoontes, zoals extreme CSS sprites en enorme samengevoegde bundles die alleen werden gemaakt om verbindingslimieten te omzeilen.

Maar HTTP/2 maakte requests niet gratis.

Multiplexing helpt wanneer veel resources een verbinding delen, maar de browser moet ze nog steeds prioriteren. Servers moeten nog steeds reageren. De client moet nog steeds elke response verwerken. Congestie, packet loss, TLS-onderhandeling, DNS-lookup, cache misses en druk op de main thread bestaan nog steeds.

HTTP/3 verbetert een deel van het transportgedrag, vooral rond connection migration en head-of-line blocking op transportniveau. Het neemt de kosten van ontdekken, plannen, downloaden, parsen en uitvoeren van resources niet weg.

Het moderne doel is dus niet “bundel alles in één enorm bestand.” Het is “verstuur minder kritieke requests, en maak de resterende requests bewust.”

In de waterfall staat de waarheid

Performanceproblemen kondigen zich zelden aan in één enkele metric. Ze worden zichtbaar als vorm.

Open een browser-network panel en kijk naar de eerste paar seconden. Vraag:

• Hoeveel requests starten voordat de hoofdcontent verschijnt?
• Welke requests blokkeren rendering?
• Worden belangrijke resources laat ontdekt?
• Concurreren third-party scripts met first-party CSS, fonts of afbeeldingen?
• Komen veel bestanden terug met 304-responses in plaats van direct uit cache te worden geserveerd?
• Zijn iconen, fonts of UI-fragmenten opgesplitst in meer bestanden dan de pagina nodig heeft?

Een snelle pagina heeft meestal een saaie vroege waterfall. Een klein aantal kritieke resources arriveert vroeg. Niet-kritieke resources wachten. Third-party scripts worden uitgesteld, beperkt of verwijderd. De browser wordt niet gedwongen om met twintig prioriteiten te jongleren voordat hij de pagina kan painten.

Een trage pagina heeft vaak een nerveuze waterfall: veel kleine bestanden, veel origins en veel late ontdekkingen.

Kleinere bestanden doen er nog steeds toe — alleen niet allemaal evenveel

Dit is geen pleidooi tegen compressie of optimalisatie. Het is een pleidooi tegen het optimaliseren van bytes terwijl coördinatie wordt genegeerd.

Kleinere bestanden doen er het meest toe wanneer de resource groot is, rendering blokkeert of onderdeel is van het hoofdpad naar content. Bijvoorbeeld:

• De hero-afbeelding moet correct geschaald en gecodeerd zijn.
• Render-blocking CSS moet slank zijn.
• JavaScript dat nodig is voor de eerste interactie moet minimaal zijn.
• Fonts moeten gesubset, gecomprimeerd en beperkt zijn tot de weights die daadwerkelijk worden gebruikt.

Fonts zijn een veelvoorkomend voorbeeld. Teams focussen zich vaak obsessief op de vraag of een fontbestand 24 KB of 31 KB is, terwijl ze zes weights, twee stijlen en meerdere families leveren. De betere oplossing is niet 7 KB van één bestand afschaven. Het is minder fontbestanden versturen. Als typografie onderdeel is van je performancewerk, zijn web fonts nog steeds een van de makkelijkste wins op de meeste sites.

Afbeeldingen volgen hetzelfde patroon. AVIF of WebP kan betekenisvolle bytes besparen, maar tien decoratieve afbeeldingen boven de fold versturen is nog steeds een slecht plan. Kies betere formaten, ja, maar vraag je ook af of elke afbeelding überhaupt opgevraagd moet worden. Voor formaatkeuzes is onze gids over wanneer AVIF beter is dan WebP en wanneer niet een nuttige aanvulling op dit werk rond request-aantallen.

De verborgen kosten van veel kleine bestanden

Veel kleine requests veroorzaken vaak problemen die niet zichtbaar worden als je alleen naar het totaal aantal overgedragen bytes kijkt.

1. Late ontdekking

Browsers kunnen niet aanvragen wat ze nog niet hebben ontdekt. Een CSS-bestand kan naar een font verwijzen. Een script kan een ander script importeren. Een component kan na hydration JSON aanvragen. Elke afhankelijkheid creëert een nieuwe stap in de keten.

Hoe dieper de keten, hoe later belangrijk werk begint.

2. Header-overhead

Elke request en response bevat headers. Header compression helpt, vooral via HTTP/2 en HTTP/3, maar het elimineert overhead niet. Cookies kunnen dit veel erger maken. Als je site grote cookies meestuurt met elke request, zijn kleine assets in de praktijk minder klein.

Dit is een reden waarom static assets vaak op cookie-vrije paden of domeinen moeten staan, en waarom cache headers aandacht verdienen. Als headers zich vreemd gedragen in productie, is redirects en HTTP headers debuggen meestal sneller dan gokken.

3. Onderbreking van de main thread

Veel JavaScript-chunks kunnen herhaald parse- en uitvoeringswerk veroorzaken. Zelfs als elke chunk klein is, kan de browser steeds moeten stoppen om code te evalueren. Dit kan Interaction to Next Paint schaden en de pagina schokkerig laten aanvoelen.

De gebruiker geeft er niet om dat elk bestand klein was. Die merkt dat het aantikken van een menu 600 milliseconden duurde.

4. Cachecomplexiteit

Assets opsplitsen kan caching verbeteren wanneer het zorgvuldig gebeurt. Een stabiele vendor bundle en een veranderende app bundle kunnen een goede splitsing zijn.

Maar overmatig chunken kan averechts werken. Meer bestanden betekenen meer cache-lookups, meer kansen op revalidatie, meer versiecoördinatie en meer manieren om per ongeluk resources te invalideren die niet hoefden te veranderen.

Bundling is terug, maar met oordeel

Het eerste tijdperk van webperformance hield van bundling omdat browsers strikte verbindingslimieten hadden. Daarna kwam HTTP/2 en sloegen veel teams hard door naar agressieve code splitting. Een deel daarvan was nuttig. Een deel werd bijgeloof.

Het verstandige midden is route-aware bundling.

Voor een typische marketingsite of contentsite:

• Inline of laad alleen de CSS die nodig is voor de eerste rendering.
• Houd globale JavaScript klein.
• Vermijd het opsplitsen van kleine modules in afzonderlijke network requests.
• Stel interactieve functies uit die niet direct nodig zijn.
• Verwijder third-party scripts die hun kosten niet rechtvaardigen.

Voor een applicatie:

• Splits per route of belangrijke feature, niet per component.
• Houd gedeelde afhankelijkheden stabiel en cachebaar.
• Preload alleen resources die zeker binnenkort nodig zijn.
• Vermijd het laden van admin-, dashboard-, editor- of experimentcode op publieke pagina’s.
• Meet interactiekosten, niet alleen bundle size.

Bundling is niet automatisch goed. Code splitting is niet automatisch goed. De nuttige vraag is: helpt deze splitsing de browser om de volgende betekenisvolle gebruikerservaring eerder te leveren?

Third-party requests verdienen extra wantrouwen

First-party requests vallen tenminste onder je eigen controle. Third-party requests zijn vaak trager, minder voorspelbaar en duurder dan ze lijken.

Eén tag manager kan analytics, advertenties, heatmaps, chatwidgets, A/B-testing, consent tools en personalisatiescripts activeren. Elke leverancier kan meer requests meebrengen. Sommige draaien vroeg. Sommige blokkeren de main thread. Sommige veranderen zonder jouw releaseproces.

De beste third-party optimalisatie is verwijderen. De op één na beste is uitstellen.

Vraag voordat je een third-party script toevoegt:

• Moet dit laden voordat de gebruiker de pagina ziet?
• Moet dit op elke pagina laden?
• Kan het laden na consent, interactie of idle time?
• Wie is er intern eigenaar van?
• Welke metric bewijst dat het de performancekosten waard is?

Hier wordt performance governance. Iemand moet nee mogen zeggen.

Een praktische checklist om requests te verminderen

Begin met de pagina’s die het belangrijkst zijn: homepage, pricing page, product page, checkout, signup of belangrijkste landing pages. Werk daarna de waterfall door.

Verwijderen

• Verwijder ongebruikte JavaScript en CSS.
• Verwijder oude experimenten, verlaten pixels en dubbele analytics.
• Schrap ongebruikte font weights en icon libraries.
• Vervang decoratieve afbeeldingen waar passend door CSS.

Doordacht combineren

• Bundel kleine JavaScript-modules die altijd samen laden.
• Voeg kleine CSS-bestanden samen die hetzelfde renderpad blokkeren.
• Gebruik SVG sprites of inline SVG voor herhaalde iconen wanneer dit requests vermindert zonder maintainability te schaden.

Uitstellen

• Lazy-load afbeeldingen onder de fold.
• Stel niet-kritieke scripts uit tot na first paint of gebruikersinteractie.
• Laad reacties, embeds, kaarten, chat en videospelers alleen wanneer nodig.

Goed cachen

• Gebruik langlevende caching voor versioned static assets.
• Vermijd onnodige revalidatie voor bestanden die zelden veranderen.
• Houd HTML vers, maar laat hashed assets gecachet blijven.

Opnieuw meten

Controleer na elke wijziging opnieuw de waterfall. Het doel is geen perfecte score. Het doel is minder kritieke requests, eerdere nuttige rendering en minder verstoring van de main thread.

Hoe goed eruitziet

Een gezonde pagina heeft niet per se zo weinig mogelijk requests. Hij heeft een klein, bewust kritisch pad.

De browser krijgt HTML, essentiële CSS, de hoofdcontentafbeelding als die er is, misschien een klein script dat nodig is voor navigatie of interactie boven de fold, en de minimale fontset die nodig is om tekst leesbaar te maken. Al het andere wacht op zijn beurt.

Dat is het verschil tussen een pagina die alleen geoptimaliseerd is en een pagina die snel aanvoelt.

Bestanden verkleinen blijft de moeite waard. Maar als de site al redelijk gecomprimeerd is, is de volgende performancewinst meestal niet nog eens 2 KB besparen op een bundle. Het is één blocking request minder, één fontbestand minder, één third-party script minder, één dependency chain minder.

Minder requests maken het werk van de browser eenvoudiger. Eenvoud is vaker snel dan we graag toegeven.