![\"File](\"/images/journal-inline-brotli-vs-gzip.webp\")
\n Every millisecond counts for page load speed. When I'm optimizing a static site, one of the first questions always pops up: what's the deal with brotli vs gzip for static sites? It's a common fork in the road for web performance, and the answer has evolved.
\n\nFor years, Gzip was the undisputed king of web compression. It did its job well, reducing file sizes and speeding up delivery. But like any technology, newer, more efficient options have emerged to challenge its dominance.
\n\nMy goal is always to deliver content as fast as possible to the end-user without overcomplicating the server setup. This means looking at the real-world impact of compression algorithms, not just theoretical benchmarks or marketing claims. I need something reliable that ships.
\n\n# nginx — precompressed assets at build time\nlocation ~* \\.(js|css|svg)$ {\n gzip_static on;\n brotli_static on;\n}\n
Gzip, based on the DEFLATE algorithm, has been the workhorse of web compression since the HTTP/1.1 era. It’s universally supported by browsers and web servers, making it a safe default for reducing the bandwidth needed to serve assets. Most CDNs enable it by default, which simplifies a lot of initial setups.
\n\nIt works by finding repeated patterns in data and replacing them with shorter references. This is highly effective for text-based content like HTML, CSS, and JavaScript, which often contain many repetitive strings. The compression process is relatively fast, so it doesn't add significant latency during runtime.
\n\nWhile effective, Gzip’s compression ratio, especially at its highest levels, can be modest compared to newer algorithms. The algorithms have matured, and there isn't much more room for improvement within its established architecture. It's solid, but not groundbreaking anymore.
\n\nBrotli, developed by Google, entered the scene with a clear mandate: achieve better compression ratios than Gzip, particularly for web content. It uses a combination of LZ77, Huffman coding, and a 120KB static dictionary common to web resources, like common keywords in HTML and JavaScript. This dictionary is a key differentiator.
\n\nThe result is often 15-20% smaller files for comparable quality settings compared to Gzip, sometimes even more for certain file types. This means less data travels over the network, leading to faster downloads for users. For critical CSS or JavaScript bundles, these savings add up quickly.
\n\nBrotli also offers different compression levels, similar to Gzip. Higher levels achieve greater compression but take longer to process. For static sites, where compression happens once at build time or on demand for cached assets, this increased processing time is usually a non-issue. The client-side decompression is fast.
\n\nI've run countless tests on briancrabtree.me and client sites comparing the two. The gains with Brotli are consistent and measurable, especially on larger JavaScript bundles and CSS files. A 200KB JavaScript file Gzipped might be 60KB, but Brotli can often shrink it down to 50KB or even less. That's a significant win for initial page loads.
\n\nThe benefit is most pronounced on textual content. Images and videos are typically already compressed using their own specialized algorithms like JPEG, PNG, or WebP, so applying Brotli or Gzip to them offers minimal to no additional benefit. In fact, it can sometimes make them larger if applied incorrectly.
\n\nFor users on slower connections or mobile networks, these smaller file sizes translate directly to a snappier experience. It’s not just about raw speed; it’s about reducing the overall data burden. That's a practical advantage for every visitor to your static site, particularly important for global audiences.
\n\nWhen it comes to my Nginx setup for static sites, I configure Brotli first. Most modern browsers support Brotli, so serving it as the primary option makes sense. I instruct Nginx to check if the browser accepts \"br\" encoding via the Accept-Encoding header before falling back to \"gzip\".
\n\nThe configuration is straightforward but requires the ngx_brotli module. Once compiled or installed, I use brotli on; and set brotli_comp_level to a higher value like 6 or 8 for pre-compressed static assets. For dynamic content, a lower level might be necessary to avoid CPU spikes, but for static, we can afford the time.
\n\nIt's important to ensure your build process pre-compresses your static assets with Brotli. Relying on Nginx to compress on-the-fly for every request can be CPU-intensive and negate some performance benefits. I usually generate both .br and .gz versions of my assets at build time, then let Nginx serve the appropriate one. This ensures we don't accidentally serve redundant content or break accessibility landmarks like I discussed in Semantic HTML Landmarks Search Engines Actually Read for HTML structure.
\n\nWhile Brotli offers superior compression, it generally comes at the cost of higher CPU usage during the compression phase. For static sites, this impact is typically mitigated by pre-compressing assets at build time. The server then just serves the already compressed file, with minimal CPU overhead for the request itself.
\n\nIf you're compressing on-the-fly, particularly on a server with limited resources or high traffic, Gzip might still be the more pragmatic choice. The balance between compression ratio and CPU cycles is a real engineering decision. Always profile your server's performance under load before making a blanket change.
\n\nAnother consideration is client support. While Brotli is widely supported by modern browsers, legacy browsers might still rely solely on Gzip. This is why a robust server configuration includes a fallback mechanism, ensuring all users receive a compressed version of your assets, even if it's the older standard.
\n\nFor every new static site project, or when I'm optimizing an existing one, my first move is to implement Brotli compression. I pre-compress all textual assets – HTML, CSS, JavaScript, SVGs – at the highest practical compression level during the build step. These pre-compressed .br files live alongside their uncompressed and Gzipped counterparts.
\n\nMy Nginx configuration prioritizes serving the Brotli-compressed version if the browser supports it. If not, it falls back to the Gzip version, ensuring broad compatibility and optimal performance for the vast majority of users. This layered approach guarantees we're leveraging the best available compression without leaving anyone behind.
\n\nThe gains in page load speed and reduced bandwidth are real and worth the minor setup effort. It's a low-hanging fruit for performance optimization that directly impacts user experience and crawl efficiency. If you're looking for other ways to boost your site's speed, don't forget to check out my notes on WebP and AVIF: How I Ship Images Without Regret for modern image delivery.
","tags":["brotli","gzip","compression"],"views":77}