Gzip / Brotli Compression
Server-side compression algorithms that reduce the size of HTML, CSS, and JavaScript files before sending them to the browser. Brotli typically achieves 20-30% better compression than Gzip.
§ 1 Definition
Gzip and Brotli are lossless compression algorithms used in HTTP content encoding to reduce transfer sizes. Gzip (based on DEFLATE) has been the web standard for decades. Brotli, developed by Google, uses a more sophisticated algorithm (including a pre-defined dictionary of common web strings) and achieves 20-30% better compression ratios for text-based resources. Brotli is supported by all modern browsers and should be the first choice, with Gzip as fallback.
§ 2 How They Work
The browser sends an Accept-Encoding header listing supported algorithms (Accept-Encoding: br, gzip). The server compresses the response (if applicable) and sets Content-Encoding to the chosen algorithm. The browser decompresses before rendering. Brotli levels 1-4 are fast enough for dynamic compression; levels 5-11 are better for static pre-compressed assets.
§ 3 Common Misunderstandings
Brotli is NOT always faster to compress than Gzip. At high compression levels (8-11), Brotli is significantly slower to compress (5-10x), though decompression is comparable. This makes high-level Brotli unsuitable for on-the-fly compression of dynamic responses. Pre-compress static assets at build time with Brotli level 11 and serve pre-compressed files. Also, Brotli's gains diminish for already-compressed content like JPEG, WebP, and PNG: compressing images with Brotli rarely pays off.
§ 4 Implementation
For static assets: pre-compress at build time (brotli CLI, Sharp, or build plugins). For dynamic HTML: use Brotli level 1-4 on the server (nginx http_brotli module, or CDN-level Brotli). Always configure content negotiation: serve Brotli to browsers that accept it, Gzip to others. CDNs like Cloudflare, Fastly, and Akamai handle this automatically. Test with curl -H 'Accept-Encoding: br' to verify.
§ 5 Note
§ 6 In code
# nginx Brotli configuration
brotli on;
brotli_comp_level 4;
brotli_types text/html text/css application/javascript image/svg+xml;
# Pre-compress at build time (CLI)
brotli -Z -f styles.css # level 11
brotli -Z -f app.js # level 11
brotli -q 4 -f index.html # level 4 for dynamic§ 7 Common questions
- Q. Which is better for the web in 2026?
- A. Brotli by default, Gzip as fallback. Brotli is universally supported in modern browsers.
- Brotli compresses 20-30% better than Gzip.
- Use high-level Brotli for pre-compressed static assets.
- Use low-level Brotli (1-4) for dynamic content.
- Always configure content negotiation (br then gzip).
- Do not compress already-compressed formats (JPEG, WebP).
Atomic Glue configures Brotli compression at the server, CDN, and build levels to minimize transfer sizes while maintaining compatibility. Web Development services.
Get in touchServer-side compression algorithms that reduce the size of HTML, CSS, and JavaScript files before sending them to the browser. Brotli typically achieves 20-30% better compression than Gzip.
Category: Performance (also: Infrastructure)
Author: Atomic Glue Performance Team
## Definition
Gzip and Brotli are lossless compression algorithms used in HTTP content encoding to reduce transfer sizes. Gzip (based on DEFLATE) has been the web standard for decades. Brotli, developed by Google, uses a more sophisticated algorithm (including a pre-defined dictionary of common web strings) and achieves 20-30% better compression ratios for text-based resources. Brotli is supported by all modern browsers and should be the first choice, with Gzip as fallback.
## How They Work
The browser sends an Accept-Encoding header listing supported algorithms (Accept-Encoding: br, gzip). The server compresses the response (if applicable) and sets Content-Encoding to the chosen algorithm. The browser decompresses before rendering. Brotli levels 1-4 are fast enough for dynamic compression; levels 5-11 are better for static pre-compressed assets.
## Common Misunderstandings
Brotli is NOT always faster to compress than Gzip. At high compression levels (8-11), Brotli is significantly slower to compress (5-10x), though decompression is comparable. This makes high-level Brotli unsuitable for on-the-fly compression of dynamic responses. Pre-compress static assets at build time with Brotli level 11 and serve pre-compressed files. Also, Brotli's gains diminish for already-compressed content like JPEG, WebP, and PNG: compressing images with Brotli rarely pays off.
## Implementation
For static assets: pre-compress at build time (brotli CLI, Sharp, or build plugins). For dynamic HTML: use Brotli level 1-4 on the server (nginx http_brotli module, or CDN-level Brotli). Always configure content negotiation: serve Brotli to browsers that accept it, Gzip to others. CDNs like Cloudflare, Fastly, and Akamai handle this automatically. Test with curl -H 'Accept-Encoding: br' to verify.
## Note
Image formats (JPEG, WebP, AVIF, PNG) are already compressed. Applying Brotli/Gzip on top yields minimal gains and wastes CPU. Only compress text-based resources.
## In code
# nginx Brotli configuration brotli on; brotli_comp_level 4; brotli_types text/html text/css application/javascript image/svg+xml; # Pre-compress at build time (CLI) brotli -Z -f styles.css # level 11 brotli -Z -f app.js # level 11 brotli -q 4 -f index.html # level 4 for dynamic
## Common questions
Q: Which is better for the web in 2026?
A: Brotli by default, Gzip as fallback. Brotli is universally supported in modern browsers.
## Key takeaways
- Brotli compresses 20-30% better than Gzip.
- Use high-level Brotli for pre-compressed static assets.
- Use low-level Brotli (1-4) for dynamic content.
- Always configure content negotiation (br then gzip).
- Do not compress already-compressed formats (JPEG, WebP).
## Related entries
- [Content Delivery Network (CDN)](atomicglue.co/glossary/content-delivery-network-cdn)
- [Edge Caching](atomicglue.co/glossary/edge-caching)
Last updated July 2026. Permalink: atomicglue.co/glossary/gzip-brotli-compression