Brotli vs Gzip: hvilken skal din server bruge?
Begge krymper din tekst, før den rammer ledningen, og begge er dybest set fri hastighed. Den ærlige sammenligning – som komprimerer hårdere, hvilket er hurtigere, og hvorfor svaret afhænger af, om filen kan cachelagres.
Det korte svar, så du kan stoppe med at læse, hvis det er alt, hvad du har brug for: tilbyde begge dele, og lade browseren vælge. Betjen statiske filer Brotli-komprimeret med høj indstilling, og cachelagre resultatet. Betjen dynamiske svar med Gzip eller Brotli på lavt niveau. Hver browser udgivet i det sidste årti understøtter begge dele, så der er ingen kompatibilitetsgrund at vælge.
Det længere svar er mere interessant, fordi "Brotli er nyere så brug Brotli" er præcis den slags råd, der gør en travl API-server 20% langsommere.
Hvad komprimering gør
Teksten er meget gentagende. HTML, CSS, JavaScript og JSON gentager de samme tags, klassenavne, nøgleord og mønstre med mellemrum tusindvis af gange i en fil. Både Gzip og Brotli finder disse gentagelser og koder dem kompakt, så en 200 KB fil rejser som 40-noget KB og browseren genopbygger det ved ankomsten. Færre data på ledningen betyder hurtigere belastninger, og effekten er størst, præcis hvor den betyder mest – mobilforbindelser.
Komprimering hjælper kun tekst. JPEG, PNG, WebP, MP4 og WOFF2 er allerede komprimeret - kører Gzip over dem brænder CPU for en brøkdel af en procent, og kan lejlighedsvis gøre filen større. Komprimer tekst og optimer medierne separat.
Sammenligningen
| Gzip | Brotli | |
|---|---|---|
| Udgivet | 1992 | 2015 |
| Kompressionsniveauer | 1–9 | 0–11 |
| Typisk tekstbesparelse | ~70% | ~75–80% |
| Indbygget ordbog | Nr | Ja almindelige webstrenge |
| Hastighed ved maksimal indstilling | Hurtigt | Meget langsommere |
| Hastighed ved lave indstillinger | Hurtigt | Sammenlignelig |
| Understøttelse af browser | Universal | Universal (siden 2016) |
| Fungerer over almindelig HTTP | Ja, ja | HTTPS kun i praksis |
Brotlis kant kommer dels fra en bedre algoritme og dels fra noget smart: det leveres med en indbygget ordbog på omkring 13.000 almindelige webstrenge - ting som </div>, function, charset=utf-8. Disse koster næsten ingenting at kode, fordi begge sider allerede har dem. Derfor er Brotlis fordel størst på små filer, hvor Gzip endnu ikke har haft mulighed for at opbygge sin egen ordbog ud fra indholdet.
Hvorfor den nye ikke altid er den rigtige
Her er den del, der bestemmer din konfiguration. Brotli på niveau 11 er dramatisk langsommere at komprimere end Gzip – ofte en størrelsesorden eller mere. Dekompression er hurtig uanset hvad; det er kompressionssiden, der koster.
Om det betyder noget, afhænger helt af, hvor mange gange det komprimerede output bliver brugt.
ForTil en statisk, cachevenlig fil - din CSS bundle, din app JavaScript, en skrifttype-fri HTML-side, der sjældent ændres - du komprimere en gang og tjene den samme komprimerede kopi tusindvis eller millioner af gange. Den langsomme komprimering sker én gang, når den bygges eller efter første anmodning, og ingen besøgende venter nogensinde på den. Brug Brotli 11. Der er ingen ulemper.
For et svar, der genereres pr. anmodning – et personligt dashboard, et API-endepunkt, en søgeresultatside – er der ingen genbrug. Hvert svar er komprimeret frisk, og Brotli 11 ville tilføje målbar ventetid og CPU til hver enkelt. Her vil du have Gzip på et middelhøjt niveau, eller Brotli på 4 eller 5, hvilket er omtrent Gzip-hastighed, mens du stadig komprimerer lidt bedre.
Den klassiske fejl er at aktivere Brotli på sit standardmaksimum på en dynamisk appserver og derefter undre sig over, hvorfor responstiderne blev værre under belastning. Hvis du tager et nummer fra denne artikel: 11 for cacheable, 4x5 for on-the-fly.
Tjekke, hvad du rent faktisk tjener
Konfiguration og virkelighed glider fra hinanden overraskende ofte - en proxy strimler overskriften, en regel matcher kun nogle indholdstyper, nogen slukkede den under en hændelse i 2023. En kommando fortæller dig sandheden:
curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/app.css | grep -i content-encodingHvis intet kommer tilbage, sender du ukomprimeret tekst. Prøv det mod din HTML, dit primære stilark og dit største JavaScript-bundt – det er almindeligt, at en af de tre er gået glip af noget.
Hvor zstd passer ind
Et tredje navn er dukket op i denne samtale: zstd eller Zstandard. Chrome og Firefox understøtter begge det som en indholdskodning nu, og det er værd at vide, hvad det er til, fordi indramningen er forskellig fra Brotli.
Brotlis tonehøjde er "mindre end Gzip". Zstd's tonehøjde er "meget hurtigere end Brotli i lignende forhold". Ved de lav-til-mellem indstillinger, du ville bruge til dynamiske svar, komprimerer zstd betydeligt hurtigere end nogen af de andre for nogenlunde samme output størrelse, hvilket gør det interessant præcis, hvor Brotli 11 er en dårlig ide per-request indhold genereret på flue.
For statiske cachefiler vinder Brotli 11 stadig generelt på størrelse, og da komprimeringstiden ikke betyder noget der, forbliver det det rigtige valg. Så formen af svaret ændrer sig ikke rigtig; zstd er en bedre mulighed for den dynamiske halvdel end Gzip er på klienter, der understøtter det.
Støtten er god, men ikke universel, og Safari har været langsommere end de andre. Det er fint - indholdsforhandlinger betyder, at du tilbyder det, og kunder, der ikke forstår det, får bare Brotli eller Gzip i stedet. Det er et additiv, ikke en migration.
Du behøver faktisk ikke at vælge
Browsere annoncerer, hvad de understøtter på hver anmodning via appen Accept-Encoding overskrift. En CDN læser, at og tjener den bedste løsning, som klienten kan håndtere - Brotli hvor tilgængelig, Gzip som en fallback - og cacher begge varianter separat, nøglet ved kodning. Du aktiverer det én gang, og det rigtige sker pr. besøgende, for evigt.
Hvilket virkelig er svaret på spørgsmålet i titlen. "Brotli vs Gzip" rammer det som en beslutning, og det har det ikke været i årevis. Beslutningen værd at træffe er kompressionsniveauet, og det afhænger af, om den ting, du komprimerer, vil blive genbrugt.
Hurtige svar
Er Brotli bedre end Gzip?
Brotli komprimerer tekst omkring 15-20 procent mindre end Gzip, så for filer, du komprimerer én gang og tjener mange gange, er det klart bedre. For svar, der genereres frisk på hver anmodning, er Brotli ved sin højeste indstilling langt langsommere end Gzip og vil tilføje ventetid under belastning. Det rigtige svar er at tilbyde begge dele og variere komprimeringsniveauet, alt efter om indholdet kan cachelagres.
Hvilket Brotli-kompressionsniveau skal jeg bruge?
Brug niveau 11 til statiske cacheaktive aktiver som CSS og JavaScript bundter, hvor den langsomme komprimering sker én gang, og resultatet genbruges. Brug niveau 4 eller 5 til dynamiske svar pr. anmodning, hvilket er omtrent Gzip-hastighed, mens du stadig komprimerer lidt bedre. Niveau 11 for dynamisk indhold er den mest almindelige fejlkonfiguration, og den øger responstiden målbart.
Støtter alle browsere Brotli?
Ja, alle nuværende browsere har understøttet Brotli siden omkring 2016, herunder Chrome, Firefox, Safari og Edge. Browsere annoncere støtte i Accept-kodning anmodning header, så en server eller CDN kan tjene Brotli til klienter, der accepterer det og falde tilbage til Gzip for noget, der ikke gør. Der er ingen grund til at undgå det.
Skal jeg komprimere billeder med Gzip eller Brotli?
Nej. JPEG, PNG, WebP, AVIF, MP4 og WOFF2 filer er allerede komprimeret, så kører Gzip eller Brotli over dem bruger CPU til en ubetydelig besparelse og lejlighedsvis gør filen lidt større. Komprimer tekstformater som HTML, CSS, JavaScript, JSON og SVG, og håndter billeder separat gennem formatkonvertering og ændring af størrelse.
Tilbyd begge kodninger. Komprimer statiske filer, der kan gemmes, hårdt med Brotli 11, og lad dem blive genbrugt. Komprimer svar pr. anmodning let med Gzip eller Brotli 45. Komprimer aldrig billeder eller videoer. Kør derefter én curl-kommando for at bekræfte, at det, du har konfigureret, er det, du rent faktisk serverer.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
