HTTP compression encoder tekstbaserede svar — HTML, CSS, JavaScript, JSON, SVG — til en mindre form, før de sendes til browseren, som dekomprimerer ved modtagelse. De to algoritmer i almindelig brug er Gzip (universel understøttelse, RFC 1952) og Brotli (RFC 7932), der typisk opnår 15-25 % bedre kompressionsrater end Gzip ved sammenlignelig hastighed for statisk tekst.
Hvorfor det er vigtigt
Mindre svar betyder færre bytes over netværket, hurtigere TTFB og tidligere LCP — især på mobile og højlatens-forbindelser. Compression er en af de billigste optimeringer: det er en konfigurationsændring, ikke en kodeændring, og det forbedrer Core Web Vitals på tværs af hele sitet. CPU-forbruget på moderne servere er ubetydeligt, fordi komprimerede statiske assets kan caches.
Sådan tjekker du det
- Aktivér Brotli med Gzip fallback på din edge eller origin; klienter annoncerer understøttelse via
Accept-Encoding. - Pre-komprimér statiske assets ved build-tid (
.br- og.gz-varianter), så serveren aldrig komprimerer on the fly. - Spring allerede komprimerede formater over: JPEG, PNG, WebP, AVIF, MP4 og WOFF2 har ingen gavn og spilder CPU.
- Verificér ved at inspicere response headers for
Content-Encoding: brellerContent-Encoding: gzipi DevTools. - Bekræft at dit CDN respekterer encoding for cachede svar og varierer cache key på
Accept-Encoding. - Kombinér med HTTP/2 eller HTTP/3 multiplexing for den bedste end-to-end transferprofil.