Performance
Gzip
Gzip is the older, still widely used way to shrink text responses on the wire. Nearly every browser, proxy, and server supports it.
How it is measured
Look for `Content-Encoding: gzip` in the response and compare the transferred size to the resource size in the Network panel. Text formats such as HTML, CSS, JS, JSON, and SVG compress well, often by 70 percent or more.
Compression levels run from 1 to 9. Higher levels cost more CPU for diminishing returns, and level 6 is a common default.
Worked example
A JSON API returns an 86 KB product list. With gzip at level 6 it is 14 KB, and the response completes in 180 ms instead of 410 ms on a 3G profile. With no compression configured, the server was sending all 86 KB.
Moving to Brotli would save only about 2 KB more here, so the team leaves gzip on.
How it differs
Gzip is the broadly compatible compressor. Brotli compresses a few percent smaller at high levels and is slower to produce. Minification shrinks the source by removing whitespace and names before compression. Gzip is the safe fallback when Brotli is not available.
Common errors
Compressing JPEG, PNG, and video that are already compressed. Forgetting to enable it on JSON APIs. Not sending `Vary: Accept-Encoding`. Compressing very small files where headers outweigh the gain. Letting a proxy decompress and not recompress.
In practice
Test your HTML, CSS, JS, and JSON responses with curl and look for a content-encoding header. Turn gzip on where it is missing, and layer Brotli on top where the CDN supports it.