Compression (Gzip / Brotli)
Squeezing text files smaller for the trip over the network, so a 300KB bundle travels as 80KB and unpacks in the browser.
See it
What it is
Text compresses beautifully, so servers ship it squeezed and browsers expand it on arrival. The browser advertises what it understands in 'Accept-Encoding', the server picks one and answers with 'Content-Encoding'. Gzip is the universal floor. Brotli ('br') is the modern default and lands roughly 15 to 20 percent smaller than gzip on JS and CSS. Zstd is starting to appear on CDNs. A 300KB JavaScript bundle commonly crosses the wire as about 80KB.
Compress text: HTML, CSS, JS, JSON, SVG, plain text. Do not compress what is already compressed (JPEG, PNG, WebP, AVIF, MP4, woff2), because you burn CPU to save nothing and occasionally make the file bigger. If you can precompress at build time, do it at Brotli quality 11 and serve the '.br' file statically; if you compress per request, use a mid-level setting so encoding time does not eat your TTFB.
The gotcha: compression flatters your numbers without touching the expensive part. Those 80KB still expand into 300KB of JavaScript the device must parse, compile, and run, and on a mid-range Android that cost dwarfs the download. Minify first, delete code second, compress third. Also check it is actually on: a proxy or misconfigured origin quietly serving uncompressed responses is a very common find.
Ask AI for it
Turn on and verify transfer compression for this site. Enable Brotli with gzip as the fallback for all text content types (HTML, CSS, JS, JSON, SVG, XML) and exclude already-compressed binaries (images, video, woff2). Precompress static build output at Brotli quality 11 and serve the .br files directly; use a moderate quality level for dynamically generated responses so TTFB stays low. Then verify it by showing me the Content-Encoding response header plus the transferred versus decoded size for the main bundle.