Kort fortalt: Gzip er et tabstabfrit komprimeringsformat til teksttyper. Webserveren eller CDN kan vælge gzip når klienten sender Accept-Encoding: gzip, så payload bliver mindre end rå UTF-8 over ledningen.
Gzip vs Brotli
I praksis:
- Brotli vinder ofte 10–25 % ekstra på tekst sammenlignet med gzip ved samme kvalitet.
- Gzip er hurtigere at komprimere on-the-fly på svage servere og understøttes næsten overalt.
Mange sites leverer Brotli til browsere der kan det og gzip til ældre - I konfigurerer en prioriteret liste, ikke et enten/eller.
Hvad bør komprimeres?
text/html,text/css,text/javascript,application/javascript,application/json,image/svg+xml
Ikke: JPEG, PNG, WebP, AVIF - de er allerede komprimerede bitmaps.
Typiske fejl i opsætning
- Komprimering slået fra bag reverse proxy mens origin stadig komprimerer → dobbeltarbejde, forvirrende debugging eller chunked-problemer.
- Micro-assets hvor header-overhead overstiger gevinst - sjældent et problem for HTML, mere for meget små filer.
- Glemte Content-Encoding-headers eller forkerte typer → browseren gætter forkert.
Sikkerhed og CPU
Gzip er modent og stabilt. Ved meget høj trafik uden hardware-akseleration kan CPU blive et tema - der hjælper edge caching, færre dynamiske HTML-svar og generelt mindre tunge responses.
Forhold til TTFB
Komprimering tilføjer lidt servertid modsat færre bytes over nettet. Profilér jeres konkrete stack - på de fleste sites er bytebesparelsen det der tæller mest for tekst.
Relaterede begreber
- Brotli
- HTTP/2, HTTP/3
- TTFB
- minification - adskilt lag: mindre kildekode før komprimering
FAQ
Skal jeg slå gzip fra når jeg har Brotli?
Som udgangspunkt nej - behold gzip som fallback for klienter uden Brotli. Serveren vælger det bedste understøttede encoding via Accept-Encoding.
Gør gzip min side langsommere?
Komprimering bruger CPU og sparer bytes. På moderne servere og CDNs er netværket ofte flaskehalsen for teksttyper, så gzip eller Brotli er typisk en netto-gevinst.
Skal billeder gzip’es?
Nej. JPEG, PNG, WebP og AVIF er allerede komprimerede formater. Tilføj ikke dobbelt komprimering af binære billedfiler - det giver sjældent gevinst og kan ødelægge effektivitet.
Hvad med SVG?
SVG er tekstbaseret XML og komprimerer ofte godt med gzip/Brotli - sørg for korrekt Content-Type og cache-headers som for andre assets.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
Forbedr TTFB med caching, edge cache og hurtigere serverrespons
Lær hvordan du reducerer TTFB med page cache, edge cache, korrekt cache strategi og bedre serverrespons på HTML.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
En feltguide til at spotte når browseren forsøger at bruge Range request, men ender med at få hele filer retur (200 i stedet for 206). Lær at se det i DevTools og ret fejl i proxy/CDN/origin.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
Vary-header og caching: undgå forkert indhold og lav cache-hit-rate
Vary bestemmer hvornår caches skal gemme flere varianter af samme URL (fx gzip vs brotli eller dansk vs engelsk). Lær de typiske fejl, og hvordan du tester med headers og curl.
