Vad är HTTP-komprimering?

En webbserver kan komprimera en sida, ett skript eller en stilmall innan den skickas, och webbläsaren packar upp den när den kommer fram. Webbläsaren anger vilka format den förstår i sin Accept-Encoding-begärandeheader, och servern anger vilket format den använde i Content-Encoding. Text komprimeras effektivt, så en komprimerad sida är ofta en fjärdedel så stor eller mindre, vilket gör att den läses in snabbare och sparar bandbredd.

Kodning Header-värde Kommentarer
gzip gzip Stöds överallt; grundläggande stöd som alla servrar bör ha
Brotli br Vanligtvis 15–25 % mindre än gzip för text; endast HTTPS
Zstandard (zstd) zstd Nyare; snabb komprimering, stöds av Chrome och Firefox

Verktygsbeskrivning

Ange en URL och tryck på Kontrollera komprimering. Vår server hämtar den en gång okomprimerad och en gång för varje kodning och jämför sedan storlekarna:

  • Stöds anger om servern svarade med den kodningen
  • Storlek visar hur många byte som skickades komprimerade, och Sparat visar hur mycket mindre det är jämfört med den okomprimerade storleken
  • Vary: Accept-Encoding anger om servern talar om för cache och CDN:er att svaret beror på kodningen, så att de inte skickar en komprimerad kopia till en klient som inte kan läsa den

Omdirigeringar följs (upp till 5), och Kontrollerad URL visar vart de ledde. Varje hämtning läses in upp till 5 MB.

AI-assistenter som är anslutna till MCP-servern Rapid Tool Set kan köra samma kontroll med http_compression_checker.

Tips

  • Kontrollera de filer som är viktigast för hastigheten: själva sidan, dess huvudsakliga JavaScript-paket och dess CSS.
  • Bilder, videor och teckensnitt som WOFF2 är redan komprimerade; servrar skickar dem därför med rätta utan HTTP-komprimering.
  • Om Brotli saknas räcker det ofta med en enda inställning: brotli on; med modulen ngx_brotli i nginx, eller mod_brotli i Apache. CDN:er som Cloudflare aktiverar det åt dig.