Domains, CDN & Web Delivery

Gzip Compression

Definition

Gzip is a container around the DEFLATE algorithm, which finds repeated runs of bytes and replaces later copies with a short back-reference. Markup is full of repetition, so the wins are large: a 300 KB JavaScript bundle commonly lands near 90 KB, and HTML often does better still. The negotiation happens per response through two headers — the browser advertises what it can decode, the server declares what it actually sent. Compression levels run from 1 to 9, and most servers sit around 6 because level 9 costs noticeably more CPU for a percent or two of size. Brotli compression is the newer alternative and usually squeezes text a little further, but gzip remains the fallback that everything understands. Crucially, gzip only helps formats that are not already compressed. A JPEG, a PNG, an MP4 or a ZIP has had its redundancy squeezed out already, and running gzip over one burns CPU to produce a file that is the same size or very slightly larger.

Why It Matters

Bytes on the wire are the part of page load you have the most direct control over. On a mobile connection at 1.5 Mbps, 300 KB of uncompressed JavaScript takes roughly 1.6 seconds to arrive; the same file at 90 KB takes about half a second. That difference lands squarely on render-blocking resources, so it moves the point at which anything appears on screen. Compression also stacks with minification rather than replacing it — stripping whitespace and shortening variable names gives the compressor less to work with but still ends up smaller overall. Getting it wrong is usually invisible in a fast office, and painfully visible on a phone in a car park.

How It Works

The browser sends an Accept-Encoding request header, normally something like gzip, deflate, br. The server picks an encoding it supports from that list, compresses the body, and returns it with Content-Encoding: gzip. Content-Length then describes the compressed size, which is why a network panel shows a transferred size much smaller than the resource size. Because the same URL can return different bytes depending on that request header, the response should also carry Vary: Accept-Encoding so caches store one copy per encoding instead of serving a compressed body to a client that cannot read it. Well-run hosts precompress static assets at deploy time and keep the .gz file beside the original, so no CPU is spent per request; a CDN edge does the same thing on the way out.

Real-World Example

Someone publishes a documentation site on 99helpers at handbook-2026.99helpers.site. The build produces 210 KB of HTML, 64 KB of CSS and 180 KB of JavaScript — 454 KB before anything is done to it. Served with gzip, the same three files transfer as roughly 42 KB, 12 KB and 54 KB, about 108 KB in total. The 1.2 MB hero photograph in the same deploy is untouched, because a JPEG has nothing left to give.

Common Mistakes

  • Turning on compression for every content type — gzipping JPEGs, PNGs and ZIPs adds CPU and often a few bytes, with no benefit at all
  • Omitting Vary: Accept-Encoding, so a shared cache can hand a gzipped body to a client that asked for plain text
  • Setting the compression level to 9 on dynamically generated responses, where the extra CPU delays the first byte more than the saved bytes help
  • Assuming compression removes the need to minify — the two are complementary, and skipping one leaves easy savings on the table

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →