[WP] Gzip vs Brotli-compressie: het verschil tussen de twee compressie-algoritmen

Om websites sneller te maken, ook die met het CMS WordPress, is het nuttig om op de server datacompressie in te stellen. Dan laden de gegevens tussen webserver en browser sneller en wordt de hele website sneller. Het is een van de factoren waar websitebeheerders het meest over nadenken. Gzip-compressie wordt veel gebruikt, en op veel webservers is er een groeiende verschuiving van gzip naar Brotli -compressie.

1️⃣ Wat is compressie?

Site URL: als je die opent, begint er een gesprek tussen browser en server. Daarbij vertelt de browser de server of hij compressie van content (Compression) ongedaan kan maken en welke compressie-algoritmen hij gebruikt. Zo kan de browser de gegevens goed uitpakken als de server ze gecomprimeerd stuurt. Met een server en browser die compressie-algoritmen ondersteunen, laadt je website dus nog sneller.

Als een webbrowser verbinding maakt met een server, stuurt hij headers mee zoals gzip- of Brotli-compressie. Gegevens die met een van de twee zijn gecomprimeerd, komen bij de browser aan, en gecomprimeerde gegevens laden sneller dan niet-gecomprimeerde.

Content-encoding: gzip
Content-encoding: br

De bestanden die worden gecomprimeerd, zijn vooral tekst:
· HTML
· CSS
· JavaScript

2️⃣ Wat is Gzip-compressie?

De gangbare compressie-algoritmen bij webhosts zijn Gzip en Brotli. De bèta van Gzip verscheen in 1992 en versie 1.0 in 1993. In het algemeen geldt: Gzip is een van de standaardmethoden om gegevens die via internet worden verzonden te comprimeren. Het is gebaseerd op DEFLATE, een vroeg compressie-algoritme, en dankt zijn naam aan gzip, een eerder ontwikkeld programma voor bestandscompressie op Unix.

DEFLATE combineert het LZ77-algoritme (Lempel-Ziv 1977) met Huffman-codering. LZ77 zoekt naar herhaalde gegevens, vindt overeenkomende reeksen en vervangt die door codes. Huffman-codering gebruikt hoe vaak elk teken voorkomt om de kortste bitcodes toe te wijzen.

Gzip comprimeert gegevens met DEFLATE en comprimeert, via de header ‘Accept-Encoding: gzip’ in HTTP-verzoeken en -antwoorden, alleen als de client Gzip ondersteunt. Die compressie helpt websites sneller te laden.

3️⃣ Wat is Brotli-compressie?

Brotli werd in 2013 ontwikkeld door Google-engineers Jyrki Alakuijala en Zoltán Szabadka.

Gzip was oorspronkelijk bedoeld om bestanden te comprimeren, maar werd aangepast voor gebruik op het web. Brotli daarentegen werd vanaf het begin voor het web ontwikkeld. Met Brotli kan de webserver content dus comprimeren voordat die naar de browser gaat. Omdat het wordt gecomprimeerd voordat het naar de browser wordt gestreamd, is het een betere, geavanceerdere aanpak.

Brotli gebruikt dezelfde twee kerntechnieken als GZIP-compressie: LZ77 en Huffman-codering.

4️⃣ Gzip-compressie vs Brotli-compressie

Gzip comprimeert (en pakt uit) met de methode DEFLATE, terwijl Brotli een eigen formaat gebruikt dat contextmodellering toevoegt aan LZ77 en Huffman-codering.

• Gzip comprimeert sneller dan Brotli.
• Brotli is speciaal voor het web ontworpen.
• Brotli biedt op elk compressieniveau een betere compressieverhouding (dus kleinere gecomprimeerde bestanden).
• Vergeleken met Gzip comprimeert Brotli deze drie bestandstypen beter: HTML met 21%, CSS met 17% en JavaScript met 14%.

Steeds meer webservers geven de voorkeur aan Brotli boven Gzip. Omdat Brotli is ontworpen om streams direct te comprimeren, zou het uitpakken aan de front-end tot 64% sneller zijn dan bij Gzip.

RFC 1952, gepubliceerd in mei 1996, legt uit dat het Gzip-formaat de compressiemethode DEFLATE gebruikt en een CRC-waarde bevat om beschadigde gegevens te herkennen. De CRC-32-waarde en de grootte van de oorspronkelijke gegevens staan aan het einde van de gecomprimeerde gegevens.

RFC 7932, gepubliceerd in juli 2016, stelt dat Brotli comprimeert door het LZ77-algoritme te combineren met Huffman-codering. Daarbovenop gebruikt het de vorige twee bytes van de ongecomprimeerde gegevens als context om Huffman-codes te kiezen, en in plaats van herhaalde reeksen kan het ook verwijzen naar woorden in een statisch woordenboek van 122.784 bytes.

De twee formaten verschijnen in de antwoordheader als [Content-Encoding: gzip] en [Content-Encoding: br]. De waarde [br] werd in RFC 7932 geregistreerd als HTTP-contentcodering.

5️⃣ Gzip- en Brotli-compressie gemeten: een Nginx + Apache-server

Op een WordPress-server met Nginx en Apache samen werden de antwoorden voor één bericht, het standaard-CSS-bestand voor blokken van WordPress en het jQuery-bestand vergeleken, waarbij alleen de verzoekheader veranderde. Verzoeken met alleen gzip in [Accept-Encoding], met alleen br en zonder header werden met curl vanaf dezelfde server verstuurd.

for ae in gzip br ''; do echo == ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/hello-world/ | grep -i -E '^(content-encoding|size)'; done

== gzip
content-encoding: gzip
size: 21390
== br
content-encoding: br
size: 20190
== none
size: 90833

De HTML van één bericht werd bij het gzip-verzoek gecomprimeerd tot 21.390 bytes en bij het br-verzoek tot 20.190 bytes, en het verzoek zonder header kreeg de ongecomprimeerde 90.833 bytes. Het br-antwoord was 1.200 bytes (5,6%) kleiner dan gzip.

for f in wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do for ae in gzip br ''; do echo == ${f##*/} ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/$f | grep -i -E '^(content-encoding|size)'; done; done

== style.min.css gzip
content-encoding: gzip
size: 19655
== style.min.css br
size: 140829
== style.min.css none
size: 140829
== jquery.min.js gzip
content-encoding: gzip
size: 30633
== jquery.min.js br
size: 87553
== jquery.min.js none
size: 87553

Bij het gzip-verzoek werd het CSS-bestand gecomprimeerd tot 19.655 bytes en het jQuery-bestand tot 30.633 bytes. Met alleen br of zonder header gaf de server de originelen van 140.829 en 87.553 bytes ongewijzigd terug, zonder header [Content-Encoding].

nginx -V 2>&1 | grep -c brotli

0

httpd -M 2>/dev/null | grep -E 'brotli|deflate'

 deflate_module (shared)
 brotli_module (shared)

Statische bestanden zoals CSS en JS worden direct door Nginx geleverd en gecomprimeerd, en omdat Nginx in deze opstelling geen Brotli-module heeft, comprimeert het alleen met gzip.

Voor HTML beantwoordt WordPress het verzoek dat Nginx doorstuurt naar Apache, en Apache comprimeert het. Apache heeft zowel de Brotli-module als de module [mod_deflate], die Gzip-compressie afhandelt.

for f in hello-world/ wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do echo == $f; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/$f | grep -i -E '^(content-encoding|size)'; done

== hello-world/
content-encoding: gzip
size: 21390
== wp-includes/css/dist/block-library/style.min.css
content-encoding: gzip
size: 19655
== wp-includes/js/jquery/jquery.min.js
content-encoding: gzip
size: 30633

Een Brotli-module op de server betekent niet dat de browser met Brotli gecomprimeerde antwoorden krijgt. Bij een verzoek met [gzip, deflate, br, zstd], dezelfde waarde die Edge 155 stuurt, comprimeerde Apache de HTML ook met gzip, en alle drie de bestanden kwamen terug in gzip.

Ook toen br vóór gzip werd gezet of als voorkeur werd gemarkeerd, zoals in [br;q=1.0, gzip;q=0.5], kwam de HTML terug in gzip. Toen hetzelfde bericht en de twee bestanden in Edge werden geopend, werden ze ook allemaal in gzip geleverd.

De tijd tot de eerste byte is de mediaan van de waarden [time_starttransfer] van curl, telkens 40 keer gemeten in willekeurige volgorde; elk verzoek opende een nieuwe verbinding, dus de TLS-verbindingstijd zit erin. Voor HTML duurde het ongecomprimeerde antwoord 22,7 ms, gzip 26,3 ms, br 26,5 ms en het browserachtige verzoek 25,0 ms. CSS en JS duurden 18–21 ms, met of zonder compressie.

De compressiesnelheid van Gzip en Brotli is hier niet gemeten, maar vergeleken met openbare bronnen. RFC 7932 stelt dat Brotli met een duidelijk hogere compressieverhouding comprimeert dan het programma gzip en veel sneller uitpakt dan huidige LZMA-implementaties. In de Brotli-repository legt Google uit dat Brotli qua snelheid vergelijkbaar is met deflate, maar compacter comprimeert.

In 2015 testte Cloudflare beide methoden op 10.655 HTML-, CSS- en JavaScript-bestanden. Brotli op de hoogste kwaliteit leverde gemiddeld 1,19 keer kleinere resultaten dan zlib op de hoogste kwaliteit, maar comprimeerde met 0,5 MB per seconde, veel trager dan de 41,9 MB van zlib niveau 9. Brotli niveau 4 had een vergelijkbare compressieverhouding als zlib niveau 8 en was gemiddeld iets sneller, maar 1,48 keer trager als je alleen naar bestanden kleiner dan 64 KB kijkt.

We hebben gekeken naar het optimaliseren van een website door bestanden als HTML, CSS en JavaScript te comprimeren. Voor een snellere website horen bestandscompressie en Afbeeldingsoptimalisatie tot de essentiële onderdelen.

🔢 FAQ & aanbevolen content

ℹ️ Affiliatemelding
De content van deze site bevat affiliatelinks. Koopt een bezoeker via een van deze links een product of dienst, dan ontvangt deze site een commissie van de verkoper. Het bedrag dat de koper betaalt ^{(bij acties gaat het omlaag ↓)} wordt daardoor niet hoger. De vermelde prijzen, kortingen en voorraad gelden op het moment van schrijven en kunnen afwijken; controleer ze daarom vóór je aankoop bij de verkoper. Producten worden gekozen en beoordeeld volgens onze eigen criteria, en commissies hebben geen invloed op de volgorde of de inhoud van de beoordelingen.