Brotli vs Gzip: vilken ska din server använda?
Båda krymper din text innan den träffar ledningen, 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 cachelagrad.
Det korta svaret, så att du kan sluta läsa om det är allt du behöver: eErbjud båda och låt webbläsaren välja. Servera statiska filer som är Brotli-komprimerade med hög inställning och cachelagra resultatet. Servera dynamiska svar med Gzip eller Brotli på låg nivå. Varje webbläsare som släppts under det senaste decenniet stöder båda, så det finns ingen kompatibilitetsskäl att välja.
Ju längre svaret är mer intressant, eftersom "Brotli är nyare så använd Brotli" är precis den typ av råd som gör en upptagen API-server 20% långsammare.
Vad kompression gör
Texten är väldigt repetitiv. HTML, CSS, JavaScript och JSON upprepar samma taggar, klassnamn, nyckelord och blankteckenmö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. Färre data på tråden innebär snabbare belastningar, och effekten är störst exakt där den spelar störst roll – 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 och 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 | Universell | Universal (sedan 2016) |
| Fungerar över vanlig HTTP | Ja, ja | HTTPS endast i praktiken |
Brotlis kant kommer dels från en bättre algoritm och dels från något smart: den levereras med en inbyggd ordbok på cirka 13 000 vanliga webbsträngar saker som </div>, function, charset=utf-8. Dessa 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 en egen ordbok från innehållet.
Varför den nya inte alltid är den rätta
Här är den del som bestämmer 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 produktionen används.
För en statisk, cachebar fil - din CSS-bunt, din app JavaScript, en teckensnittsfri HTML-sida som sällan ändras - komprimerar du en gång och tjänar samma komprimerade kopia tusentals eller miljoner gånger. Den långsamma komprimeringen sker en gång, vid byggnation eller vid första begäran, och ingen besökare väntar någonsin på den. 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 – finns det ingen återanvändning. Varje svar komprimeras färskt, och Brotli 11 skulle ge mätbar latens och CPU till varenda en. Här vill du ha Gzip på medelhög nivå, eller Brotli på 4 eller 5, vilket är ungefär Gzip-hastighet medan du fortfarande 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 sämre under belastning. Om du tar ett nummer från den här artikeln: 11 för cacheable, 4x5 för on-the-fly.
Kontrollera vad du faktiskt serverar
Konfiguration och verklighet glider ifrån varandra förvånansvärt ofta - en proxy strips rubriken, en regel matchar bara vissa innehållstyper, någon stängde av den under en incident i 2023. Ett kommando säger dig sanningen:
curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/app.css | grep -i content-encodingOm inget kommer tillbaka skickar du okomprimerad text. Prova det mot din HTML, din huvudsakliga stilmall och ditt största JavaScript-paket – det är vanligt att någon av de tre har missats.
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 ä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 en migration.
Du behöver egentligen inte välja
Webbläsare annonserar vad de stöder på varje begäran via Accept-Encoding rubrik. Ett 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 verkligen är svaret på frågan i titeln. "Brotli vs Gzip" ramar in det som ett beslut, och det har inte varit ett på flera år. Beslutet värt att göra är komprimeringsnivån, och det beror på om den sak du komprimerar kommer att återanvändas.
Snabba svar
Är Brotli bättre än Gzip?
Brotli komprimerar text ungefär 15-20 procent mindre än Gzip, så för filer som du komprimerar en gång och servar många gånger är det klart bättre. För svar som genereras färska på varje begäran är Brotli vid sin högsta inställning mycket långsammare än Gzip och kommer att lägga till latens under belastning. Det rätta svaret är att erbjuda båda och variera komprimeringsnivån beroende på om innehållet är cachelagrat.
Vilken Brotli-komprimeringsnivå ska jag använda?
Använd nivå 11 för statiska cacheaktiva tillgångar 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 den ökar mätbart svarstiderna.
Stödjer alla webbläsare Brotli?
Ja, alla nuvarande webbläsare har stöd för Brotli sedan 2016, inklusive Chrome, Firefox, Safari och Edge. Webbläsare annonsera stöd i Acceptera-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 kompatibilitetsskäl för 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 statiska filer hårt med Brotli 11 och låt dem återanvändas. Komprimera svar per begäran lätt med Gzip eller Brotli 45. Komprimera aldrig bilder eller video. Kör sedan ett curl-kommando för att bekräfta att det du har konfigurerat faktiskt är det du serverar.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT – mestadels som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, 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.
