Brotli is an open-source compression algorithm developed by Google for delivering web content. It typically compresses text resources such as HTML, CSS and JavaScript more effectively than the older gzip. All common modern browsers support Brotli over encrypted connections (HTTPS).
Brotli squeezes your website's files together before sending them, like vacuum packaging: the content stays the same, but the parcel is smaller and reaches the recipient faster. The browser then unpacks the data automatically – visitors notice nothing except shorter load times.
Why do I need Brotli compression?
Before a browser can display a page, HTML, CSS and JavaScript have to be transferred. Compression shrinks these text-based files considerably before they are sent. Brotli was released by Google in 2015 as a free algorithm; at its launch, Google cited compression ratios around 20 to 26 percent better than its gzip-compatible predecessor Zopfli (Google). In practice, Brotli-compressed text files are therefore usually noticeably smaller than their gzip counterparts.
Smaller files mean less transfer time – especially on mobile networks. This has a direct effect on metrics such as Largest Contentful Paint (LCP) and thus supports good Core Web Vitals. Modern shop frontends in particular ship extensive JavaScript and CSS bundles; SVG graphics, web font companion files and JSON responses from APIs also count among the compressible content. Since compression, once configured, works permanently without any further effort, it is one of the measures with a particularly good effort-to-benefit ratio.
Practical relevance for shop and website owners
Brotli works entirely in the background: browser and server negotiate the method via the Accept-Encoding header. If a client does not support Brotli, the server automatically falls back to gzip – so the risk of display problems is low. Static pre-compression is particularly efficient: files are compressed once at the highest level and then delivered ready-made instead of being re-packed on every request. Our article on Brotli asset compression for shop performance shows how this can be implemented in a shop project.
Common mistakes
- Compressing only HTML: CSS, JavaScript, SVG and JSON also benefit considerably – images and videos do not, as they are already compressed.
- Maximum level for dynamic content: Brotli level 11 is very CPU-intensive for on-the-fly compression; dynamic responses are better packed at a medium level.
- Overlooking the HTTPS requirement: Browsers effectively only accept Brotli over encrypted connections.
- Never verifying the configuration: The Content-Encoding response header reveals whether Brotli is actually active – some setups silently keep delivering gzip only.
What to look for
First check whether your host or your CDN supports Brotli and whether static assets are delivered pre-compressed. With professional managed hosting, correctly configured compression is usually part of the standard setup. It makes sense to generate the pre-compressed files during the build or deploy process so that the web server only has to deliver them. You can verify the measurable effect with Lighthouse or the browser developer tools – in our page speed optimisation service, compression is one of the basic measures, complemented by a suitable server configuration from hosting & maintenance.
Open the developer tools (network tab) and check the response header of a CSS or JS file: if it says "content-encoding: br", Brotli is active; if it says "gzip", there is usually still room for optimisation.