Brotli vs Gzip: vilken ska din server använda?
Båda krymper din text innan den träffar tråden, och båda är i princip fri hastighet. Den ärliga jämförelsen - som komprimerar hårdare, vilket är snabbare, och varför svaret beror på om filen är cacheable.
Det korta svaret, så att du kan sluta läsa om det är allt du behöver: Erbjud båda och låt webbläsaren välja. Servera statiska filer Brotli-komprimerade med en hög inställning och cache resultatet; servera dynamiska svar med Gzip eller låg nivå Brotli. Varje webbläsare som släppts under det senaste decenniet stöder båda, så det finns ingen kompatibilitets anledning att välja.
Ju längre svaret är mer intressant, eftersom "Brotli är nyare så använd Brotli" är exakt den typ av råd som gör en upptagen API-server 20% långsammare.
Vad komprimering gör
Texten är väldigt repetitiv. HTML, CSS, JavaScript och JSON upprepar samma taggar, klassnamn, nyckelord och blankstegsmönster tusentals gånger i en fil. Både Gzip och Brotli hittar dessa upprepningar och kodar dem kompakt, så en 200 KB-fil färdas som 40-något KB och webbläsaren återuppbygger den vid ankomsten. Mindre data på tråden innebär snabbare belastningar, och effekten är störst exakt där det betyder mest – mobila anslutningar.
Komprimering hjälper bara text. JPEG, PNG, WebP, MP4 och WOFF2 är redan komprimerade - kör Gzip över dem bränner CPU för en bråkdel av en procent, och kan ibland göra filen större. Komprimera text; optimera media separat.
Jämförelsen
| Gzip | Brotli | |
|---|---|---|
| Släppt | 1992 | 2015 |
| Kompressionsnivåer | 1–9 | 0–11 |
| Typiska textbesparingar | ~70% | ~75–80% |
| Inbyggd ordbok | Nej | Ja – vanliga webbsträngar |
| Hastighet vid maximal inställning | Snabb | Mycket långsammare |
| Hastighet vid låga inställningar | Snabb | Jämförbar |
| Webbläsarstöd | Universal | Universal (sedan 2016) |
| Fungerar över vanlig HTTP | Ja. | HTTPS endast i praktiken |
Brotlis kant kommer delvis från en bättre algoritm och delvis från något smart: det levereras med en inbyggd ordbok på cirka 13 000 vanliga webbsträngar - saker som </div>, function, charset=utf-8. – De kostar nästan ingenting att koda eftersom båda sidor redan har dem. Det är därför Brotlis fördel är störst på små filer, där Gzip ännu inte har haft en chans att bygga upp sin egen ordbok från innehållet.
Varför den nya inte alltid är den rätta
Här är den del som avgör din konfiguration. Brotli på nivå 11 är dramatiskt långsammare att komprimera än Gzip – ofta en storleksordning eller mer. Dekompression är snabbt antingen sätt; Det är kompressionssidan som kostar.
Om det spelar någon roll beror helt på hur många gånger den komprimerade utmatningen används.
För en statisk, cachebar fil din CSS-bunt, din app JavaScript, en teckensnittsfri HTML-sida som sällan ändras - du komprimerar en gång och serverar samma komprimerade kopia tusentals eller miljoner gånger. Den långsamma komprimeringen sker en gång, vid bygg eller på första begäran, och ingen besökare väntar någonsin på det. Använd Brotli 11. Det finns ingen nackdel.
För ett svar som genereras per begäran en personlig instrumentpanel, en API-slutpunkt, en sökresultatsida – det finns ingen återanvändning. Varje svar komprimeras färskt, och Brotli 11 skulle lägga till mätbar latens och CPU till var och en. Här vill du ha Gzip på medelnivå, eller Brotli på 4 eller 5, vilket är ungefär Gzip-hastighet samtidigt som du komprimerar något bättre.
Det klassiska misstaget är att aktivera Brotli vid sitt standardmaximum på en dynamisk appserver och sedan undra varför svarstiderna blev värre under belastning. Om du tar ett nummer från den här artikeln: 11 för cacheable, 45 för on-the-fly.
Kontrollera vad du faktiskt tjänar
Konfiguration och verklighet glider förvånansvärt ofta ifrån varandra - en proxy strips rubriken, en regel matchar bara vissa innehållstyper, någon stängde av den under en incident i 2023. Ett kommando berättar sanningen:
curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/app.css | grep -i content-encodingOm inget kommer tillbaka, du skickar okomprimerad text. Prova det mot din HTML, din huvudsakliga stilmall och din största JavaScript bunt det är vanligt att en av de tre att ha missat.
Där zstd passar in
Ett tredje namn har dykt upp i den här konversationen: zstd eller Zstandard. Chrome och Firefox stöder båda det som en innehållskodning nu, och det är värt att veta vad det är för, eftersom inramningen skiljer sig från Brotli.
Brotlis tonhöjd är "mindre än Gzip". Zstds tonhöjd är "mycket snabbare än Brotli vid liknande förhållanden". Vid de låg-till-mitten inställningar du skulle använda för dynamiska svar, komprimerar zstd betydligt snabbare än någon av de andra för ungefär samma utgångsstorlek, vilket gör det intressant exakt där Brotli 11 är en dålig idé per-begäran innehåll som genereras i farten.
För statiska cachefiler vinner Brotli 11 fortfarande i allmänhet på storlek, och eftersom komprimeringstiden inte spelar någon roll där, förblir det rätt val. Så formen på svaret förändras inte riktigt; zstd är ett bättre alternativ för den dynamiska halvan än Gzip är, på klienter som stöder det.
Stödet är bra men inte universellt, och Safari har varit långsammare att anta det än de andra. Det är bra - innehållsförhandling innebär att du erbjuder det och kunder som inte förstår det får bara Brotli eller Gzip istället. Det är additiv, inte migration.
Du behöver egentligen inte välja
Webbläsare annonsera vad de stöder på varje begäran via Accept-Encoding rubrik. En CDN läser det och tjänar det bästa alternativet som klienten kan hantera - Brotli där det finns tillgängligt, Gzip som en reserv - och cachar båda varianterna separat, nyckelad av kodning. Du aktiverar det en gång och det rätta händer per besökare, för alltid.
Vilket är verkligen svaret på frågan i titeln. "Brotli vs Gzip" ramar in det som ett beslut, och det har inte varit ett i åratal. Beslutet värt att göra är komprimeringen nivå, och det beror på om det du komprimerar kommer att återanvändas.
Snabba svar
Är Brotli bättre än Gzip?
Brotli komprimerar text ungefär 15 till 20 procent mindre än Gzip, så för filer du komprimerar en gång och tjänar många gånger är det klart bättre. För svar som genereras färskt på varje begäran är Brotli vid sin högsta inställning mycket långsammare än Gzip och lägger till latens under belastning. Det rätta svaret är att erbjuda båda och variera komprimeringsnivån efter om innehållet är cachelagrat.
Vilken Brotli-komprimeringsnivå ska jag använda?
Använd nivå 11 för statiska cachelager som CSS och JavaScript-buntar, där den långsamma komprimeringen sker en gång och resultatet återanvänds. Använd nivå 4 eller 5 för dynamiska svar per begäran, vilket är ungefär Gzip-hastighet medan du fortfarande komprimerar något bättre. Nivå 11 på dynamiskt innehåll är den vanligaste felkonfigurationen och det ökar mätbart svarstiderna.
Stöder alla webbläsare Brotli?
Ja, alla nuvarande webbläsare har stöd för Brotli sedan runt 2016, inklusive Chrome, Firefox, Safari och Edge. Webbläsare annonsera stöd i Accept-kodning begäran header, så en server eller CDN kan tjäna Brotli till klienter som accepterar det och falla tillbaka till Gzip för något som inte gör det. Det finns ingen kompatibilitet anledning att undvika det.
Ska jag komprimera bilder med Gzip eller Brotli?
Nej. JPEG-, PNG-, WebP-, AVIF-, MP4- och WOFF2-filer är redan komprimerade, så att köra Gzip eller Brotli över dem förbrukar CPU för en försumbar besparing och ibland gör filen något större. Komprimera textformat som HTML, CSS, JavaScript, JSON och SVG, och hantera bilder separat genom formatkonvertering och storleksändring.
Erbjud båda kodningarna. Komprimera cachelagrade statiska filer hårt med Brotli 11 och låt dem återanvändas; komprimera per begäran svar lätt med Gzip eller Brotli 4 5. Komprimera aldrig bilder eller video. Kör sedan ett curl kommando för att bekräfta vad du konfigurerat är vad du faktiskt serverar.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT - mestadels värd - sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till Vismas förvärv, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.
