Gzip vs Brotli: How Do These Compression Algorithms Compare?
Compare gzip and Brotli compression — size savings, speed tradeoffs, and how Accept-Encoding negotiation works.
Expected Interview Answer
Gzip and Brotli are both lossless HTTP content-encoding algorithms that shrink text-based responses (HTML, CSS, JS, JSON) before transfer, but Brotli generally achieves 15-25% smaller output than gzip at equivalent settings because it uses a larger, web-content-tuned static dictionary and a more advanced compression scheme, at the cost of slower compression time — which servers offset by pre-compressing static assets at build time.
Gzip, based on DEFLATE, has been the web’s compression workhorse for decades and is universally supported. Brotli, developed by Google, adds a built-in dictionary of common web strings (HTML tags, JS keywords, CSS properties) on top of a context-modeling compression scheme, letting it find redundancy gzip’s generic dictionary misses, especially in smaller files. Brotli’s higher compression levels are noticeably slower to compute than gzip’s, which matters for dynamically generated responses compressed on the fly, but static assets like bundled JS/CSS are typically pre-compressed once at build time, so the extra compression cost is paid once rather than per-request. A server negotiates which to use via the client’s Accept-Encoding header, falling back to gzip for the small share of clients without Brotli support, and CDNs commonly serve pre-computed Brotli and gzip variants of the same static file to avoid runtime compression entirely.
- Brotli typically produces 15-25% smaller output than gzip for text-based web assets
- Both are content-encoding negotiated automatically via Accept-Encoding, requiring no client code changes
- Pre-compressing static assets at build time avoids paying Brotli’s slower compression cost per request
- Universal gzip support provides a safe fallback for the rare client without Brotli
AI Mentor Explanation
Gzip is like a groundskeeper packing equipment using a generic packing method that works for any sport. Brotli is like a groundskeeper who has a cricket-specific packing template — pre-shaped slots for bats, stumps, and pads — so the same gear fits into a noticeably smaller kit bag. Building that specialized template takes longer upfront, but once built it is reused for every match without repeating the work. That generic-but-fast versus specialized-but-more-compact tradeoff is exactly gzip versus Brotli.
Step-by-Step Explanation
Step 1
Client advertises support
The browser sends Accept-Encoding: gzip, br (deflate) listing algorithms it can decode.
Step 2
Server selects an encoding
The server picks the best mutually supported algorithm, preferring Brotli when the client and server both support it.
Step 3
Asset is compressed
Static assets are typically pre-compressed at build time; dynamic responses are compressed on the fly.
Step 4
Response is labeled and sent
The server sets Content-Encoding: br (or gzip) so the client knows how to decompress the body.
What Interviewer Expects
- Understanding that Brotli generally compresses smaller than gzip for text assets
- Awareness of Brotli’s built-in web-tuned dictionary as the mechanism behind the gain
- Knowledge that Accept-Encoding/Content-Encoding negotiate which algorithm is used
- Mention of pre-compressing static assets at build time to avoid runtime cost
Common Mistakes
- Assuming Brotli is always better with no tradeoff — ignoring its slower compression time
- Compressing dynamic, highly variable responses at max Brotli level on every request, adding latency
- Forgetting to set Content-Encoding correctly, causing clients to fail decoding
- Not providing a gzip fallback for the small share of clients without Brotli support
Best Answer (HR Friendly)
“Gzip and Brotli both shrink files like HTML, CSS, and JavaScript before sending them over the network so pages load faster. Brotli usually compresses a bit smaller than gzip because it has a dictionary built specifically for web content, but it takes more time to compress, so sites usually pre-compress their files once ahead of time rather than compressing on every request.”
Code Example
const express = require('express')
const app = express()
app.get('/app.js', (req, res) => {
const acceptEncoding = req.headers['accept-encoding'] || ''
if (acceptEncoding.includes('br')) {
res.set('Content-Encoding', 'br')
res.sendFile(__dirname + '/dist/app.js.br')
} else if (acceptEncoding.includes('gzip')) {
res.set('Content-Encoding', 'gzip')
res.sendFile(__dirname + '/dist/app.js.gz')
} else {
res.sendFile(__dirname + '/dist/app.js')
}
})Follow-up Questions
- Why is it common to pre-compress static assets rather than compress them per request?
- How does the Vary: Accept-Encoding header interact with caching?
- When might gzip still be the better practical choice over Brotli?
- How do CDNs typically handle Brotli negotiation at the edge?
MCQ Practice
1. What primarily gives Brotli its size advantage over gzip on web text assets?
Brotli ships with a static dictionary of common web strings, letting it exploit redundancy gzip’s generic approach misses.
2. Why do sites typically pre-compress static assets with Brotli at build time?
Brotli at high quality levels is compute-intensive, so build-time compression avoids repeating that cost on every request.
3. How does a server know whether a client supports Brotli?
The client lists supported encodings in Accept-Encoding, letting the server choose the best mutually supported one.
Flash Cards
Typical size advantage of Brotli over gzip? — Roughly 15-25% smaller for text-based web assets.
What gives Brotli its edge? — A built-in dictionary tuned for common HTML/CSS/JS patterns.
Main Brotli tradeoff? — Slower compression time at high quality levels, usually offset by pre-compressing at build time.
Header that negotiates compression? — Accept-Encoding (request) and Content-Encoding (response).