Performance

Brotli Compression

A text compression algorithm that beats gzip. Announced as Content-Encoding: br.

Brotli is a compression algorithm that shrinks text files — HTML, CSS, JavaScript — before they are sent to the browser, typically 15 to 20 percent smaller than gzip. Every modern browser supports it, so enabling it on the server or CDN reduces transfer size and load time with no change to the code itself.

Definition

Brotli is a compression algorithm developed by Google and supported by every current browser. For text — HTML, CSS, JavaScript, JSON, SVG — it typically produces files noticeably smaller than gzip at equivalent settings, because it ships with a dictionary of common web strings.

Servers negotiate it through Accept-Encoding and announce it with Content-Encoding: br. Static assets can be pre-compressed at build time at the highest setting, since the cost is paid once; dynamic responses use a lower level to keep compression time small.

Why It Matters

Compression is the rare optimisation with no design cost: the page is identical, the bytes are fewer. On a JavaScript-heavy page the saving over gzip is meaningful on slow connections, which is where the users who bounce actually are.

It is also frequently half-configured — enabled for HTML but not for JavaScript, or enabled at the CDN but not the origin — which is invisible unless you check the response headers per asset type.

Example

Verify per resource rather than per site: curl -sI -H "Accept-Encoding: br" https://example.com/app.js | grep -i content-encoding. Expect br. If it says gzip or nothing, that asset is not being served compressed the way you think it is.

Where to enable it, and the quality setting nobody tunes

Brotli is a server or CDN setting, not a code change. Most CDNs enable it by default; origin servers frequently do not, which is why a site can be compressed at the edge and uncompressed for anything that bypasses the cache.

The setting worth knowing is the quality level, 0 to 11. Level 11 gives the smallest files and is slow enough that it is only appropriate for static assets compressed once at build time. For content generated per request, level 4 or 5 gives most of the benefit at a fraction of the CPU — and a server configured at 11 for dynamic responses can spend more time compressing than it saves in transfer.

Static assets should be pre-compressed at build and served from disk. Then you get level 11 with no runtime cost at all.

How SlapMyWeb checks this

The audit records the Content-Encoding of every text resource and reports files served uncompressed, along with the saving available. The matching fix guides are unminified CSS and unminified JavaScript — compression and minification compound, and doing only one leaves most of the saving on the table.

Related Tools

HTTP Header Checker Website Speed Test

Know the term.
Check your own site.

A free audit tells you whether this is currently costing you score points — and exactly what to change.

Run a free audit

Free foreverNo signupResults in 30s