Brotli vs Gzip: Compression Benchmarks at the Edge

Introduction to Edge Asset Compression

In modern web architectures, load performance directly impacts user engagement and conversion rates. While developers expend substantial effort optimizing image sizes and refactoring Javascript modules, the final delivery pipeline remains one of the most cost-effective levers for accelerating web performance. Historically, the Deflate algorithm, packaged as gzip, has been the standard for compressing web assets.

However, Brotli, a compression algorithm introduced by Google in 2015, has rapidly emerged as a superior alternative. By investigating the algorithmic mechanics and benchmarking their execution profile at the network edge, engineers can design optimal delivery layers that minimize transit weight without degrading edge CPU availability.

To understand the advantages of Brotli over Gzip, one must examine their underlying compression structures. Gzip uses the Deflate algorithm, combining the LZ77 sliding window algorithm with Huffman coding. Deflate scans the input data stream for duplicate byte sequences, replacing occurrences with backward references to previous data within a 32KB sliding window.

Brotli builds upon this foundation but introduces three major improvements: a much larger sliding window (ranging from 1KB up to 16MB), second-order context modeling, and a pre-defined static dictionary. The static dictionary contains over 13,000 common words, phrases, and HTML/CSS/JS tokens. This dictionary allows Brotli to compress short strings and common web structures far more efficiently than Gzip, which must build its dictionary completely from scratch for every asset.

Evaluating Compression Levels and Edge CPU Constraints

A common pitfall when deploying Brotli is failing to understand the computational trade-offs of its compression levels. Gzip supports compression levels from 1 to 9, with level 6 typically representing the industry standard for balancing speed and compression ratio. Brotli, on the other hand, operates on a scale from 0 to 11.

While Brotli level 11 achieves maximum compression, it is highly compute-intensive, requiring multiple orders of magnitude more CPU cycles to compress a file than Gzip level 6. Conversely, Brotli's decompression speed is extremely fast and remains relatively consistent across all levels, making it ideal for client browsers that only need to unpack the data.

At the network edge, where requests are processed concurrently by serverless functions or reverse proxies, running high-level compression dynamically is dangerous. Dynamically compressing HTML responses on the fly using Brotli level 11 can cause severe CPU bottlenecks, spiking Time-to-First-Byte (TTFB) latencies and negating any performance benefits gained from smaller payloads.

Dynamic vs. Static Asset Strategies

Therefore, best practices dictate a tiered compression strategy. Static assets (such as bundled Javascript, CSS, and SVG files) should be pre-compressed during the build phase at Brotli level 11 and served directly from storage. Dynamic API payloads, which must be compressed in real-time, should utilize lower levels—typically Brotli level 4 or Gzip level 6—to maintain sub-millisecond processing overhead at the edge.

Dynamic Content Negotiation Middleware

// Example Edge Worker Content Negotiation Routing
async function handleRequest(request) {
  const response = await fetch(request);
  const acceptEncoding = request.headers.get("Accept-Encoding") || "";

  // Check if browser supports Brotli
  if (acceptEncoding.includes("br")) {
    return new Response(response.body, {
      status: response.status,
      headers: {
        ...response.headers,
        "Content-Encoding": "br",
        "Vary": "Accept-Encoding"
      }
    });
  }

  // Fallback to Gzip
  if (acceptEncoding.includes("gzip")) {
    return new Response(response.body, {
      status: response.status,
      headers: {
        ...response.headers,
        "Content-Encoding": "gzip",
        "Vary": "Accept-Encoding"
      }
    });
  }

  return response;
}

Benchmarking Transmission Efficiency and Web Vitals

Comprehensive industry benchmarks reveal that Brotli consistently outperforms Gzip across almost all web-relevant file types. On average, Brotli compresses JavaScript bundles to sizes 15% to 20% smaller than Gzip, and CSS assets show reductions of up to 25%. For HTML documents, Brotli can reduce the payload weight by 20% to 30%.

On high-latency mobile networks, these smaller file sizes directly translate into faster Page Speed indices and improved Web Vitals. Specifically, Largest Contentful Paint (LCP) is reduced because the main thread receives the critical render-blocking assets much sooner, accelerating the initial layout calculation.

Caching Policies and Accept-Encoding Negotiation

However, when configuring edge delivery networks, architects must carefully manage caching policies to ensure compression negotiation works correctly. Intermediate proxies and CDNs must be instructed to cache separate versions of compressed assets based on the client's capabilities. This is achieved by setting the Vary: Accept-Encoding header.

Failing to set this header can result in a Gzip-only browser receiving a cached Brotli asset, causing a decoding error and rendering the application broken. Additionally, modern CDNs can perform dynamic decompression, storing a single Brotli-compressed file in the cache and automatically converting it to Gzip or uncompressed formats for legacy clients, optimizing cache storage efficiency.

• Static Pre-compression: Always build and upload pre-compressed .br files at Brotli level 11 during your CI/CD pipeline.
• Dynamic Negotiations: Utilize edge worker scripts to inspect headers and route request payloads to the appropriate compressed asset.
• Optimized Dynamic Levels: Limit on-the-fly edge Brotli compression to level 4 to maintain high throughput and low TTFB.

Brotli Optimization at the Edge with Bramsley

Fine-tuning edge compression is critical to balancing delivery speed with execution overhead. Bramsley Digital Studio implements optimized asset routing layers that take the guesswork out of compression negotiation:

• Dynamic Level Mapping: Automating real-time negotiation between Gzip and lower Brotli levels for dynamic API routes.
• Build-Time Pre-Compression: Automatically compiling static bundles to Brotli Level 11 in CI/CD before deployment.
• Vary Header Orchestration: Standardizing cache rules across global edge locations to prevent browser decoding errors.

Let Bramsley accelerate your application's Time-to-First-Byte and drive down payload weight. Partner with us to modernize your edge delivery networks.