Compresión y codificación de transferencia

Text assets like HTML, CSS, JS, JSON, and SVG are highly compressible. Compressing them before transfer can cut payloads by 70-90%, directly speeding up load on every network.

The browser advertises supported algorithms with the Accept-Encoding header; the server responds with the chosen one in Content-Encoding.

gzip is universally supported and a safe baseline. It offers good compression with low CPU cost and is enabled on virtually every server and CDN.

Brotli (br) typically compresses text 15-25% smaller than gzip. It is supported in all modern browsers over HTTPS, making it the preferred choice today.

Compress text-based MIME types only. Already-compressed binaries like JPEG, PNG, WebP, MP4, and woff2 fonts gain nothing and waste CPU if recompressed.

For static assets, precompress at build time at the highest level. The server then serves the .br or .gz file directly, avoiding per-request CPU.

For dynamic responses, use a lower compression level so CPU cost does not delay the response. High levels are best reserved for static, build-time compression.

In Node, the compression middleware adds gzip/Brotli to dynamic responses with sensible defaults.

Inspect a response in the Network panel: check Content-Encoding: br or gzip and compare transferred size to resource size. Lighthouse flags uncompressed text assets.

Modern compression for sensitive content is served over HTTPS, which also avoids historic attacks. Brotli in browsers is only offered on secure connections.

• Prefer Brotli, fall back to gzip.
• Compress text types only.
• Precompress static assets at max level.
• Use lower levels for dynamic responses.

You learned to shrink transfers with gzip and Brotli, negotiated via Accept-Encoding. Compress text types only, precompress static assets at max level, use lower levels for dynamic responses, and verify with the Network panel.