Web hosting
Website compression setup: gzip, Brotli and what should actually be compressed
HTTP compression reduces transfer size for compressible responses such as HTML, CSS, JavaScript, JSON, XML, and text. It should be negotiated with Accept-Encoding, applied to appropriate types and sizes, and measured against CPU cost and limited to response types that actually benefit from compression.
Inspect current Content-Encoding
Request representative assets with and without gzip/br support and compare Content-Encoding, Vary: Accept-Encoding, Content-Type, original bytes, and transferred bytes. A CDN may compress even when the origin does not.
Do not infer compression from a control-panel checkbox; test the public response.
Compress the formats that benefit
Text, code, SVG, JSON, and many API responses usually shrink well. JPEG, PNG, WebP, AVIF, MP4, ZIP and other compressed formats often gain little and waste CPU if recompressed.
Set minimum size thresholds so tiny responses do not pay unnecessary overhead.
Keep caching variants correct
Shared caches must distinguish compressed and uncompressed variants where content negotiation happens. Vary: Accept-Encoding and CDN configuration should preserve the right representation for each client.
Check ETag behavior if the server emits different bytes for encodings.
Measure performance after enabling
Compare transferred bytes, CPU use, response latency, and cache hit behavior. Brotli at extreme quality can cost more origin CPU than it saves for dynamically compressed responses; precompression can be a better fit for static assets.
- Verify public Content-Encoding.
- Target compressible MIME types.
- Preserve cache variants.
- Measure bytes and CPU together.