Sitecheck Din hjemmeside, fuldt dækket
All terms
Glossary · Compression

Compression (Brotli / Gzip)

Server-side encoding that shrinks text-based responses before transit, cutting bandwidth and improving page load.

Sitecheck Team

HTTP compression encodes text-based responses — HTML, CSS, JavaScript, JSON, SVG — into a smaller form before sending them to the browser, which decompresses on receipt. The two algorithms in mainstream use are Gzip (universal support, RFC 1952) and Brotli (RFC 7932), which typically achieves 15–25% better ratios than Gzip at comparable speeds for static text.

Why it matters

Smaller responses mean fewer bytes over the wire, faster TTFB, and earlier LCP — especially on mobile and high-latency links. Compression is one of the cheapest wins available: it's a config flag, not a code change, and it improves Core Web Vitals site-wide. CPU cost on modern servers is negligible because compressed static assets can be cached.

How to check

  • Enable Brotli with a Gzip fallback at your edge or origin; clients advertise support via Accept-Encoding.
  • Pre-compress static assets at build time (.br and .gz siblings) so the server never compresses on the hot path.
  • Skip already-compressed formats: JPEG, PNG, WebP, AVIF, MP4, and WOFF2 do not benefit and waste CPU.
  • Verify by inspecting response headers for Content-Encoding: br or Content-Encoding: gzip in DevTools.
  • Confirm your CDN honours the encoding for cached responses and varies the cache key on Accept-Encoding.
  • Combine with HTTP/2 or HTTP/3 multiplexing for the best end-to-end transfer profile.

See also