Brotli vs Gzip Website

Use Brotli for modern HTTPS traffic when your CDN or server can negotiate Accept-Encoding: br; keep Gzip enabled as the fallback. That rule gives most sites smaller HTML, CSS, JavaScript, JSON, and SVG responses without breaking older clients.

Brotli vs Gzip is not a branding choice. It is a delivery decision: which compression format should your edge or origin serve for text assets so pages transfer fewer bytes, start rendering sooner, and waste less bandwidth.

This guide covers web response compression for public websites and web apps. It applies to text-based assets served over HTTPS: HTML, CSS, JavaScript, JSON, XML, and SVG. It does not apply to images, videos, PDFs, ZIP files, already-compressed font files, or private downloads where CPU cost matters more than transfer size.

The business outcome is measurable: fewer transferred bytes, lower time to first byte and download duration on repeat templates, better Core Web Vitals on slow connections, and lower CDN or origin bandwidth spend. Treat compression as useful only when those numbers move in production tests.

Choose Brotli first when the visitor's browser supports it, the request is HTTPS, the asset is text, and you can precompress static files or absorb modest CPU cost at the edge. Choose Gzip when you need universal legacy support, your host lacks Brotli, or real-time compression CPU is the bottleneck.

What Is Brotli Compression?

Brotli is a lossless data compression algorithm developed by Google that improves web content compression. It uses LZ77 references, Huffman coding, and context modeling to achieve better compression ratios than traditional methods.

Brotli compression analyzes text patterns and uses a pre-defined dictionary of common web words and phrases. This static dictionary, combined with dynamic context modeling, allows Brotli to identify and compress repetitive elements more effectively than its predecessors. The algorithm adapts to different content types, making it effective for compressing HTML, CSS, JavaScript, and other text-based web assets.

Google developed Brotli for offline web font compression in 2015, it expanded its capabilities and released it as an open-source project. The algorithm was designed for HTTP content, making it ideal for modern web applications relying on text-based resources and enabling more efficient page prefetching strategies.

Benefits of Brotli Compression

Brotli usually wins on text because it combines LZ77 references, Huffman coding, context modeling, and a static dictionary of common web terms. Gzip uses DEFLATE, so it remains fast and compatible but usually produces larger text responses.

The practical benefit is not "better SEO" by itself. The benefit is fewer bytes on the wire. Smaller HTML, CSS, JavaScript, JSON, and SVG files can reduce download time, improve slow-network page loads, cut bandwidth cost, and remove one bottleneck behind LCP.

Brotli vs Gzip Decision Matrix

Implementation Process

1. Inventory compressible assets. Use browser DevTools, WebPageTest, or curl -H "Accept-Encoding: br,gzip" to list HTML, CSS, JavaScript, JSON, XML, and SVG responses larger than about 1 KB.
2. Confirm where compression happens. Decide whether the CDN, reverse proxy, application server, or build pipeline owns compression. Avoid double-compressing the same response.
3. Enable Brotli with Gzip fallback. Serve Brotli when the request includes Accept-Encoding: br; serve Gzip when it includes gzip; serve identity only when neither is available.
4. Set content types and exclusions. Compress text MIME types. Exclude images, video, archives, and already-compressed files.
5. Pick compression levels by asset type. Precompress static assets at higher Brotli quality. Keep dynamic Brotli moderate so CPU does not slow the origin.
6. Verify headers and variants. Check Content-Encoding, Vary: Accept-Encoding, cache keys, and CDN behavior for both Brotli and Gzip responses.
7. Measure before and after. Compare transferred bytes, TTFB, download duration, LCP, bandwidth cost, and server CPU on representative pages.

How to Enable Brotli Compression

Most teams should enable Brotli at the CDN or edge first. That keeps compression CPU away from the application server and makes rollback simple. If you manage the origin yourself, configure Apache, Nginx, IIS, or your reverse proxy directly.

Apache Configuration

Enable mod_brotli, compress text types, exclude binary formats, and use a moderate level for dynamic responses:

LoadModule brotli_module modules/mod_brotli.so
AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css text/javascript application/javascript application/json application/xml image/svg+xml
BrotliCompressionLevel 6
SetEnvIfNoCase Request_URI "\.(?:gif|jpe?g|png|webp|avif|mp4|zip|gz|br|pdf)$" no-brotli dont-vary

Nginx Configuration

Nginx usually needs the ngx_brotli module or a distribution that packages it:

brotli on;
brotli_comp_level 6;
brotli_min_length 1024;
brotli_static on;
brotli_types text/plain text/css text/xml text/javascript application/json application/javascript application/xml+rss application/atom+xml image/svg+xml;

CDN and Hosting Provider Support

Cloudflare, Fastly, KeyCDN, AWS CloudFront, Google Cloud CDN, Azure CDN, and many managed hosts can serve Brotli from the edge. Check the provider's setting, then verify the live response with DevTools or curl. The response should show Content-Encoding: br for Brotli-capable requests and Vary: Accept-Encoding for cache safety.

Browser and Server Support

Brotli is supported by current Chrome, Firefox, Safari, and Edge versions over HTTPS. Gzip remains the fallback for legacy clients and any request that does not advertise Brotli. On the server side, Apache uses mod_brotli, Nginx uses ngx_brotli or a packaged equivalent, IIS supports Brotli in modern Windows Server stacks, and most major CDNs can handle negotiation.

Where Brotli Fits

Brotli is strongest for:

• Content sites: HTML templates, articles, CSS, JavaScript, JSON feeds, and SVG assets.
• E-commerce sites: Product descriptions, category pages, reviews, filters, and front-end bundles.
• Single-page apps: Large JavaScript bundles and JSON payloads.
• Progressive web apps: Cached static assets where precompression can happen during the build.

Risks and Failure Modes

Brotli helps only when it is negotiated, cached, and measured correctly. The common failures are operational, not theoretical:

• No Gzip fallback: Some legacy clients, bots, and intermediaries do not send br. If Gzip is disabled, they may receive larger identity responses or fail on misconfigured stacks.
• Missing Vary: Accept-Encoding: Shared caches can serve a Brotli response to a client that only understands Gzip. Always vary compressed responses by accepted encoding.
• Wrong cache key at the CDN: If the CDN ignores encoding variants, one compressed version can poison another. Test through the CDN, not only against localhost.
• Compressing already-compressed files: JPEG, PNG, WebP, AVIF, MP4, ZIP, and most PDFs waste CPU with little or no size reduction.
• High dynamic compression levels: Brotli quality 9-11 can be useful for precompressed static assets, but it can slow dynamic HTML if performed on every request.
• Tiny response overhead: Headers and CPU can outweigh savings on very small responses. Start compression around 1 KB unless your platform has a different proven threshold.
• Security-sensitive reflected data: Compression can expose side channels when secrets and attacker-controlled text share the same response. Avoid compressing pages that mix CSRF tokens, session secrets, or personalized sensitive data with reflected input.

Performance Metrics, Tools, and Sources

Measure compression as a delivery change, not a checkbox. Track:

• Transferred bytes: Compare uncompressed, Gzip, and Brotli variants for representative HTML, CSS, JavaScript, JSON, and SVG files.
• Download duration and TTFB: Confirm smaller files are not offset by higher origin CPU time.
• Core Web Vitals: Watch LCP on slow 4G or mid-tier mobile profiles because compression mainly helps network-bound sessions.
• Bandwidth cost: Multiply byte savings by monthly requests at the CDN or origin.
• CPU and cache hit rate: Compression should not push origin CPU high enough to increase latency.

Useful tools include Chrome DevTools Network, WebPageTest, PageSpeed Insights, GTmetrix, CDN analytics, server CPU dashboards, and curl -I -H "Accept-Encoding: br,gzip" https://example.com/page.

Primary references worth checking before rollout: MDN on the Accept-Encoding header, MDN on Content-Encoding, Google's Brotli repository, Apache mod_brotli, and the Nginx Brotli module.

Alternatives

• Gzip only: Keep Gzip if the site is on a host without Brotli, has strict CPU limits, or serves a meaningful share of legacy clients.
• CDN-managed compression: Prefer this when the CDN can handle Brotli negotiation, cache variants, and rollback faster than the origin team.
• Static precompression: Generate .br and .gz files during the build for CSS, JavaScript, SVG, and other versioned assets.
• No compression: Use this for already-compressed media, archives, tiny responses, and pages where compression side-channel risk is unacceptable.

FAQ

Q: Does my hosting provider support Brotli, and how do I enable it?

A: Check the host or CDN compression settings first. If Brotli is available, enable it there, keep Gzip on, and verify live headers with DevTools or curl.

Q: What should I do if Brotli is not working?

A: Confirm the client sends Accept-Encoding: br, the response is HTTPS, the MIME type is compressible, the CDN cache key varies by encoding, and the response shows Content-Encoding: br.

Q: Can Brotli work with older browsers or servers?

A: Older clients can keep using Gzip. The server should negotiate per request instead of forcing Brotli globally.

Conclusion

Use Brotli as the default for modern HTTPS text assets and keep Gzip as the fallback. Do not compress binary media or tiny responses. Measure transferred bytes, latency, Core Web Vitals, bandwidth cost, cache behavior, and origin CPU before calling the rollout successful.