Gzip en Brotli zijn compressie-algoritmen die uw webserver gebruikt om bestanden te verkleinen voordat ze naar de browser van de bezoeker worden gestuurd. Het idee is eenvoudig: tekstgebaseerde bestanden zoals HTML, CSS en JavaScript bevatten veel repetitieve patronen, en compressie-algoritmen zijn er erg goed in om die redundantie te vinden en te elimineren. Een HTML-bestand van 100 KB kan worden gecomprimeerd tot 15-20 KB. De browser decomprimeert het direct, en de bezoeker merkt niets, behalve dat de pagina sneller laadt.
Heeft u ooit een map op uw computer gezipt, dan kent u het basisconcept al. Webcompressie werkt op dezelfde manier, maar dan automatisch en transparant. De server comprimeert de response, de browser decomprimeert die, en noch de ontwikkelaar noch de bezoeker hoeft iets bijzonders te doen (mits de server correct geconfigureerd is).
Hoe webcompressie werkt op protocolniveau
Telkens wanneer een browser een HTTP-request verstuurt, neemt hij een Accept-Encoding-header op die de server vertelt welke compressie-algoritmen hij ondersteunt:
Accept-Encoding: gzip, deflate, brDeze header zegt dat de browser Gzip, Deflate en Brotli (afgekort als br) aankan. De server kiest het beste algoritme dat hij ondersteunt, comprimeert het response-body en voegt een Content-Encoding-header toe om de browser te vertellen welk algoritme is gebruikt:
Content-Encoding: gzipof:
Content-Encoding: brDe browser leest deze header, past het bijbehorende decompressie-algoritme toe en rendeert de inhoud. Ondersteunt de server geen compressie (of is die niet geconfigureerd), dan stuurt hij de response ongecomprimeerd, en is er geen Content-Encoding-header aanwezig.
Deze onderhandeling vindt plaats bij elk afzonderlijk request. De server kan voor verschillende bestandstypen verschillende compressiemethoden kiezen, of zelfs ongecomprimeerde inhoud serveren voor bestanden die niet van compressie profiteren.
Gzip: de gevestigde standaard
Gzip is sinds eind jaren negentig de werkpaard van webcompressie. Het is gebaseerd op het DEFLATE-algoritme (een combinatie van LZ77 en Huffman-codering) en wordt door letterlijk elke gebruikte browser en webserver ondersteund. Wanneer mensen het hebben over het "inschakelen van compressie" op een webserver, bedoelen ze meestal Gzip.
Gzip werkt met instelbare compressieniveaus, doorgaans van 1 (snelst, minste compressie) tot 9 (langzaamst, beste compressie). De meeste webservers staan standaard op niveau 6, dat een goede balans biedt tussen compressieverhouding en CPU-gebruik. Op niveau 6 behaalt Gzip doorgaans 70-85% compressie op tekstgebaseerde bestanden. Een CSS-bestand van 100 KB wordt dan ongeveer 15-30 KB.
De belangrijkste voordelen van Gzip zijn de universaliteit (het werkt overal), de snelheid bij gematigde compressieniveaus, en de decennia van optimalisatie die in de implementaties zijn gestoken. Het belangrijkste nadeel is dat het niet zo goed comprimeert als Brotli, vooral bij kleinere bestanden.
Brotli: het moderne alternatief
Brotli is ontwikkeld door Google en in 2016 gepubliceerd als RFC 7932. Het is specifiek ontworpen voor webcontent en behaalt 15-25% betere compressieverhoudingen dan Gzip op typische webassets. Brotli realiseert dit door een geavanceerder compressie-algoritme te gebruiken en een ingebouwd woordenboek mee te leveren met veelvoorkomende strings in webcontent (HTML-tags, CSS-eigenschappen, JavaScript-sleutelwoorden, enz.).
Brotli gebruikt eveneens instelbare compressieniveaus, van 0 tot 11. Bij vergelijkbare kwaliteitsniveaus produceert Brotli kleinere uitvoer dan Gzip, maar op de hoogste niveaus (10-11) is Brotli aanzienlijk trager bij het comprimeren. Hoog ingestelde Brotli-compressie is dus ideaal voor statische assets die eenmalig vooraf gecomprimeerd kunnen worden en daarna vele malen geserveerd, en minder geschikt voor dynamische content die bij elk request gecomprimeerd moet worden.
Een belangrijke beperking: Brotli werkt alleen via HTTPS. Browsers accepteren geen Brotli-gecomprimeerde responses over platte HTTP-verbindingen. Aangezien de meeste WordPress-sites toch op HTTPS zouden moeten draaien (en HTTP/2 dat vereist), is dit zelden een praktisch probleem.
Gzip versus Brotli: een praktische vergelijking
Zo verhouden de twee algoritmen zich op de metrieken die ertoe doen voor WordPress-site-eigenaren:
- Compressieverhouding: Brotli produceert doorgaans bestanden die op vergelijkbare compressieniveaus 15-25% kleiner zijn dan bij Gzip. Op een WordPress-site die 500 KB aan comprimeerbare assets laadt, vertaalt dat verschil zich naar ongeveer 15-30 KB minder dataverkeer per pagina-laad.
- Compressiesnelheid: Gzip op niveau 6 is sneller dan Brotli op een gelijkwaardige kwaliteitsinstelling. Voor dynamische content (door PHP gegenereerde HTML-pagina's) is Gzip vaak de praktischere keuze, omdat de compressie bij elk request plaatsvindt. Brotli op niveau 1-4 is qua snelheid vergelijkbaar met Gzip en comprimeert nog steeds iets beter.
- Decompressiesnelheid: Brotli decomprimeert iets sneller dan Gzip, waardoor de browser de inhoud marginaal sneller kan verwerken. Het verschil is klein, maar consistent.
- Browserondersteuning: alle moderne browsers ondersteunen zowel Gzip als Brotli. Internet Explorer (inmiddels uit de roulatie) ondersteunde Brotli niet, maar Edge, Chrome, Firefox en Safari wel. Wereldwijde browserondersteuning voor Brotli ligt boven de 96%.
- Serverondersteuning: Apache ondersteunt Brotli via
mod_brotli(beschikbaar sinds Apache 2.4.26). Nginx ondersteunt het via dengx_brotli-module (een externe module die apart gecompileerd moet worden). LiteSpeed heeft ingebouwde Brotli-ondersteuning. De meeste managed hostingproviders en CDN's ondersteunen beide. - HTTPS-vereiste: Brotli vereist HTTPS. Gzip werkt over zowel HTTP als HTTPS.
In de praktijk zijn veel servers geconfigureerd om de voorkeur te geven aan Brotli wanneer de browser het ondersteunt en anders terug te vallen op Gzip. Zo krijgt u de beste compressie voor moderne browsers en behoudt u compatibiliteit met oudere clients.
Compressie inschakelen in Apache
Voor Apache schakelt u Gzip-compressie in via mod_deflate (verwarrend benoemd, maar het gebruikt Gzip, niet ruwe Deflate). Voeg het volgende toe aan uw .htaccess:
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/font-woff2
Voor Brotli op Apache heeft u mod_brotli nodig:
AddOutputFilterByType BROTLI_COMPRESS text/html
AddOutputFilterByType BROTLI_COMPRESS text/css
AddOutputFilterByType BROTLI_COMPRESS text/javascript
AddOutputFilterByType BROTLI_COMPRESS application/javascript
AddOutputFilterByType BROTLI_COMPRESS application/json
Compressie inschakelen in Nginx
Voor Nginx is Gzip ingebouwd en hoeft alleen in de configuratie te worden geactiveerd:
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;Voor Brotli op Nginx, na installatie van de ngx_brotli-module:
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;WordPress-cachingplugins en compressie
Heeft u geen toegang tot uw serverconfiguratie (gebruikelijk bij shared hosting), dan kunnen diverse WordPress-cachingplugins de compressie voor u afhandelen:
- WP Rocket: schakelt Gzip-compressie automatisch in door regels aan uw
.htaccesstoe te voegen. Maakt ook vooraf gecomprimeerde statische HTML-cachebestanden aan. - W3 Total Cache: biedt Gzip-compressie als instelbare optie in de Browser Cache-instellingen. Kan ook vooraf gecomprimeerde bestanden serveren.
- LiteSpeed Cache: draait uw host op een LiteSpeed-server, dan schakelt deze plugin automatisch zowel Gzip- als Brotli-compressie in.
- WP Super Cache: bevat een Gzip-compressie-optie die gecachte pagina's comprimeert.
- Autoptimize: hoewel primair een CSS/JS-optimalisatieplugin, kan deze ook gecomprimeerde versies van de gegenereerde bestanden serveren.
Houd er rekening mee dat als uw server al compressie op serverniveau verzorgt, het opnieuw inschakelen via een plugin onnodig is en soms conflicten kan veroorzaken (dubbele compressie, die browsers niet kunnen decomprimeren).
Welke bestandstypen profiteren het meest van compressie
Compressie werkt het beste op tekstgebaseerde, repetitieve content. Een overzicht per bestandstype:
- HTML: comprimeert uitstekend (70-90% reductie). Door WordPress gegenereerde HTML-pagina's zitten vol repetitieve tag-structuren, klassenamen en witruimte.
- CSS: comprimeert zeer goed (80-90% reductie). Stylesheets bevatten veel herhaalde eigenschapsnamen en selectoren.
- JavaScript: comprimeert zeer goed (70-85% reductie). JS-bestanden hebben herhaalde sleutelwoorden, functienamen en structurele patronen.
- SVG: comprimeert uitstekend (80-95% reductie). SVG's zijn XML-gebaseerd en sterk repetitief.
- JSON: comprimeert zeer goed (75-90% reductie). API-responses en configuratiedata profiteren aanzienlijk.
- XML- en RSS-feeds: comprimeren zeer goed dankzij hun repetitieve tag-structuur.
- Webfonts (WOFF/WOFF2): WOFF2-fonts bevatten al intern Brotli-compressie, dus aanvullende compressie aan serverzijde levert weinig op. WOFF-fonts bevatten lichtere compressie en kunnen marginaal profiteren van Gzip.
Wat NIET gecomprimeerd zou moeten worden
Niet alle bestandstypen profiteren van compressie, en sommige zouden actief uitgesloten moeten worden:
- JPEG-, PNG-, WebP-, AVIF-afbeeldingen: deze formaten zijn al gecomprimeerd. Ze door Gzip of Brotli halen verspilt CPU-tijd en kan de bestandsgrootte zelfs licht vergroten.
- Videobestanden (MP4, WebM): al gecomprimeerd met zeer efficiënte codecs. Compressie aan serverzijde voegt overhead toe zonder voordeel.
- Audiobestanden (MP3, AAC, OGG): idem als video, al gecomprimeerd.
- ZIP-, GZIP- en andere archieven: al gecomprimeerd per definitie.
- PDF-bestanden: de meeste PDF's gebruiken interne compressie. Aanvullende compressie levert verwaarloosbare besparingen op.
Het comprimeren van reeds gecomprimeerde bestanden verspilt server-CPU bij elk request en kan zelfs licht grotere uitvoer opleveren. De meeste webserver-configuraties en WordPress-cachingplugins beperken compressie correct tot tekstgebaseerde MIME-types, maar het is de moeite waard te verifiëren dat binaire bestanden zijn uitgesloten.
Wat InspectWP controleert
InspectWP onderzoekt de response-header Content-Encoding die uw WordPress-site retourneert om te bepalen of compressie actief is. Specifiek wordt gezocht naar gzip, br (Brotli) of deflate in de header-waarde. Wordt geen compressie gedetecteerd, dan signaleert het rapport dit als prestatieprobleem met de aanbeveling om Gzip- of Brotli-compressie in te schakelen. De gedetecteerde compressiemethode wordt getoond in de prestatiesectie van het rapport, en geeft u een helder beeld of uw server correct is geconfigureerd om transferomvang te beperken.