Videre til indhold 
Med brotli vs gzip Jeg beslutter, hvilket format jeg leverer live, på baggrund af målbare effekter på TTFB, datavolumen og Core Web Vitals. Fra pålidelige benchmarks ved jeg: Brødpind komprimerer HTML, CSS og JS i gennemsnit 15–21 % stærkere og dekomprimerer i browseren i mange tilfælde hurtigere, i nogle tilfælde op til 64 % [1][4][5].
Centrale punkter
- kompressionshastighed: Brotli reducerer tekstressourcerne med gennemsnitligt 15–21 % mere end Gzip – mærkbart for FCP/LCP [1][4][5].
- Scenarier: Statiske aktiver ved kanten med Brotli, dynamiske svar ofte med Gzip eller moderat Brotli-niveau.
- effektniveauer: Brotli niveau 4 er ofte hurtigere og mere effektivt end Gzip niveau 6; høje niveauer kun ved forkomprimering [4][5].
- Hosting: Effektiv komprimeringshosting med HTTP/2/3, caching og CDN reducerer rundrejser betydeligt [3][5][8].
- Overvågning: Kontroller altid ændringer via RUM og syntetiske tests via FCP, LCP og TTFB.
Kompatibilitet, header og caching-nøgler
For at Brotli eller Gzip fungerer stabilt, sørger jeg for, at Indholdsforhandling. Browseren sender Accept-Encoding, serveren svarer med Indholdskodning (br, gzip eller identity). Vigtigt: Vary: Accept-Encoding lytter efter hvert komprimeret svar, så caches og CDN'er adskiller forskellige varianter korrekt. Ellers leverer cachen en Brotli-fil til en klient, der kun forstår Gzip. På CDN-niveau kontrollerer jeg, at Accept-Encoding Del af Cache-nøgler og at Edge-noder må gemme både .br- og .gz-varianter.
Jeg har desuden et robust Tilbagefald klar: hvis en klient ikke kan bruge Brotli, får den Gzip; hvis den slet ikke kan bruge noget, får den ukomprimeret. For lokale proxyer eller ældre enheder er denne metode guld værd – og den koster mig ingen tid i hverdagen, hvis Vary-kæden er korrekt. Jeg arbejder bevidst med ETags: stærke ETags pr. variant eller en hash, der inkluderer komprimeringsformen, forhindrer fejlbehæftede 304 Ikke ændret Treffer mellem br/gz.
Hvad postkomprimering virkelig betyder i hverdagen
Effektiv Kompression Det forkorter ikke kun overførslen, men stabiliserer også indlæsningstiderne ved svingende mobilkvalitet. Jo mindre HTML, CSS, JavaScript og JSON er, jo hurtigere vises det første indhold, fordi browseren skal hente og udpakke færre bytes. Jeg prioriterer derfor tekstressourcer, fordi billeder og videoer drager større fordel af egne codecs end af HTTP-komprimering. På velkonfigurerede værter kan tiden til første byte reduceres synligt, da CPU-tid og netværksventetid er bedre afbalanceret. Hvis man rydder op i sin pipeline, vinder man dobbelt: mindre båndbredde til Data og færre reflows takket være tidligere tilgængelige stilarter og scripts.
Hvilket indhold skal komprimeres – og hvilket ikke?
Jeg komprimerer målrettet tekstbaseret Typer: text/html, text/css, application/javascript, application/json, application/xml, image/svg+xml, application/manifest+json og lignende. For allerede komprimerede binære formater (billeder, videoer, PDF-filer i mange tilfælde, WOFF2) sparer jeg CPU'en: effekten er minimal, og latenstiden kan stige. Også vigtigt: en tærskelværdi-regel (f.eks. fra 1024–2048 byte), så små svar ikke forsinkes unødigt uden mærkbar gevinst. I CI kontrollerer jeg regelmæssigt indholdstype og størrelse for at opdage fejlkonfigurationer tidligt.
Brotli vs Gzip: Tal, der ændrer indlæsningstiderne
Komprimeret i test Brødpind HTML ca. 21 %, JavaScript ca. 14 % og CSS ca. 17 % stærkere end Gzip [1][4]. Andre målinger bekræfter en fordel på ca. 20 % i forhold til Deflate, den metode, der ligger bag Gzip [5][6]. Denne forskel gør siderne mærkbart hurtigere, især ved mange tekstaktiver og på mobile enheder med variabel båndbredde. Derudover kører dekomprimeringen i browseren i mange tilfælde hurtigere med Brotli; der blev målt op til 64 % hurtigere udpakningstider i frontend [1]. Alt i alt forkorter bedre Kompressionshastigheder og hurtig udpakning gør den kritiske sti til det synlige indhold tydelig.
Set ud fra et netværksperspektiv: Første RTT'er og CWV'er
Mange mærkbare gevinster opstår, fordi mindre svar passer bedre ind i de første TCP/QUIC-flyvninger passe. Hvis den oprindelige HTML takket være Brotli passer i en eller to pakker mindre, forkortes tiden til FCP/LCP og blokeringen for renderingskritiske ressourcer. Under HTTP/3 drager forbindelser desuden fordel af mindre Leder af linjen-blokering. I mobilnetværk med højere pakketab udjævner mindre overførsler JitterKurve – RUM-data viser derefter færre afvigelser opad. For mig er det en grund til konsekvent at reducere især den første HTML og kritisk CSS [3][5][8].
Hvornår jeg bruger Brotli – og hvornår jeg bruger Gzip
For statisk Til aktiver som HTML, CSS, JS, SVG og WOFF2 bruger jeg Brotli med høj niveau, forkomprimeret ved build eller direkte på CDN-Edge. Filerne havner i cachen og leveres tusindvis af gange uden CPU-omkostninger. Ved meget dynamiske svar – personaliserede HTML-visninger, API-JSON, søgning – bruger jeg som regel Gzip eller Brotli med moderat niveau, så serveren hurtigt kan streame svaret. TTFB-kurven er afgørende: Hvis den skyder i vejret, skruer jeg niveauet ned eller leverer ublokeret delindhold tidligere. Sådan holder jeg Svartider lav uden at miste fordelene ved kompakte filer.
Vælg de rigtige kvalitetsniveauer (niveau)
Jeg starter pragmatisk: Brotli niveau 4 til on-the-fly, niveau 9-11 kun til pre-komprimering; Gzip niveau 6 som et solidt udgangspunkt [4][5][6]. Hvis CPU-belastningen stiger ved spidsbelastning, reducerer jeg først Brotli-niveauet og kontrollerer, om caching-headeren og CDN-kanten fungerer korrekt. Ofte hjælper en lille justering af Cache mere end et højt kompressionsniveau. I målinger viste Brotli på niveau 4 ofte bedre filstørrelser med tilsvarende eller mindre latenstid end Gzip niveau 6 [4]. Hvis man måler iterationer nøjagtigt, ender man hurtigt med en opsætning, der Server skåner og alligevel sparer mærkbart på data.
Konfiguration: Nginx, Apache, Caddy – sikre standardindstillinger
Jeg satser på enkle, kontrollerbare standardindstillinger. For Nginx betyder det: brug statiske varianter, moderat on-the-fly, rigtige typer, fornuftige minimumsstørrelser, sæt Vary korrekt.
# Nginx (eksempel) 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 aktiverer jeg mod_brotli og mod_deflate med klart ansvar: først Brotli, derefter Deflate som reserve. Mindstestørrelser og typer forbliver ensartede.
# Apache (eksempel) 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"
Vigtige foranstaltninger: ingen komprimering af allerede komprimerede medier, test for dobbeltkomprimering og på proxyservere no-transform undgå, hvis caches ellers undertrykker varianter. Jeg tjekker med curl: -H „Accept-Encoding: br,gzip“ og -I, om Indholdskodning, Varierer og størrelser er plausible.
Forudkomprimering af statiske aktiver: Build, Edge, Cache
For bundle-tunge frontends komprimerer jeg på forhånd Aktiver i build og læg .br/.gz-varianter ved siden af originalerne, så Nginx eller et CDN leverer den rigtige version direkte. Store biblioteker, gentagne CSS-klasser og framework-kode drager over gennemsnittet fordel af dette, fordi Brotli bruger et større søgevindue og et indbygget ordbog [2][9]. Legitime langtidscacher (uforanderlige + versionering) reducerer desuden antallet af anmodninger og udpakningsarbejde. Hvis du vil levere globalt, kan du kombinere dette med en smart CDN-optimering, så Edge-noder tæt på brugeren leverer dataene. På den måde sikrer mindre filer og geografisk nærhed sammen lavere Forsinkelser.
Kontroller dynamiske svar og TTFB
Ved servergenererede HTML-Visninger tæller streaming og lav latenstid mere end de sidste procentpoint i filstørrelse. Jeg komprimerer on-the-fly med Gzip eller Brotli på et moderat niveau, kontrollerer TTFB og CPU pr. worker og øger kun niveauet, hvis der er tilstrækkelige reserver. En smart skabelonrækkefølge sender de første bytes tidligt af sted, så browseren kan begynde at rendere. Derudover stabiliserer Caching på serversiden svaretiden, fordi gentagne fragmenter ikke beregnes på ny hver gang. Denne opsætning holder Tips uden at forringe brugeroplevelsen.
Levering af streaming og delindhold korrekt
Især ved HTML-visninger satser jeg på Tidlige floder: kritisk inline-CSS, tidlig head-sektion, derefter hurtig streaming af body. Komprimering må ikke bremse dette. Derfor holder jeg øje med bufferstørrelser og flush-punkter og undgår komplicerede Brotli-niveauer ved on-the-fly. Gzip niveau 6 eller Brotli niveau 3-4 giver her en god balance. Afgørende: serveren skal ikke vente, indtil „alt er klar“, men sende i meningsfulde blokke – det forbedrer FCP og den oplevede reaktionsevne.
HTTP/2 og HTTP/3: Effektiv kombination af komprimering
Multiplexing under HTTP/2 og QUIC under HTTP/3 fungerer perfekt sammen med mindre filer, fordi flere objekter flyder parallelt og med mindre head-of-line-blocking. Især på mobilforbindelser giver reducerede RTT'er og mindre pakketab i HTTP/3 ekstra stabilitet. Jeg kontrollerer derfor altid, om værten understøtter begge protokoller med korrekt prioritering og server push-erstatning (Early Hints). Hvis man sammenligner opsætningen, finder man nyttige detaljer i den kompakte HTTP/3 vs HTTP/2 Oversigt. I kombination med Brotli til statiske filer og Gzip til live-HTML reduceres ventetiden og Jitter Bemærkelsesværdigt.
CDN-strategier: Cache-nøgler, Stale og Edge-Precompression
I CDN sørger jeg for, at .br og .gz Variationer caches separat, og Edge-noder leverer helst de allerede forkomprimerede artefakter. Jeg aktiverer stale-while-revalidate og stale-if-error, så peaks eller backend-udfald ikke bliver synlige. For API-ruter lader jeg ofte CDN komprimere live, men med konservative niveauer. Vigtigt: Headers som Cache-kontrol, ETag, Varierer og Indholdskodning skal give et harmonisk billede – ellers opstår der bizarre cache-miss-bølger, der forringer TTFB.
Mobilbrugere: Spar båndbredde, skån batteriet
På smartphonen betaler hver sparede byte direkte på indlæsningstid og energiforbrug. De 15–21 % mindre Brotli-filer reducerer overførselstiden og radioaktiviteten; når båndbredden er begrænset, mærkes lettelsen især [4][5]. Mindre payloads stabiliserer desuden FCP- og LCP-metrikkerne, fordi renderingskritiske ressourcer ankommer hurtigere. Jeg sørger også for, at Critical CSS er rent, og træffer en klar beslutning om, hvilke scripts der virkelig må være renderingsblokerende. I sidste ende falder afvisningsprocenten, og interaktioner starter tidligere, fordi browseren bruger mindre Belastning bærer.
Team-workflow, CI og budgetter
Jeg gør kompression til en Pipeline-emne: Build-trin genererer .br/.gz, CI måler størrelsen af artefakterne og sammenligner med budgetterne. En pull-anmodning, der forøger kritiske aktiver med 30 %, bliver straks bemærket. Derudover gemmer jeg smoke-tests (curl-checks på content-encoding, vary, størrelses sammenligning), så fejl ikke først bliver bemærket i produktionen. Jeg kører rollouts som Kanariefugl: Del trafikken på nye niveauer, overvåg RUM og servermetrikker, og rul derefter fuldt ud. Klare rollback-håndtag (feature-flags, Nginx-kort for kvalitetsniveauer) giver mig sikkerhed ved spidsbelastning.
Sammenligningstabel: Styrker på et øjeblik
Følgende oversigt hjælper mig i samtaler med Hold, at træffe hurtige beslutninger. Det erstatter ikke en test i din egen stack, men viser, hvor de største effekter ligger. Jeg vurderer altid kombinationen af filstørrelse, CPU-profil og brugerpåvirkning. Hvis du har et klart fokus på statiske tekstaktiver, vil du næsten altid være tilfreds med Brotli. Ved meget dynamiske applikationer er Gzip fortsat en pålidelig løsning. Allrounder.
| Kriterium | Brødpind | Gzip | Praktisk effekt |
|---|---|---|---|
| kompressionshastighed | ~15–21 % mindre ved HTML/CSS/JS [1][4][5] | God, men større end Brotli | Færre bytes, hurtigere Transmission |
| Dekomprimering i browseren | Ofte hurtigere; op til 64 % i tests [1] | Solid hastighed | Hurtigere start synlig Indhold |
| On-the-fly CPU-profil | Moderat niveau hurtigt; højt niveau dyrt | Mellemniveauer meget hurtigt | Vælg konservativt ved Live-HTML-niveau |
| Bedste anvendelsesformål | Statiske aktiver, forudkomprimering, edge-cache | Dynamiske svar, streams, API'er | Adskil opsætninger efter ressourcetype |
| Typiske trin | 4 (on-the-fly), 9–11 (pre) [4][5][6] | 6 som udgangspunkt | Balance mellem størrelse og TTFB |
| Kompatibilitet | Bredt understøttet, fallback mulig [3][5][6] | Tilgængelig næsten overalt | Ingen reelle hindringer i moderne stacks |
Overvågning og test: Sådan måler jeg fremskridt
Jeg installerer først klare Metrikker: TTFB, FCP, LCP, bytes/anmodning og CPU pr. medarbejder. Derefter sammenligner jeg varianter – Gzip vs. Brotli, niveaujusteringer, Edge-cache til/fra – i identiske tidsvinduer. Syntetiske tests viser reproducerbare forskelle, og Real-User-Monitoring bekræfter effekten hos rigtige brugere. Det er vigtigt at have en ren rollback, hvis der opstår CPU-spidsbelastninger eller cache-miss-bølger. Først når effekterne er stabile, ruller jeg opsætningen ud. Trafik-stærke ruter.
Fejlfinding: typiske fejl og hurtige kontroller
- Dobbelt kompression: Indholdskodning viser „br, br“ eller „gzip, gzip“. Årsagen er ofte filterkæder eller proxy + origin. Løsning: Lad kun ét sted være ansvarligt, foretræk statiske varianter.
- Forkert variant fra cachen: Brotli fungerer hos klienter uden br-understøttelse. Oftest mangler Vary: Accept-Encoding eller CDN-cache-nøglen indeholder ikke feltet. Løsning: Tving Vary og tilpas CDN-nøglen.
- Eksploderende TTFB Efter aktivering: On-the-fly-niveau for højt, CPU-mætning eller manglende Edge-cache. Løsning: Sænk niveauet, aktiver forkomprimering, kontroller cache-header.
- Ingen størrelsesgevinst: forkerte typer (allerede komprimerede medier), minimumslængde for lav eller aggressiv minificering mangler. Løsning: Kurater typer, øg minimumslængden, kontroller build-optimering.
- Beskadigede downloads: Content‑Length passer ikke til det komprimerede svar, eller upstream fjerner Content‑Encoding. Løsning: Brug Transfer‑Encoding: chunked ved komprimering, eller genberegn længden korrekt.
- Ujævne renderingsstier: HTML streamer for sent, selvom det er komprimeret. Løsning: Strukturér skabelonen, send tidlige bytes, kritisk CSS, vælg moderate niveauer.
Kort sammenfattet: Min standardstrategi
For alle cachebare tekstressourcer aktiverer jeg Brødpind og leverer forkomprimeret via Build eller CDN‑Edge. Højdynamisk indhold får Gzip eller Brotli på moderat niveau, så TTFB og interaktivitet forbliver stabile. HTTP/2 og HTTP/3 kører med korrekt indstillede cache-headers, Early Hints og prioriteret indlæsning af kritiske ressourcer. Jeg holder kvalitetsindstillingerne så lave som muligt, så længe filstørrelserne viser en klar fordel. Denne fremgangsmåde kombinerer lav Datamængde med lav serverbelastning – og gør siderne mærkbart hurtigere.
