Performance
Brotli
Brotli is a compression algorithm that usually shrinks HTML, CSS, and JavaScript more than gzip does. Browsers announce support with `Accept-Encoding: br` and only accept it over HTTPS.
How it is measured
Read the `Content-Encoding` response header in DevTools or curl and compare transfer size to resource size. Check the same file at several compression levels, because the top levels cost real CPU at request time.
Static files can be compressed once at build time at the highest level. Dynamic HTML is usually better at a middle level such as 4 or 5, where size savings are good and time to first byte does not suffer.
Worked example
A Next.js marketing site ships a main JavaScript bundle of 412 KB raw. Gzip at level 9 brings it to 118 KB. Brotli at level 11, precompressed at deploy, brings it to 101 KB. On a slow connection that 17 KB gap is worth about 70 ms of download.
The same origin compresses HTML on the fly at Brotli level 11 and TTFB jumps from 190 ms to 340 ms. Dropping to level 5 puts TTFB back at 205 ms and keeps most of the saving.
How it differs
Brotli is a newer, denser compressor that is slower to produce at high levels. Gzip is the older default that every client and proxy understands and that compresses faster. Minification removes characters from the source before either compressor runs, so the two stack.
Common errors
Turning on level 11 for dynamic pages and paying for it in TTFB. Compressing images and video, which are already compressed. Forgetting that a CDN or proxy in front of the origin may strip or re-encode the header. Serving Brotli over plain HTTP, where browsers ignore it. Skipping the Vary: Accept-Encoding header and caching the wrong variant.
In practice
Check one HTML response and one JS file with `curl -I -H 'Accept-Encoding: br'`. If you see gzip or nothing, enable Brotli at the CDN or web server. Precompress static assets at build time and keep dynamic responses at a moderate level.