Hoppa till innehåll 
Med brotli vs gzip Jag bestämmer vilket format jag ska använda live utifrån mätbara effekter på TTFB, datavolym och Core Web Vitals. Från tillförlitliga benchmark-tester vet jag att: Brödpinne komprimerar HTML, CSS och JS i genomsnitt 15–21 % starkare och dekomprimerar i webbläsaren i många fall snabbare, delvis upp till 64 % [1][4][5].
Centrala punkter
- kompressionsgrad: Brotli minskar textresurserna med i genomsnitt 15–21 % mer än Gzip – märkbart för FCP/LCP [1][4][5].
- Scenarier: Statiska tillgångar vid kanten med Brotli, dynamiska svar ofta med Gzip eller måttlig Brotli-nivå.
- effektnivåer: Brotli nivå 4 är ofta snabbare och effektivare än Gzip nivå 6; höga nivåer endast vid förkomprimering [4][5].
- Hosting: Effektiv komprimeringshosting med HTTP/2/3, caching och CDN förkortar rundresorna avsevärt [3][5][8].
- Övervakning: Kontrollera alltid förändringar med RUM och syntetiska tester via FCP, LCP och TTFB.
Kompatibilitet, rubriker och cachningsnycklar
För att Brotli eller Gzip ska fungera stabilt ser jag till att Innehållsförhandling. Webbläsaren skickar Accept-Encoding, svarar servern med Innehållskodning (br, gzip eller identity). Viktigt: Vary: Accept-Encoding hör på varje komprimerat svar så att cacher och CDN korrekt separerar olika varianter. Annars levererar cachen en Brotli-fil till en klient som bara förstår Gzip. På CDN-nivå kontrollerar jag att Accept-Encoding Del av Cache-nycklar och att Edge-noderna får lagra både .br- och .gz-varianter.
Jag har dessutom ett robust Återgång redo: om en klient inte kan hantera Brotli får den Gzip; om den inte kan hantera något alls får den okomprimerat. För lokala proxyservrar eller äldre enheter är denna metod guld värd – och den kostar mig ingen tid i vardagen om Vary-kedjan stämmer. Jag arbetar medvetet med ETags: starka ETags per variant eller en hash som inkluderar komprimeringsformen förhindrar felaktiga 304 Ej modifierad Träffar mellan br/gz.
Vad postkomprimering verkligen innebär i vardagen
Effektiv Kompression förkortar inte bara överföringen, utan stabiliserar även laddningstiderna vid varierande mobilkvalitet. Ju mindre HTML, CSS, JavaScript och JSON är, desto snabbare visas det första innehållet, eftersom webbläsaren behöver hämta och packa upp färre byte. Jag prioriterar därför textresurser, eftersom bilder och videor drar större nytta av egna codecs än av HTTP-komprimering. På välkonfigurerade värdar kan tiden till första byte minskas märkbart, eftersom CPU-tid och nätverksväntetid balanseras bättre. Den som rensar upp i sin pipeline vinner dubbelt: mindre bandbredd för Uppgifter och färre omflyttningar tack vare tidigare tillgängliga stilar och skript.
Vilket innehåll ska komprimeras – och vilket inte?
Jag komprimerar målinriktat textbaserad Typer: text/html, text/css, application/javascript, application/json, application/xml, image/svg+xml, application/manifest+json och liknande. För redan komprimerade binära format (bilder, videor, PDF-filer i många fall, WOFF2) sparar jag på CPU: effekten är minimal, latensen kan öka. Också viktigt: en tröskelvärde-regel (t.ex. från 1024–2048 byte) så att små svar inte fördröjs i onödan utan märkbar vinst. I CI kontrollerar jag regelbundet innehållstyp och storlek för att upptäcka felkonfigurationer i ett tidigt skede.
Brotli vs Gzip: siffror som förändrar laddningstiderna
Komprimeras i tester Brödpinne HTML cirka 21 %, JavaScript cirka 14 % och CSS cirka 17 % starkare än Gzip [1][4]. Andra mätningar bekräftar cirka 20 % försprång framför Deflate, metoden bakom Gzip [5][6]. Denna skillnad gör sidorna märkbart snabbare, särskilt vid många textresurser och på mobila enheter med varierande bandbredd. Dessutom går dekomprimeringen i webbläsaren i många fall snabbare med Brotli; upp till 64 % snabbare packningstider i frontend har uppmätts [1]. Sammantaget förkortar bättre Kompressionshastigheter och snabb uppackning tydliggör den kritiska vägen till det synliga innehållet.
Ur nätverksperspektiv: Första RTT:er och CWV
Många märkbara vinster uppstår eftersom mindre svar passar bättre in i de första TCP/QUIC-flygningar passar. Om den initiala HTML-koden tack vare Brotli får plats i ett eller två paket mindre, minskar tiden till FCP/LCP och blockeringen för renderingskritiska resurser. Under HTTP/3 drar anslutningarna dessutom nytta av lägre Huvudlinje-blockering. I mobilnät med högre paketförlustfrekvens jämnar mindre överföringar ut JitterKurva – RUM-data visar då färre avvikelser uppåt. För mig är det en anledning att konsekvent minska just den första HTML-koden och kritisk CSS [3][5][8].
När jag använder Brotli – och när jag använder Gzip
För statisk För tillgångar som HTML, CSS, JS, SVG och WOFF2 använder jag Brotli med hög nivå, förkomprimerat vid byggandet eller direkt på CDN-kanten. Filerna hamnar i cachen och levereras tusentals gånger utan CPU-kostnader. Vid mycket dynamiska svar – personaliserade HTML-vyer, API-JSON, sökning – använder jag oftast Gzip eller Brotli med måttlig nivå så att servern snabbt kan strömma svaret. TTFB-kurvan är avgörande: om den skjuter i höjden sänker jag nivån eller levererar oblockerade delinnehåll tidigare. På så sätt håller jag Svarstider låg, utan att förlora fördelarna med kompakta filer.
Välja rätt kvalitetsnivåer (nivå)
Jag börjar pragmatiskt: Brotli nivå 4 för on-the-fly, nivå 9–11 endast för förkomprimering; Gzip nivå 6 som en solid utgångspunkt [4][5][6]. Om CPU-belastningen ökar vid hög trafik minskar jag först Brotli-nivån och kontrollerar om caching-header och CDN-Edge fungerar korrekt. Ofta räcker det med en liten justering av Cache mer än en hög komprimeringsnivå. I mätningar visade Brotli på nivå 4 ofta bättre filstorlekar med liknande eller lägre latens än Gzip nivå 6 [4]. Den som mäter iterationer noggrant kommer snabbt fram till en inställning som ger Server skyddar och ändå sparar märkbart data.
Konfiguration: Nginx, Apache, Caddy – säkra standardinställningar
Jag satsar på enkla, kontrollerbara standardinställningar. För Nginx innebär det att använda statiska varianter, moderat on-the-fly, rätt typer, rimliga minimistorlekar och korrekt inställning av Vary.
# Nginx (exempel) brotli on; brotli_comp_level 4; brotli_static on; brotli_types text/html text/plain text/css application/javascript application/json application/xml image/svg+xml;
gzip on; gzip_comp_level 6; gzip_min_length 1024; gzip_static on; gzip_vary on; gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml; add_header Vary "Accept-Encoding" always;
Under Apache aktiverar jag mod_brotli och mod_deflate med tydligt ansvar: Brotli först, Deflate som fallback. Minsta storlekar och typer förblir konsekventa.
# Apache (exempel) AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css application/javascript application/json application/xml image/svg+xml BrotliCompressionQuality 4 BrotliWindowSize 22
AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json application/xml image/svg+xml DeflateCompressionLevel 6 Header append Vary "Accept-Encoding"
Viktiga skyddsåtgärder: ingen komprimering av redan komprimerade medier, tester för dubbel komprimering och på proxyservrar. no‑transform undvika om cacher annars undertrycker varianter. Jag kontrollerar med curl: -H „Accept-Encoding: br,gzip“ och -I, om Innehållskodning, Varierande och storlekarna är rimliga.
Förkomprimera statiska tillgångar: Build, Edge, Cache
För frontend med många paket förkomprimerar jag Tillgångar i build och placera .br/.gz-varianter bredvid originalen så att Nginx eller ett CDN levererar rätt version direkt. Stora bibliotek, upprepade CSS-klasser och ramverkskod drar större nytta än genomsnittet, eftersom Brotli använder ett större sökfönster och ett inbyggt ordbok [2][9]. Legitima långvariga cacher (oföränderliga + versionering) minskar dessutom antalet förfrågningar och packningsarbetet. Om du vill leverera globalt kan du kombinera detta med en smart CDN-optimering, så att Edge-noder nära användaren kan leverera data. På så sätt säkerställer mindre filer och geografisk närhet tillsammans lägre Fördröjningar.
Kontrollera dynamiska svar och TTFB
För servergenererade HTML-Visningar räknar streaming och låg latens mer än sista procentenheterna av filstorleken. Jag komprimerar on-the-fly med Gzip eller Brotli på en måttlig nivå, kontrollerar TTFB och CPU per arbetare och ökar nivån endast om det finns tillräckliga reserver. En smart mallordning skickar iväg de första byte tidigt så att webbläsaren kan börja rendera. Dessutom stabiliserar Cachelagring på serversidan svarstiden, eftersom återkommande fragment inte beräknas om varje gång. Denna inställning håller Tips utan att försämra användarupplevelsen.
Leverera streaming och delinnehåll på rätt sätt
Särskilt när det gäller HTML-vyer förlitar jag mig på tidiga floder: kritisk inline-CSS, tidig head-sektion, sedan snabbt strömma body. Komprimering får inte bromsa detta. Därför håller jag koll på buffertstorlekar och flush-punkter och undviker komplicerade Brotli-nivåer vid on-the-fly. Gzip nivå 6 eller Brotli nivå 3–4 ger en bra balans här. Avgörande: servern ska inte vänta tills „allt är klart“, utan skicka i meningsfulla block – det förbättrar FCP och den upplevda reaktionsförmågan.
HTTP/2 och HTTP/3: Kombinera komprimering effektivt
Multiplexing under HTTP/2 och QUIC under HTTP/3 fungerar perfekt med mindre filer, eftersom fler objekt flödar parallellt och med mindre head-of-line-blockering. Särskilt på mobilnät ger reducerade RTT:er och mindre paketförluster i HTTP/3 ytterligare stabilitet. Jag kontrollerar därför alltid om värden stöder båda protokollen med korrekt prioritering och server push-ersättning (Early Hints). Om du jämför inställningarna hittar du användbara detaljer i den kompakta HTTP/3 jämfört med HTTP/2 Översikt. I kombination med Brotli för statiska filer och Gzip för Live-HTML minskar väntetiden och Jitter märkbar.
CDN-strategier: Cache-nycklar, Stale och Edge-Precompression
I CDN ser jag till att .br och .gz Varianterna cachelagras separat och Edge-noder levererar helst de redan förkomprimerade artefakterna. Jag aktiverar stale-under-validering och stale-if-error, så att toppar eller avbrott i backend inte syns. För API-rutter låter jag ofta CDN komprimera live, men med konservativa nivåer. Viktigt: Headers som Cache-kontroll, ETag, Varierande och Innehållskodning måste bilda en harmonisk helhet – annars uppstår bisarra cachemissvågor som försämrar TTFB.
Mobilanvändare: spara bandbredd, spara batteri
På smarttelefonen betalar varje sparad byte direkt på laddningstid och energiförbrukning. De 15–21 % mindre Brotli-filerna minskar överföringstiden och radioaktiviteten; vid begränsad bandbredd märks avlastningen särskilt tydligt [4][5]. Mindre nyttolaster stabiliserar dessutom FCP- och LCP-mätvärdena, eftersom renderingskritiska resurser anländer snabbare. Jag ser också till att Critical CSS är rent och fattar ett tydligt beslut om vilka skript som verkligen får blockera renderingen. I slutändan minskar avvisningsfrekvensen och interaktionerna startar tidigare, eftersom webbläsaren har mindre Last bär.
Teamets arbetsflöde, CI och budgetar
Jag gör kompression till en Pipeline-ämne: Byggsteg genererar .br/.gz, CI mäter storleken på artefakterna och jämför med budgetarna. En pull-begäran som ökar kritiska tillgångar med 30 % upptäcks omedelbart. Dessutom sparar jag rökprov (curl-kontroller av innehållskodning, variation, storleksjämförelse) så att fel inte upptäcks först i produktionen. Jag kör utrullningar som Kanariefågel: Dela trafiken till nya nivåer, övervaka RUM och servermetriker, sedan fullständig utrullning. Tydliga rollback-verktyg (funktioner, Nginx-karta för kvalitetsnivåer) ger mig trygghet vid topptrafik.
Jämförelsetabell: Styrkor i korthet
Följande översikt hjälper mig i samtal med Lag, fatta snabba beslut. Det ersätter inte ett test i din egen stack, men visar var de största effekterna finns. Jag utvärderar alltid kombinationen av filstorlek, CPU-profil och användarpåverkan. Den som tydligt fokuserar på statiska textresurser kommer nästan alltid att vara nöjd med Brotli. För mycket dynamiska applikationer förblir Gzip ett pålitligt Allroundspelare.
| Kriterium | Brödpinne | Gzip | Praktisk effekt |
|---|---|---|---|
| kompressionsgrad | ~15–21 % mindre för HTML/CSS/JS [1][4][5] | Bra, men större än Brotli | Färre byte, snabbare Transmission |
| Dekomprimering i webbläsaren | Ofta snabbare; upp till 64 % i tester [1] | Solid hastighet | Snabbare start synlig Innehåll |
| CPU-profil i realtid | Måttliga nivåer snabbt; höga nivåer dyrt | Medelhöga nivåer mycket snabbt | Välj konservativt vid Live-HTML-nivå |
| Bästa användningsområden | Statiska tillgångar, förkomprimering, kantcache | Dynamiska svar, strömmar, API:er | Separera inställningar efter resurstyp |
| Typiska steg | 4 (on-the-fly), 9–11 (pre) [4][5][6] | 6 som utgångspunkt | Balans mellan storlek och TTFB |
| Kompatibilitet | Bredt stöd, fallback möjligt [3][5][6] | Tillgänglig nästan överallt | Inga verkliga hinder i moderna stackar |
Övervakning och tester: Så mäter jag framsteg
Jag installerar först tydliga Mätetal: TTFB, FCP, LCP, byte/förfrågan och CPU per arbetare. Därefter jämför jag olika varianter – Gzip vs. Brotli, nivåjusteringar, Edge-cache på/av – i identiska tidsfönster. Syntetiska tester visar reproducerbara skillnader, Real-User-Monitoring bekräftar effekten hos riktiga användare. Det är viktigt att ha en ren återställning om CPU-toppar eller cache-miss-vågor uppstår. Först när effekterna är stabila rullar jag ut inställningen. Trafik-starka rutter.
Felsökning: typiska felbilder och snabba kontroller
- Dubbel kompression: Innehållskodningen visar „br, br“ eller „gzip, gzip“. Orsaken är ofta filterkedjor eller proxy + origin. Lösning: låt endast en instans ansvara, prioritera statiska varianter.
- Felaktig variant från cachen: Brotli fungerar hos klienter utan br-stöd. Oftast saknas Vary: Accept-Encoding eller CDN-cache-nyckeln innehåller inte fältet. Lösning: Tvinga Vary och anpassa CDN-nyckeln.
- Exploderande TTFB Efter aktivering: On-the-fly-nivå för hög, CPU-mättnad eller saknad Edge-cache. Lösning: Sänk nivån, aktivera förkomprimering, kontrollera cache-header.
- Ingen storleksvinst: felaktiga typer (redan komprimerade medier), minimilängd för låg eller aggressiv minifiering saknas. Lösning: Kuratera typer, öka minimilängden, kontrollera byggoptimering.
- Skadade nedladdningar: Content‑Length passar inte med det komprimerade svaret eller uppströms borttagen Content‑Encoding. Lösning: vid komprimering, använd Transfer‑Encoding: chunked eller beräkna längden på nytt korrekt.
- Ruckelige renderingsvägar: HTML strömmar för sent, trots att det är komprimerat. Lösning: Strukturera mallen, skicka tidiga byte, kritisk CSS, välj måttliga nivåer.
Kort sammanfattat: Min standardstrategi
För alla cachbara textresurser aktiverar jag Brödpinne och levererar förkomprimerat via Build eller CDN‑Edge. Högdynamiskt innehåll får Gzip eller Brotli på måttlig nivå så att TTFB och interaktivitet förblir stabila. HTTP/2 respektive HTTP/3 körs med korrekt inställda cache-headers, Early Hints och prioriterad laddning av kritiska resurser. Jag håller kvalitetsinställningarna så låga som möjligt så länge filstorlekarna visar en tydlig nytta. Detta tillvägagångssätt kombinerar låg Datavolym med låg serverbelastning – och påskyndar sidorna märkbart.
