Ga naar de inhoud 
Op brotli versus gzip Ik bepaal op basis van meetbare effecten op TTFB, datavolume en Core Web Vitals welk formaat ik live lever. Uit betrouwbare benchmarks weet ik: Broodstengel comprimeert HTML, CSS en JS gemiddeld 15-21 % sterker en decomprimeert in veel gevallen sneller in de browser, soms tot wel 64 % [1][4][5].
Centrale punten
- compressieverhouding: Brotli vermindert tekstbronnen gemiddeld met 15-21 % meer dan Gzip – merkbaar voor FCP/LCP [1][4][5].
- Scenario's: Statische assets aan de rand met Brotli, dynamische antwoorden vaak met Gzip of een gematigd Brotli-niveau.
- vermogensniveaus: Brotli niveau 4 is vaak sneller en efficiënter dan Gzip niveau 6; hoge niveaus alleen bij precompressie [4][5].
- Hosting: Efficiënte compressiehosting met HTTP/2/3, caching en CDN verkort de roundtrips aanzienlijk [3][5][8].
- Controle: Controleer wijzigingen altijd via RUM en synthetische tests via FCP, LCP en TTFB.
Compatibiliteit, headers en caching-sleutels
Om ervoor te zorgen dat Brotli of Gzip stabiel werken, let ik op een schone Contentonderhandeling. De browser verzendt Accept-Encoding, de server antwoordt met Contentcodering (br, gzip of identity). Belangrijk: Vary: Accept-Encoding moet op elk gecomprimeerd antwoord worden geluisterd, zodat caches en CDN's verschillende varianten correct scheiden. Anders levert de cache een Brotli-bestand aan een client die alleen Gzip begrijpt. Op CDN-niveau controleer ik dat Accept-Encoding Deel van het Cache-sleutels is en dat de edge-knooppunten zowel .br- als .gz-varianten mogen opslaan.
Ik heb ook een robuuste Terugval klaar: als een client Brotli niet kan, krijgt hij Gzip; als hij helemaal niets kan, krijgt hij ongecomprimeerd. Voor lokale proxies of oudere apparaten is dit pad goud waard – en het kost me in het dagelijks leven geen tijd als de Vary-keten klopt. Ik werk bewust met ETags: sterke ETags per variant of een hash die de compressievorm meeneemt, voorkomt foutieve 304 Niet gewijzigd Treffers tussen br/gz.
Wat postcompressie in het dagelijks leven echt oplevert
Efficiënt Compressie verkort niet alleen de overdracht, maar stabiliseert ook de laadtijden bij wisselende mobiele netwerk kwaliteit. Hoe kleiner HTML, CSS, JavaScript en JSON, hoe sneller de eerste inhoud verschijnt, omdat de browser minder bytes hoeft op te halen en uit te pakken. Ik geef daarom voorrang aan tekstbronnen, omdat afbeeldingen en video's meer profiteren van eigen codecs dan van HTTP-compressie. Op goed geconfigureerde hosts kan de Time to First Byte zichtbaar worden verkort, omdat CPU-tijd en netwerkwachttijd beter in balans zijn. Wie zijn pijplijn opruimt, wint dubbel: minder bandbreedte voor de Gegevens en minder reflows door eerder beschikbare stijlen en scripts.
Welke inhoud comprimeren – en welke niet?
Ik comprimeer gericht tekstgebaseerd Typen: text/html, text/css, application/javascript, application/json, application/xml, image/svg+xml, application/manifest+json en soortgelijke. Voor reeds gecomprimeerde binaire formaten (afbeeldingen, video's, pdf's in veel gevallen, WOFF2) bespaar ik de CPU: het effect is minimaal, de latentie kan toenemen. Ook belangrijk: een drempelwaarde-regel (bijv. vanaf 1024-2048 bytes), zodat kleine antwoorden zonder merkbaar voordeel niet onnodig worden vertraagd. In CI controleer ik regelmatig het inhoudstype en de grootte om verkeerde configuraties vroegtijdig op te sporen.
Brotli vs Gzip: cijfers die laadtijden veranderen
Gecomprimeerd in tests Broodstengel HTML ongeveer 21 %, JavaScript ongeveer 14 % en CSS ongeveer 17 % sterker dan Gzip [1][4]. Andere metingen bevestigen een voorsprong van ongeveer 20 % ten opzichte van Deflate, het proces achter Gzip [5][6]. Dit verschil maakt pagina's merkbaar sneller, vooral bij veel tekstbestanden en op mobiele apparaten met variabele bandbreedte. Bovendien verloopt het decomprimeren in de browser bij Brotli in veel gevallen sneller; er werden tot 64 % snellere uitpakken in de frontend gemeten [1]. Al met al verkorten betere Compressieverhoudingen en snel uitpakken het kritieke pad tot aan de zichtbare inhoud duidelijk.
Vanuit het netwerk bekeken: eerste RTT's en CWV's
Veel tastbare voordelen ontstaan doordat kleinere antwoorden beter passen in de eerste TCP/QUIC-vluchten passen. Als de initiële HTML dankzij Brotli in één of twee pakketten minder past, wordt de tijd tot FCP/LCP en de blokkering voor renderkritische bronnen verkort. Onder HTTP/3 profiteren verbindingen bovendien van een lagere Hoofd van de lijnBlokkering. In mobiele netwerken met een hoger pakketverliespercentage zorgen kleinere overdrachten voor een egalisering van de Jitter-curve – RUM-gegevens laten dan minder uitschieters naar boven zien. Voor mij is dat een reden om juist de eerste HTML en kritische CSS consequent te verkleinen [3][5][8].
Wanneer gebruik ik Brotli – en wanneer Gzip?
Voor statisch Voor assets zoals HTML, CSS, JS, SVG en WOFF2 gebruik ik Brotli op een hoog niveau, vooraf gecomprimeerd tijdens de build of direct op de CDN-edge. De bestanden komen in de cache terecht en worden duizenden keren geleverd zonder CPU-kosten. Bij zeer dynamische reacties – gepersonaliseerde HTML-weergaven, API-JSON, zoeken – gebruik ik meestal Gzip of Brotli met een gematigd niveau, zodat de server de reactie snel streamt. De TTFB-curve blijft doorslaggevend: als deze omhoog schiet, draai ik het niveau terug of lever ik ongeblokkeerde deelinhoud eerder vroeg. Zo houd ik Reactietijden laag, zonder de voordelen van compacte bestanden te verliezen.
De juiste kwaliteitsniveaus kiezen (level)
Ik begin pragmatisch: Brotli niveau 4 voor on-the-fly, niveau 9-11 alleen voor pre-compressie; Gzip niveau 6 als solide uitgangspunt [4][5][6]. Als de CPU-belasting tijdens piekverkeer toeneemt, verlaag ik eerst het Brotli-niveau en controleer ik of de caching-header en CDN-edge correct werken. Vaak helpt een kleine aanpassing aan de Cache meer dan een hoge compressieniveau. In metingen toonde Brotli aan dat niveau 4 vaak betere bestandsgroottes opleverde bij een vergelijkbare of lagere latentie dan Gzip niveau 6 [4]. Wie iteraties nauwkeurig meet, komt al snel uit bij een setup die de Server spaart en toch merkbaar gegevens bespaart.
Configuratie: Nginx, Apache, Caddy – veilige standaardinstellingen
Ik zet in op eenvoudige, controleerbare standaardinstellingen. Voor Nginx betekent dit: statische varianten gebruiken, on-the-fly gematigd, juiste types, zinvolle minimumgroottes, Vary netjes instellen.
# Nginx (voorbeeld) brotli on; brotli_comp_level 4; brotli_static on; brotli_types text/html text/plain text/css application/javascript application/json application/xml image/svg+xml;
gzip on; gzip_comp_level 6; gzip_min_length 1024; gzip_static on; gzip_vary on; gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml; add_header Vary "Accept-Encoding" always;
Onder Apache activeer ik mod_brotli en mod_deflate met duidelijke verantwoordelijkheid: eerst Brotli, daarna Deflate als terugvaloptie. Minimale groottes en lettertypen blijven consistent.
# Apache (voorbeeld) AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css application/javascript application/json application/xml image/svg+xml BrotliCompressionQuality 4 BrotliWindowSize 22
AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json application/xml image/svg+xml DeflateCompressionLevel 6 Header append Vary "Accept-Encoding"
Belangrijk blijven guards: geen compressie voor reeds gecomprimeerde media, tests voor dubbele compressie en op proxies. no‑transform vermijden als caches anders varianten onderdrukken. Ik controleer met curl: -H „Accept-Encoding: br,gzip“ en -I, of Contentcodering, Variëren en groottes plausibel zijn.
Statische assets vooraf comprimeren: Build, Edge, Cache
Voor bundelintensieve frontends comprimeer ik vooraf Activa in de build en plaats .br/.gz-varianten naast de originelen, zodat Nginx of een CDN direct de juiste versie levert. Grote bibliotheken, herhaalde CSS-klassen en frameworkcode profiteren bovengemiddeld, omdat Brotli een groter zoekvenster en een ingebouwd woordenboek gebruikt [2][9]. Legitieme langetermijncaches (onveranderlijk + versiebeheer) verminderen aanvragen en uitpakwerk bovendien. Wie wereldwijd wil leveren, combineert dit met een slimme CDN-optimalisatie, zodat Edge-nodes dicht bij de gebruiker de gegevens leveren. Zo zorgen kleinere bestanden en geografische nabijheid samen voor lagere Latencies.
Dynamische reacties en TTFB controleren
Bij server-side gegenereerde HTML-Weergaven tellen streaming en lage latentie meer dan laatste procentpunten bestandsgrootte. Ik comprimeer on-the-fly met Gzip of Brotli op een gemiddeld niveau, controleer TTFB en CPU per worker en verhoog het niveau alleen als er voldoende reserves beschikbaar zijn. Een slimme sjabloonvolgorde stuurt de eerste bytes vroeg, zodat de browser kan beginnen met renderen. Bovendien stabiliseert Server-side caching de responstijd, omdat terugkerende fragmenten niet elke keer opnieuw worden berekend. Deze opstelling houdt Tips zonder de gebruikerservaring te vertragen.
Streaming en deelinhoud correct leveren
Vooral bij HTML-weergaven vertrouw ik op vroege rivieren: kritieke inline CSS, vroege head-sectie, daarna snel de body streamen. Compressie mag dit niet vertragen. Daarom houd ik buffergroottes en flush-punten in de gaten en vermijd ik uitgebreide Brotli-niveaus bij on-the-fly. Gzip niveau 6 of Brotli niveau 3-4 biedt hier een goede balans. Cruciaal: de server moet niet wachten tot „alles klaar is“, maar in zinvolle blokken verzenden – dat verbetert de FCP en de waargenomen reactiesnelheid.
HTTP/2 en HTTP/3: compressie effectief combineren
Multiplexing onder HTTP/2 en QUIC onder HTTP/3 werken perfect samen met kleinere bestanden, omdat meer objecten parallel en met minder head-of-line-blocking worden verzonden. Vooral op mobiele verbindingen zorgen lagere RTT's en minder pakketverlies in HTTP/3 voor extra stabiliteit. Ik controleer daarom altijd of de host beide protocollen ondersteunt met de juiste prioriteit en serverpush-vervanging (Early Hints). Wie de setup vergelijkt, vindt nuttige details in de compacte HTTP/3 versus HTTP/2 Overzicht. In combinatie met Brotli voor statische bestanden en Gzip voor live HTML worden de wachttijd en Jitter merkbaar.
CDN-strategieën: cache-keys, stale en edge-precompressie
In het CDN let ik erop dat .br en .gz Varianten worden apart gecachet en edge-knooppunten leveren bij voorkeur de reeds voorgecomprimeerde artefacten. Ik activeer stale-while-revalidate en stale-if-error, zodat pieken of backend-uitval niet zichtbaar worden. Voor API-routes laat ik het CDN vaak live comprimeren, maar met conservatieve niveaus. Belangrijk: headers zoals Cachebeheer, ETag, Variëren en Contentcodering moeten een coherent beeld vormen – anders ontstaan er bizarre cache-miss-golven die de TTFB verslechteren.
Mobiele gebruikers: bandbreedte besparen, batterij sparen
Op de smartphone betaalt elke bespaarde byte direct invloed op de laadtijd en het energieverbruik. De 15-21 % kleinere Brotli-bestanden verminderen de overdrachtstijd en radioactiviteit; bij beperkte bandbreedte is de ontlasting bijzonder merkbaar [4][5]. Kleinere payloads stabiliseren bovendien de FCP- en LCP-metrics, omdat renderkritische bronnen sneller aankomen. Ik let ook op schone Critical CSS en maak een duidelijke keuze welke scripts echt renderblokkerend mogen zijn. Uiteindelijk dalen de bouncepercentages en starten interacties eerder, omdat de browser minder Belasting draagt.
Teamworkflow, CI en budgetten
Ik maak compressie tot een Pijpleidingthema: Build-stappen genereren .br/.gz, CI meet de grootte van de artefacten en vergelijkt deze met budgetten. Een pull-verzoek dat kritieke assets met 30 % opblaast, valt meteen op. Daarnaast sla ik smoke-tests op (curl-checks op content-encoding, vary, groottevergelijking), zodat fouten niet pas in de productie opvallen. Rollouts voer ik uit als Kanarie: Verkeer naar nieuwe niveaus verdelen, RUM en serverstatistieken observeren en vervolgens volledig uitrollen. Duidelijke rollback-hefbomen (feature-flags, Nginx-map voor kwaliteitsniveaus) geven me zekerheid bij piekverkeer.
Vergelijkingstabel: sterke punten in één oogopslag
Het volgende overzicht helpt mij bij gesprekken met Teams, om snelle beslissingen te nemen. Het vervangt geen test in je eigen stack, maar laat wel zien waar de grootste effecten liggen. Ik beoordeel altijd de combinatie van bestandsgrootte, CPU-profiel en gebruikersimpact. Wie zich duidelijk richt op statische tekstbestanden, zal bijna altijd tevreden zijn met Brotli. Voor zeer dynamische toepassingen blijft Gzip een betrouwbare Alleskunner.
| Criterium | Broodstengel | Gzip | Praktisch effect |
|---|---|---|---|
| compressieverhouding | ~15–21 % kleiner bij HTML/CSS/JS [1][4][5] | Goed, maar groter dan Brotli | Minder bytes, sneller Transmissie |
| Decompressie in de browser | Vaak sneller; tot 64 % in tests [1] | Solide snelheid | Sneller opstarten zichtbaar Inhoud |
| On-the-fly CPU-profiel | Matige niveaus snel; hoge niveaus duur | Gemiddelde niveaus zeer snel | Kies bij Live-HTML voor conservatief |
| Beste toepassingen | Statische assets, pre-compressie, edge-cache | Dynamische antwoorden, streams, API's | Setups scheiden op basis van het type bron |
| Typische stappen | 4 (on-the-fly), 9–11 (pre) [4][5][6] | 6 als startpunt | Balans tussen grootte en TTFB |
| Compatibiliteit | Breed ondersteund, fallback mogelijk [3][5][6] | Bijna overal beschikbaar | Geen echte hindernissen in moderne stacks |
Monitoring en tests: zo meet ik vooruitgang
Ik installeer eerst duidelijke Metriek: TTFB, FCP, LCP, bytes/verzoek en CPU per worker. Vervolgens vergelijk ik varianten – Gzip vs. Brotli, niveau-aanpassingen, edge-cache aan/uit – in identieke tijdvensters. Synthetische tests tonen reproduceerbare verschillen, real-user-monitoring bevestigt het effect bij echte gebruikers. Een nette rollback blijft belangrijk in geval van CPU-pieken of cache-miss-golven. Pas als de effecten stabiel zijn, rol ik de setup uit. Verkeersterke routes.
Probleemoplossing: typische foutmeldingen en snelle controles
- Dubbele compressie: Content‑Encoding geeft „br, br“ of „gzip, gzip“ weer. Dit wordt vaak veroorzaakt door filterketens of proxy + origin. Oplossing: slechts één instantie verantwoordelijk maken, statische varianten de voorkeur geven.
- Verkeerde variant uit de cache: Brotli wordt door clients zonder br-ondersteuning goed ontvangen. Meestal ontbreekt Vary: Accept-Encoding of de CDN-cache-sleutel bevat het veld niet. Oplossing: Vary afdwingen en CDN-sleutel aanpassen.
- Exploderende TTFB Na activering: on-the-fly-niveau te hoog, CPU-verzadiging of ontbrekende edge-cache. Oplossing: niveau verlagen, pre-compressie inschakelen, cache-header controleren.
- Geen winst in grootte: verkeerde types (reeds gecomprimeerde media), minimale lengte te laag of agressieve minifying ontbreekt. Oplossing: types beheren, minimale lengte verhogen, build-optimalisatie controleren.
- Beschadigde downloads: Content‑Length komt niet overeen met het gecomprimeerde antwoord of upstream verwijdert Content‑Encoding. Oplossing: gebruik bij compressie Transfer‑Encoding: chunked of bereken de lengte opnieuw op de juiste manier.
- Schokkerige renderpaden: HTML streamt te laat, ondanks compressie. Oplossing: sjabloon structureren, vroege bytes verzenden, kritieke CSS, gematigde niveaus kiezen.
Kort samengevat: mijn standaardstrategie
Ik activeer voor alle cachebare tekstbronnen Broodstengel en lever voorgecomprimeerd via Build of CDN-Edge. Zeer dynamische inhoud krijgt Gzip of Brotli op een gematigd niveau, zodat TTFB en interactiviteit stabiel blijven. HTTP/2 en HTTP/3 werken met correct ingestelde cache-headers, Early Hints en geprioriteerd laden van kritieke bronnen. Ik houd de kwaliteitsinstellingen zo laag mogelijk, zolang de bestandsgroottes een duidelijk voordeel opleveren. Deze aanpak combineert een lage Hoeveelheid gegevens met een lage serverbelasting – en versnelt pagina's merkbaar.
