Brotli compression

Overview of the algorithm

Brotli combines LZ77-style back‑references, context modelling, and static Huffman coding with a built‑in dictionary to achieve higher density than legacy web compressors. Its static dictionary contains tens of thousands of common substrings across web content (HTML, CSS, JavaScript, JSON, XML), allowing short references to frequent patterns such as tags, attributes, and keywords instead of emitting them verbatim. This helps shrink repetitive markup like SVG path data and class names without altering the payload semantics.

The encoder exposes quality levels (0–11) that trade CPU time for ratio. Lower levels are faster and suitable for dynamic responses; high levels spend more time searching for longer matches and better Huffman trees, producing smaller files. Decompression remains fast and predictable across levels, which is why browsers can decode Brotli efficiently even on low‑power devices. The format is deterministic and stable, making it suitable for precompressing static assets during a build step and serving them directly.

What it excels at

Brotli’s advantages grow with highly redundant, text‑heavy content. Assets with repeated tokens and structured markup (e.g., SVG paths, CSS rules, JSON keys) compress very well. Binary formats already using strong internal compression, like JPEG, PNG, WebP, AVIF, and WOFF2, see little to no benefit and can even expand if recompressed at the HTTP layer. As a rule, apply Brotli to text media types and avoid double‑compressing binaries.

HTTP support and negotiation

Brotli is negotiated through Accept-Encoding on the request and signalled by Content-Encoding: br on the response. Browsers typically advertise br and gzip with optional q‑values indicating preference; servers select one encoding or none, compress the payload, and send the chosen encoding in the response headers. The Content-Length reflects the compressed size, and clients transparently decompress before processing. If br is not present in Accept-Encoding, servers should fall back to gzip or identity (no compression).

Caching intermediaries and CDNs store distinct variants per encoding, so Vary: Accept-Encoding (or use of the Content-Encoding key in cache metadata) is important to prevent serving a mismatched representation. Precompressed static files can be stored on disk or at the edge (e.g., file.svg.br) and mapped to requests when the client supports br. Strong or weak validators (ETag/Last-Modified) should be derived per variant; otherwise conditional requests can return incorrect 304 responses across encodings.

Compatibility and transport

All modern browsers support Brotli over HTTP/2 and HTTP/1.1; it is orthogonal to the HTTP version and TLS. Many servers (Apache, Nginx), runtimes (Node.js, Go), and CDNs (Cloudflare, Fastly, Akamai) support on‑the‑fly or precompressed delivery. Historical TLS compression vulnerabilities (e.g., CRIME/BREACH) do not apply to Brotli itself, but responses that reflect secrets and attacker‑controlled input should be handled with caution. Static assets and markup without secrets are safe to compress.

What improves

Brotli reduces transfer size, which lowers network time on constrained connections, reduces data costs, and shortens the critical path for render‑blocking resources. Compared to gzip, typical additional savings for text assets range from about 10–20% for HTML/CSS/JS to 15–30% for highly repetitive markup, with decompression costs that are negligible in modern browsers. Smaller responses often translate into earlier First Contentful Paint (FCP) and can improve Largest Contentful Paint (LCP) when the LCP element depends on text resources (HTML, CSS, inline SVG).

On the server side, dynamic Brotli at high quality levels increases CPU time and can delay first bytes if the encoder cannot stream quickly enough. Sensible defaults use moderate levels for dynamic pages and high levels for precompressed static assets. At the network level, smaller payloads reduce the number of TLS records and round trips, making slow mobile connections less painful. CDNs benefit from reduced egress, and origin bandwidth bills can drop when Brotli is consistently applied to cacheable text resources.

Trade‑offs and operational impact

The main trade‑off is CPU vs. bytes. Streaming compression with very high quality may increase TTFB; precompression avoids that penalty for static files. Memory footprints are modest for decoders but can rise for encoders at the highest settings. In practice, targeting the sweet spot for dynamic compression and relying on build‑time or CDN‑time precompression for static assets yield the best balance of speed and cost.

What benefits: Brotli and text-based image assets (SVG)

SVG (image/svg+xml) is XML markup, so it behaves like other text when compressed. Brotli commonly shrinks SVG a further ~10–25% compared with gzip at typical levels, and 70–85% versus the raw, uncompressed file depending on structure, path complexity, whitespace, and embedded metadata. That reduction directly cuts transfer time for inline and external SVGs, including icon systems and vector illustrations used in hero areas that can influence LCP. Because the decompressed representation is identical, image quality is unaffected.

Brotli should not be applied to already‑compressed raster formats (JPEG, PNG, WebP, AVIF) via HTTP content‑encoding. These formats include their own internal compression; wrapping them with br can yield no gain or even increase size, while adding CPU overhead. The same caution applies to fonts: WOFF2 already uses Brotli internally, so HTTP‑level br on WOFF2 files is unnecessary and often disabled. Focus Brotli on text types: HTML, CSS, JavaScript, JSON, XML, and SVG.

Practical notes for SVG delivery

Minification at source (removing whitespace and metadata) complements Brotli by increasing redundancy and lowering the baseline. For inline SVG, HTTP compression only applies to the enclosing HTML document, not the data URL encoded inside CSS or HTML attributes. Externalising large SVGs as separate files allows the server or CDN to negotiate br and cache the compressed representation, improving reuse across pages and users.

Relationship to rankings and Page Experience

Brotli is not a direct ranking factor, but it influences signals that correlate with better search performance. Smaller assets reduce network delay and can improve Core Web Vitals, particularly LCP and FCP when text resources are on the critical path. Faster experiences support engagement and conversion goals, and can reduce bounce rates—behaviours search engines may observe indirectly. The algorithm does not alter content, so relevance and indexing remain unchanged.

From a crawl perspective, Googlebot and other modern crawlers support br and benefit from smaller bytes. Reduced transfer sizes can improve effective crawl efficiency within the same bandwidth and time budgets, which helps large sites where crawl budget is a consideration. For reporting and compliance, Page Experience frameworks track compression under opportunities in auditing tools, and enabling Brotli is a common recommendation to close those gaps on text assets including SVG.

Implementation notes

Server and CDN configuration basics

Enable Brotli for text media types only (e.g., text/html, text/css, application/javascript, application/json, application/xml, image/svg+xml). Use gzip as a fallback for clients that do not advertise br. For dynamic content, choose moderate quality (commonly 4–6) to balance CPU and latency; for static assets, precompress at high quality (8–11) during build or at the edge and serve the precompressed file to avoid runtime costs. Ensure Vary: Accept-Encoding (or CDN equivalent) so caches store the correct variant.

On Nginx, this typically involves the brotli and brotli_static modules, with brotli_types listing compressible MIME types. On Apache, mod_brotli provides BrotliCompressionQuality and BrotliFilterNote directives. In Node.js, zlib exposes createBrotliCompress/Decompress, and popular middleware can negotiate br automatically. Most CDNs can auto‑compress eligible content at the edge and honour precompressed artefacts uploaded with .br and .gz extensions, selecting the best variant per request.

Do and don’t checklist

• Do precompress cacheable static assets and version them for long caching.
• Do compress SVG and other text assets; avoid double‑compressing binaries (JPEG, PNG, WebP, AVIF, WOFF2).
• Do set correct Content-Type so servers apply Brotli only to intended types.
• Don’t use very high quality levels for dynamic responses where TTFB is critical.
• Don’t forget Vary: Accept-Encoding and encoding‑specific ETags to keep caches correct.

Comparisons

Brotli vs gzip (deflate wrapper)

Brotli typically yields an extra 10–25% reduction over gzip for web text, with comparable or faster decode times in browsers. Gzip’s encoder is faster at low settings but plateaus in ratio; Brotli scales further at higher qualities, making it ideal for precompressed static assets. Gzip remains valuable as a universal fallback, since every browser supports it and many legacy clients only advertise gzip/deflate. In practice, serve br when offered, else gzip, else identity.

Brotli vs Zstandard (zstd)

Zstandard provides excellent speed‑to‑ratio trade‑offs and is popular for storage and service‑to‑service compression. However, browser support for HTTP Content-Encoding: zstd is limited and uneven compared to br/gzip. Many CDNs can use zstd on private links or for cache storage, but public delivery to browsers still relies predominantly on br or gzip. For web compatibility today, Brotli remains the primary high‑ratio choice for text assets at the edge.

When to choose each

• Static text assets (HTML/CSS/JS/JSON/XML/SVG): precompress with Brotli at high quality; keep a gzip variant for fallback.
• Dynamic pages/APIs: use Brotli at moderate quality or gzip if CPU is constrained; profile TTFB impacts.
• Binary images and WOFF2 fonts: avoid HTTP‑layer compression; rely on the format’s internal compression.

FAQs

Should I apply Brotli to images like JPEG, PNG, WebP, or AVIF?

No. Those formats already use strong internal compression and rarely benefit from HTTP‑layer compression. In some cases, wrapping them with br can increase size and adds CPU overhead on both ends. Restrict Brotli to text assets. The main image exception is SVG, which is XML text and compresses very well with br.

What Brotli quality level should I use in production?

For dynamic responses, a quality of 4–6 is a common sweet spot, balancing CPU with latency. For static assets, precompress at 8–11 during builds or at the CDN edge and serve the precompressed file so users get the best ratio without incurring runtime cost. Always profile with real payloads and watch TTFB and CPU utilisation under load.

How do I verify that Brotli is working for my site or CDN origin?

Check response headers in your browser’s DevTools or via curl. Look for Content-Encoding: br on text assets and confirm that Accept-Encoding includes br in the request. Compare transfer sizes with and without br to estimate savings. Ensure caches show separate variants per encoding (or that Vary: Accept-Encoding is set) to avoid variant confusion.

Does Brotli require HTTP/2 or HTTPS to work?

No. Brotli is an HTTP content‑encoding and is independent of HTTP version and transport security. It works over HTTP/1.1, HTTP/2, and HTTP/3. While many deployments prefer to compress over HTTPS for performance and security reasons in general, br is not limited to TLS connections.

Can Brotli affect caching or conditional requests?

Yes—encoded variants must be cached separately. Send Vary: Accept-Encoding so intermediaries and browsers store the correct representation. If you use ETag, generate it per variant or adopt weak validators to avoid cross‑encoding mismatches that could lead to incorrect 304 Not Modified responses or corrupted content delivery.