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 er cacheable.
Det korte svar, så du kan stoppe med at læse, hvis det er alt, hvad du har brug for: Tilbyd begge dele, og lad browseren vælge. Server statiske filer Brotli-komprimeret ved en høj indstilling og cache resultatet; tjene dynamiske svar med Gzip eller lavt niveau Brotli. Hver browser udgivet i det sidste årti understøtter begge, så der er ingen kompatibilitet grund til 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, søgeord og mellemrumsmønstre 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 der, hvor det 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. Komprimere tekst; optimere medier separat.
Sammenligningen
| Gzip | Brotli | |
|---|---|---|
| Frigivet | 1992 | 2015 |
| Kompressionsniveauer | 1–9 | 0–11 |
| Typiske tekstbesparelser | ~70% | ~75–80% |
| Indbygget ordbog | Nr. | Ja almindelige webstrenge |
| Hastighed ved maksimal indstilling | Hurtig | Meget langsommere |
| Hastighed ved lave indstillinger | Hurtig | Sammenlignelig |
| Browserunderstøttelse | Universal | Universal (fra 2016) |
| Virker over almindelig HTTP | Ja. | HTTPS 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. Det er derfor Brotlis fordel er størst på små filer, hvor Gzip endnu ikke har haft mulighed for at opbygge sin egen ordbog 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 enten måde; det er den kompression side, der koster.
Hvorvidt det betyder noget afhænger helt af, hvor mange gange den komprimerede output bliver brugt.
For en statisk, cache- 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 en gang, ved opbygning eller på første anmodning, og ingen besøgende venter nogensinde på det. Brug Brotli 11. Der er ingen downside.
For et svar genereret pr. anmodning et personligt dashboard, et API-slutpunkt, en søgeresultatside der er ingen genbrug. Hvert svar er komprimeret frisk, og Brotli 11 ville tilføje målbar latens og CPU til hver enkelt. Her vil du have Gzip på et mellemniveau, eller Brotli på 4 eller 5, hvilket er nogenlunde Gzip-hastighed, mens du stadig komprimerer lidt bedre.
Den klassiske fejl er at aktivere Brotli på sit standardmaksimum på en dynamisk app-server og derefter undre sig over, hvorfor responstiderne blev værre under belastning. Hvis du tager et nummer fra denne artikel: 11 til cacheable, 45 til on-the-fly.
Tjek hvad du rent faktisk tjener
Konfiguration og virkelighed glider overraskende ofte fra hinanden - en proxy strips 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 vigtigste stilark og dit største JavaScript-bundt - det er almindeligt, at en af de tre er blevet savnet.
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 pitch er "meget hurtigere end Brotli i lignende forhold". Ved de lave til midterste indstillinger, du ville bruge til dynamiske svar, komprimerer zstd betydeligt hurtigere end nogen af de andre for nogenlunde samme outputstørrelse, hvilket gør det interessant præcis, hvor Brotli 11 er en dårlig ide pr. anmodning indhold genereret på flue.
For statiske cacheable filer, Brotli 11 stadig generelt vinder på størrelse, og da komprimering tid betyder ikke noget der, det forbliver det rigtige valg. Så formen på svaret ændrer sig ikke rigtig; zstd er en bedre mulighed for den dynamiske halvdel end Gzip er, på klienter, der understøtter det.
Support er god, men ikke universel, og Safari har været langsommere til at vedtage det end de andre. Det er fint - indhold forhandling betyder, at du tilbyder det og kunder, der ikke forstår det, får bare Brotli eller Gzip i stedet. Det er additiv, ikke migration.
Du behøver faktisk ikke at vælge
Browsere annoncere, hvad de understøtter på hver anmodning via Accept-Encoding header. En CDN læser det og tjener den bedste mulighed, som klienten kan håndtere - Brotli, hvor det er tilgængeligt, Gzip som en reserve - og cacher begge varianter separat, nøglet ved kodning. Du aktiverer det én gang, og det rigtige sker pr. besøgende, for evigt.
Hvilket er virkelig svaret på spørgsmålet i titlen. "Brotli vs Gzip" rammer det som en beslutning, og det har ikke været en i årevis. Beslutningen værd at gøre er komprimeringen niveau, og det afhænger af, om den ting, du komprimere vil blive genbrugt.
Hurtige svar
Er Brotli bedre end Gzip?
Brotli komprimerer tekst ca. 15 til 20 procent mindre end Gzip, så for filer, du komprimerer en gang og tjener mange gange, er det klart bedre. For svar genereret frisk på hver anmodning, Brotli på sin højeste indstilling er langt langsommere end Gzip og vil tilføje ventetid under belastning. Det rigtige svar er at tilbyde begge og variere kompressionsniveauet, alt efter om indholdet er cachelagerbart.
Hvilket Brotli-kompressionsniveau skal jeg bruge?
Brug niveau 11 til statiske cacheable aktiver som CSS og JavaScript bundter, hvor den langsomme komprimering sker en gang, og resultatet genbruges. Brug niveau 4 eller 5 til dynamiske svar pr. anmodning, hvilket er nogenlunde Gzip-hastighed, mens du stadig komprimerer lidt bedre. Niveau 11 på dynamisk indhold er den mest almindelige fejlkonfiguration og det målbart øger responstider.
Understø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-Koding 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 kompatibilitet 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. Komprimere cacheable statiske filer hårdt med Brotli 11 og lad dem blive genbrugt; komprimere per-anmodninger svar let med Gzip eller Brotli 4 5. Komprimer aldrig billeder eller video. Kør derefter en curl kommando for at bekræfte, hvad du konfigureret er, hvad du rent faktisk tjener.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet i IT - for det meste hosting - 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, sikker infrastruktur enkel at bruge.
