All terms
Glossary · Compression

Compression (Brotli / Gzip)

Server-side encoding, der komprimerer tekstbaserede svar før afsendelse, reducerer båndbredde og forbedrer sideindlæsning.

Sitecheck Team

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: br eller Content-Encoding: gzip i 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.

Se også