Learn & Understand

How Compression Works, Why Media Resists It, and Why Brotli Beats Gzip on the Web

The companion calculator estimates how much smaller a text asset gets with gzip. Behind that estimate is a genuinely interesting principle: compression works by finding and encoding repetition, which explains both why text-based web assets shrink so dramatically and why images and videos barely compress at all. Understanding the mechanism, why some data resists compression, and why a newer algorithm often beats gzip for web content, turns a savings estimate into real insight about one of the most impactful and free performance optimizations available.

Compression Finds Repetition

At its core, lossless compression exploits redundancy: it identifies repeated patterns in data and replaces them with shorter references, so a sequence that appears many times is stored once and pointed to thereafter. The more repetitive and predictable the data, the more there is to compress, and the smaller the result. This is why the notion of information content, or entropy, matters: data with low entropy (lots of structure and repetition) compresses well, while data with high entropy (near-random, little repetition) compresses poorly. Compression is essentially a hunt for structure to encode more efficiently, and how much it finds determines the savings.

Why Text Compresses and Media Doesn't

This principle cleanly divides web assets into those worth compressing and those not.

Text-based code and data are full of repeated syntax, common words, whitespace, and predictable structure, so they typically shrink dramatically. Media formats, by contrast, are already compressed by their own specialized schemes, so their bytes look nearly random to a general compressor, there is no leftover redundancy to exploit. Trying to gzip a JPEG or MP4 wastes CPU for essentially no size reduction, and can even add overhead. This is why servers are configured to compress text assets and skip already-compressed media, applying compression exactly where redundancy exists.

Why Brotli Beats Gzip on the Web

Gzip is the long-standing default, but a newer algorithm, Brotli, often outperforms it for web content. Brotli achieves better compression ratios on typical web text, meaning smaller files for the same content, and it ships with a built-in dictionary of common web patterns that gives it a head start on HTML, CSS, and JavaScript. For static assets that are compressed once and served many times, Brotli's higher compression is nearly pure benefit. Most modern browsers support it, so serving Brotli where available, with gzip as a fallback, squeezes out extra savings on exactly the assets that dominate page weight for code. The choice of algorithm, not just whether to compress, affects the result.

The CPU-vs-Size Trade-off

Compression is not entirely free: it costs CPU time to compress and decompress, and higher compression levels cost more CPU for diminishing size gains. This creates a trade-off, especially for dynamically generated responses compressed on every request, where too aggressive a setting can burden the server. The common resolution is to pre-compress static assets at build time using a high compression level, since that cost is paid once, while using a lighter, faster level for dynamic content compressed on the fly. Understanding that compression trades CPU for bytes helps tune where and how hard to apply it, matching effort to how often an asset is served.

Compressing the Right Things Well

Use the calculator to estimate compression savings, and apply the principle behind them: compression finds and encodes repetition, so compress text-based assets aggressively where redundancy is abundant, skip already-compressed media that has none, prefer Brotli over gzip for web content where supported, and pre-compress static assets to sidestep the CPU cost. The calculation estimates the savings; understanding how compression works is what tells you where it pays and where it does not.