Brotli versus Gzip: HTTP Compression Choices that Cut Bytes and Carbon

Brotli versus Gzip in one sentence

Choosing Brotli usually reduces transferred bytes more than Gzip for text based assets. That reduction lowers network energy and server egress for each request, but Brotli can increase CPU cost when applied at high compression levels at request time. The right choice balances compression ratio, CPU and caching to achieve net carbon and cost savings.

Why compression matters for carbon

Every byte sent from a server to a client consumes network and device energy. Compressing text assets reduces payload size which reduces the time radios or wired networks are active and reduces data center bandwidth. For pages that serve many visits this per visit reduction compounds into measurable savings for energy and egress costs. Measuring bytes saved is the most direct and verifiable proxy to estimate carbon reduction because energy use of network transfer scales with traffic volume and distance.

What compression changes and what it does not

Compression reduces the number of bytes on the wire. It does not change the content semantics, and it has no effect on already compressed binary assets such as JPEG, PNG, MP4 or WOFF2. Compression affects three measurable factors. First bytes transferred. Second server CPU used to compress responses. Third client CPU and network time used to decompress and render. A deployment that reduces bytes but uses excessive server CPU may not deliver the intended efficiency benefits if servers must scale up. Measure all three to find a net win.

How Brotli and Gzip compare

Both Brotli and Gzip are widely used HTTP content encodings. Brotli is a newer algorithm designed to achieve higher compression ratios on text assets. Gzip is older, faster on the fly in many server environments and remains well supported throughout the ecosystem. In practice Brotli often yields smaller compressed sizes for HTML, CSS and JavaScript which directly decreases network transfer. Real world results vary by content and by the compression settings chosen.

Common trade offs

Brotli tends to compress better for text which reduces bytes and therefore network energy and egress charges. Higher Brotli quality levels increase CPU work when applied while serving requests. For static files precompressing with Brotli at a high quality level is common because the cost of compression is a one time build cost. For dynamic responses many operators use a lower quality Brotli configuration to limit CPU.

Gzip is reliable and fast for on the fly compression. For some server stacks it has predictable CPU cost and works well for dynamic content. Because many caches and proxies have long standing support for gzip it remains a safe fallback when compatibility or server CPU is a concern.

Practical deployment patterns

Use the following patterns as decision gates rather than strict rules. Each site will vary depending on traffic, asset mix and server capacity.

Precompress static assets

Precompress HTML, CSS and JavaScript files during the build or publish step and upload both compressed and uncompressed versions to the origin or CDN. Serving precompressed files removes runtime CPU cost for compression and lets you use an aggressive Brotli setting to maximize size reduction while keeping server load low. Ensure the server or CDN serves the appropriate Content Encoding based on the Accept Encoding header and sets the Vary header to Accept Encoding so caches do not serve the wrong version.

Use Brotli for text assets when supported

When the client advertises support enable Brotli for HTML CSS and JavaScript. If your CDN or edge supports Brotli enable it there so compression happens at the network edge and not on origin servers. For dynamic content consider a lower quality Brotli configuration or rely on precompression when possible.

Keep a gzip fallback

Some legacy intermediaries or client environments may not handle Brotli. Maintain gzip versions to preserve compatibility. Many CDNs will negotiate Brotli first then gzip so clients that do not support Brotli still receive compressed content.

Do not compress already compressed files

Do not attempt to compress images audio video or precompressed font formats. Trying to compress them adds CPU overhead while delivering little or no size reduction. Use content type checks or file extension rules to skip compression for these asset types.

Cache key and cache control considerations

When you store multiple encodings in cache ensure the cache key includes the selected encoding. The Vary header with Accept Encoding must be present so caches segregate different encodings. For CDNs that handle encoding on the edge validate that the CDN optimizes cache storage to avoid duplicating on a per request basis when possible.

Measurement steps to prove carbon impact

Directly measuring energy or carbon per page is complex. A practical approach is to measure bytes and then translate the reduction into energy using a documented conversion if needed. Use observed bytes as the primary metric and verify server CPU change as a secondary metric.

Suggested measurement workflow

Collect baseline metrics for a representative sample of requests. Capture uncompressed and compressed sizes for HTML CSS and JavaScript and record server CPU usage under typical load.
Enable Brotli for the sample set and repeat the capture. If you precompress static assets deploy those changes and measure again.
Compare the percent reduction in transferred bytes and monitor any change in server CPU and latency metrics.
If desired translate bytes saved into energy or carbon using a transparent conversion methodology. Prefer conversions from reputable sources and document assumptions.

Measuring bytes saved per asset and per page visit is reproducible and directly attributable to the compression change. Only after that validate whether server resource changes require capacity adjustments which could offset the gains.

When Brotli may not be the best choice

There are situations where Brotli is not the right tool. If your traffic consists mostly of binary media files compression yields negligible benefit. If your origin cannot absorb the extra CPU from high quality Brotli and you do not have an edge that can offload compression then Gzip or precompression may be a better choice. For very small files under a few hundred bytes the overhead of compression can increase size slightly or provide no meaningful benefit. Test rather than assume.

Operational checklist before rolling Brotli broadly

Confirm that the client mix supports Brotli enough to matter for your audience.
Decide whether to precompress static assets at build time or enable edge Brotli at the CDN.
Ensure the server and caches respect the Accept Encoding header and set Vary: Accept Encoding.
Exclude binary media from compression rules.
Monitor compressed response sizes server CPU and CDN cache hit ratio after rollout.

Examples that illustrate the trade offs

Example one. A documentation site with mostly HTML and CSS can benefit substantially from Brotli precompression because the assets are text heavy and static. Precompressing at publish time yields maximum bytes saved while avoiding runtime CPU cost.

Example two. A high traffic API that returns JSON may choose on the fly Gzip at a conservative compression level because latency of compressing every response matters. If an edge layer can perform Brotli with low latency it may still be worth enabling Brotli for the API responses because JSON compresses well.

How to present results to stakeholders

Report measurable metrics that stakeholders can verify. Show bytes transferred per page before and after the change. Report measured server CPU and latency to demonstrate any trade offs. If translating bytes into carbon or cost include the conversion factors, the scope of traffic used and whether the numbers are estimates or measured. Avoid presenting unreferenced carbon numbers without the conversion methodology.