How to use Brotli and Gzip to optimize streaming and downloads

If you want your website, APIs, downloads, and streaming to be lightning fast even on slow mobile connections, one of the most powerful (and most underrated) tricks is HTTP compression. When used correctly, the combination of Brotli and Gzip drastically reduces the size of responses without losing a single bit of information. This translates to less bandwidth usage, less overloaded servers, and users who feel like "this loads instantly."

In the following lines, we'll delve into how Gzip and Brotli work, their differences, how to choose appropriate compression levels, how to enable them in Apache, Nginx, LiteSpeed, Cloudflare, WordPress, and REST APIs , and how to verify that everything is configured correctly. The goal is for you to end up with a comprehensive guide to maximizing the potential of both technologies for traditional websites, streaming services, and download platforms.

What are Gzip and Brotli and why do they matter so much?

Gzip is the veteran of the family: a compression format based on the DEFLATE algorithm , which in turn combines LZ77 and Huffman coding. It has been speeding up the web since the early 90s and today has virtually universal support across all types of browsers, servers, and HTTP clients.

Brotli , created by Google, also relies on similar ideas (LZ77 + Huffman), but introduces key improvements, such as the use of highly optimized static and dynamic dictionaries for web content (HTML, CSS, JS, JSON, etc.). As a result, it typically achieves compression ratios 20% to 30% better than Gzip for many text files.

In practice, both algorithms are used so that the server takes text resources (HTML, CSS, JavaScript, JSON from APIs, XML, fonts, etc.), compresses them, and sends them to the browser or client. The browser or client, transparently to the user, decompresses the response and processes it normally. The user only sees that everything loads faster and consumes less data.

One important detail: while Gzip can be used with both HTTP and HTTPS, Brotli compression on the web is de facto used over HTTPS . The good news is that nowadays virtually any project of any serious nature already runs over SSL/TLS, so it's not usually an issue.

Brotli vs Gzip: real performance differences

When comparing Brotli to Gzip, the first thing usually looked at is the compression rate . Public tests show that, for HTML, CSS, JS, or JSON, Brotli can reduce the file size by several kilobytes compared to Gzip under the same conditions. For example, for uncompressed HTML of about 418 kB, results like these have been measured:

• Gzip level 9: final file of about 78,7 kB.
• Brotli level 11: final file of about 57,2 kB.

The difference seems spectacular, but there's a catch: Brotli's maximum compression levels (10-11) involve more CPU and longer compression time , which doesn't always pay off, especially for dynamic content generated on the fly.

If we balance things out better, for example by comparing Gzip level 9 with Brotli level 3 , the same 418 kB HTML can be reduced to:

• Gzip level 9: 78,7 kB.
• Brotli level 3: 76,5 kB.

In that situation, the size is practically the same, but Brotli at level 3 compresses and decompresses much faster and with less resource consumption than Gzip at level 9. Hence, it is recommended to use medium levels of Brotli (between 3 and 6) for dynamic content and reserve the higher levels for pre-compression of static content (CSS, JS, fonts, etc.).

Independent benchmarks usually show a similar pattern: Brotli almost always wins in compression ratio , while Gzip is somewhat faster in some scenarios, especially when using low levels and when it comes to compressing many small resources in real time.

For APIs, text streaming, or large JSON downloads, the key is measurement: sometimes reducing the response size by an additional 15-20% is well worth the extra CPU cost, especially if you have a well-sized infrastructure or if you use CDN with edge compression.

How the client and server negotiate: Accept-Encoding and Content-Encoding

HTTP compression, whether on websites, REST APIs, or data streaming services, is based on a negotiation via headers. The client announces which algorithms it understands in the header. Accept-Encoding (for example gzip, br) and the server responds by indicating what it has applied in the header Content Encoding.

A typical API flow would look something like this: the client sends `Accept-Encoding: gzip, br` , the server detects that it can use Brotli and returns `Content-Encoding: br` . If the client only understands Gzip, it uses `Content-Encoding: gzip` . If there's no common algorithm, the server might respond with a 406 Not Acceptable error , although it's more common to simply send the uncompressed response.

When multiple algorithms are chained together (a rarer case, but permitted by the specification), the Content-Encoding header lists the methods in order, so the client can decompress in reverse order. Additionally, for intermediate caches such as proxies or CDNs, it is essential to send Vary: Accept-Encoding so they store both compressed and uncompressed versions of the same resource.

On devices with limited resources (older mobile phones, IoT devices, etc.), keep in mind that decompression also consumes CPU and memory. This isn't a problem in most modern browsers, but if you're developing a custom client, it's advisable to set minimum size thresholds (there's no point in compressing a 200-byte JSON response) and carefully choose which algorithms you'll support.

Brotli's internal architecture: dictionaries and sliding window

One of the reasons Brotli achieves smaller files than Gzip is its intensive use of data dictionaries . It employs two types: a static dictionary and a dynamic dictionary (sliding window), which work together to find recurring patterns and encode them very efficiently.

The static dictionary includes over 13,000 common words and snippets found in HTML, CSS, JavaScript, and general text, across multiple languages. Thanks to this dictionary, Brotli doesn't need to parse the entire stream byte by byte; instead, it can rely on familiar references, much like a template system referencing a reusable block of code.

Within that dictionary there are also partial phrases and transformations: pieces that with a prefix or suffix can form new words. This saves space not only in complete words, but also in typical combinations such as HTML tags (<html>, type="text/javascript", etc.).

The dynamic dictionary (the so-called "sliding window") analyzes recent data from the stream, storing it in a kind of cache that the algorithm can reuse. In Brotli, this window can reach up to 16 MB , much larger than the typical ~32 KB of Gzip, which provides a great deal of flexibility for finding patterns in large files or extensive data streams.

This combination allows Brotli to shine especially in large static resources (CSS, concatenated JS, modern bundles, bulky JSON for SPAs, etc.) and in HTML content with many repetitions of structure.

Brotli and Gzip compatibility with browsers, servers, and CDNs

From the client side, the situation is very favorable: according to compilations like Can I Use , over 95% of browsers in use already support Brotli, including virtually all Chromium-based browsers, Firefox, and the main mobile browsers. Gzip, meanwhile, has been universally supported for many years.

On the server side, the landscape is somewhat more varied. Gzip is available out of the box in almost any stack (Apache, Nginx, IIS, etc.), while Brotli sometimes requires specific modules or builds.

• ApacheYou need at least Apache 2.4 with mod_brotli installed and enabled.
• Nginx: It is usually activated from recent versions (1.18+), often through the module ngx_brotli, whether compiled into the binary or as a dynamic module.
• LiteSpeed ​​Web Server: brings Brotli enabled by default For years, without the need for manual changes.
• CDN such as Cloudflare, KeyCDN, CDN77, Amazon CloudFront, etc., offer support for Brotli natively or through very simple configuration options.

Many shared hosting providers still use Apache without mod_brotli or Nginx without the corresponding module, so before you start fiddling with configurations, it's a good idea to confirm with your provider what's available and what isn't. In some cases, enabling Brotli will be as simple as checking a box in the control panel or the CDN console.

Enable Gzip on web servers (Apache and Nginx)

Gzip remains essential, not only for compatibility with older browsers and clients, but also as a fallback when Brotli is unavailable across the entire chain (origin server, CDN, proxies, etc.). Enabling it is usually very straightforward.

En ApacheThe usual practice is to use the module mod_deflate and declare the MIME types you want to compress. A typical example in .htaccess would:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
  AddOutputFilterByType DEFLATE text/javascript application/javascript
  AddOutputFilterByType DEFLATE application/json application/xml
  AddOutputFilterByType DEFLATE image/svg+xml image/x-icon
  AddOutputFilterByType DEFLATE font/ttf font/otf font/woff font/woff2
</IfModule>

En NginxIt is activated with a few directives within the block http of the nginx.conf:

gzip on;
gzip_comp_level 2;
gzip_min_length 1100;
gzip_types text/plain text/html text/css text/xml
           application/json application/javascript text/javascript
           application/xml application/xml+rss image/svg+xml;
gzip_vary on;

From that point on, any browser that sends `Accept-Encoding: gzip` will receive the compressed content, and the rest will be received in plain text. It's important not to force compression on already compressed files (JPEG, PNG, MP4, ZIP, PDF, etc.), because the gain is usually minimal and you incur an unnecessary CPU cost.

Enable Brotli in Apache, Nginx, and LiteSpeed

To use Brotli on your server, your software needs to support mod_brotli or equivalent modules . Once confirmed, simply enable it and select the file types you want to compress.

En Apache 2.4+ with mod_brotli Installed, a very typical block would be:

<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css
  AddOutputFilterByType BROTLI_COMPRESS text/javascript application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json application/xml
  AddOutputFilterByType BROTLI_COMPRESS application/x-font-ttf
  AddOutputFilterByType BROTLI_COMPRESS application/vnd.ms-fontobject
  AddOutputFilterByType BROTLI_COMPRESS image/x-icon
</IfModule>

En Nginx with ngx_brotliSomething like this is usually enough in nginx.conf:

brotli on;
brotli_comp_level 4;  # niveles 3-6 son buena opción general
brotli_static on;      # sirve .br precomprimidos si existen
brotli_types text/plain text/css application/json application/javascript
             text/xml application/xml application/xml+rss text/javascript
             image/svg+xml;

In environments where resources are precompressed (for example, during a CI/CD pipeline that generates .br y .gz), brotli_static on It tells Nginx to serve those files directly, instead of compressing them each time on the fly, saving a lot of CPU.

The good news with LiteSpeed ​​Web Server is that Brotli is enabled by default in typical cPanel installations and many managed hosting plans. In this case, you practically don't need to do anything: the server will automatically decide when to use Brotli or Gzip based on the client's usage.

Using Brotli and Gzip in CDNs and content delivery networks

If you're using a modern CDN , you likely already have access to Brotli compression without much hassle. Cloudflare, for example, was one of the first to support it and now uses it across its entire infrastructure, with a highly optimized implementation.

For years, Cloudflare only requested Gzip from the origin, decompressed, and recompressed using Brotli level 4 or Gzip level 8 before returning it to the user. Now, with end-to-end Brotli support , Cloudflare can directly request Brotli content from the origin (up to level 11 if configured) and cache it as is, without recompression. This means lower latency and less bandwidth consumption between the origin and the edge.

If your source code supports Brotli, you can configure something like this with Nginx, for example:

brotli on;
brotli_comp_level 11;
brotli_static on;
brotli_types text/plain text/css application/javascript application/x-javascript
             text/xml application/xml application/xml+rss text/javascript
             image/x-icon image/vnd.microsoft.icon image/bmp image/svg+xml;

With this configuration, the matching assets will be delivered highly compressed to Cloudflare, which can then serve them directly to compatible users. For browsers that don't support Brotli, the CDN will handle decompression and forwarding in Gzip or uncompressed as appropriate.

Other CDNs like KeyCDN, CDN77, and Amazon CloudFront also offer Brotli. In some cases, simply selecting an option in the panel is enough; in others, you have to adjust settings like Accept-Encoding or disable the CDN's automatic compression to avoid interfering with the source compression.

How to integrate Brotli and Gzip into WordPress and other CMS

In WordPress, enabling compression doesn't depend on the CMS itself , but rather on the web server (Apache, Nginx, LiteSpeed, etc.) or the CDN you're using. Plugins can only help modify server settings when the server allows it.

Many caching plugins like W3 Total Cache, WP Rocket or LiteSpeed ​​Cache They offer options to enable Gzip and sometimes Brotli. In Apache, what they actually do is write or modify the rules of .htaccess to activate mod_deflate o mod_brotliIf the module is not installed on the server, the plugin will not be able to work its magic.

In Nginx, since there is no .htaccessThese plugins cannot directly affect compression. You will need to edit the configuration files (or ask your provider to do it) to add the directives gzip y brotli corresponding, and then reload Nginx.

Some managed hosting providers (for example, some based on integrated Cloudflare) automatically activate Brotli for all sites without requiring plugins. In these cases, adding another compression plugin is usually redundant and even counterproductive, as it can cause double compression or conflicts with the reverse proxy.

Brotli and Gzip compression in REST APIs, streaming, and downloads

Beyond traditional websites, Brotli and Gzip are essential for REST APIs, data streaming services, and file downloads . In these environments, reducing payload size directly impacts latency, bandwidth costs, and user experience.

In an API, it's common practice to compress text formats like application/json, application/xml, text/html , and similar, while leaving optimized formats (images, video, ZIP files, etc.) uncompressed. The server checks the client's Accept-Encoding header and decides whether to send the response in Brotli, Gzip, or without compression.

In text streaming services (e.g., SSE or WebSockets with JSON messages, real-time logs, etc.), compression must be handled more carefully. Compressing very small blocks one by one can cause the overhead to outweigh the benefit. Size thresholds are generally configured to determine when compression should be applied.

For HTTP downloads of large files, the approach is different. If the file is already a ZIP, a .tar.gz, or a video , adding Gzip/Brotli on top offers almost no benefit. However, if you're delivering large packages of JSON, XML, or CSV, compressing with Brotli or Gzip can result in enormous size reductions and significantly shorter transfer times for users.

What to compress and what not to compress

One of the key best practices is to be very clear about which types of content are worth compressing and which aren't. As a general rule, you should enable Brotli and Gzip for:

• HTML and server-rendered templates (text/html).
• CSS and JavaScript (text/css, application/javascript, etc.).
• JSON and XML APIs (application/json, application/xml).
• Web fonts (TTF, OTF, WOFF, WOFF2) if your server allows it.
• SVG (image/svg+xml), which although it is an image, is actually text.

Conversely, it is advisable to exclude the following from compression:

• Images such as JPEG, PNG, WebP, AVIF, GIF.
• Videos (MP4, WebM, etc.).
• ZIP, RAR, 7z, .tar.gz files and similar.
• PDF and other binaries are already highly optimized.

It's also wise to define a minimum response size (for example, 1 or 2 KB) to avoid compressing tiny messages where there's little to no benefit. This saves CPU and prevents adding latency to content where compression doesn't add any value.

How to check if Gzip or Brotli are active

Once compression is configured, it's necessary to verify that it's actually being applied and that the headers are behaving as expected. There are several ways to do this, from online tools to command-line utilities or the browser's DevTools.

Services like Gift of Speed, KeyCDN's Brotli test, or Paul Calvano's tools allow you to enter a URL and see if the response arrives compressed with Gzip, Brotli, or without compression, as well as the size before and after.

In your browser, simply open the Developer Tools (Network), reload the page, and select a resource (for example, the main HTML). In the headers panel, you'll see something like this:

• content-encoding: br if Brotli is being used.
• content-encoding: gzip if Gzip is being used.
• Lack of content-encoding if it arrives uncompressed.

You can also resort to curl from the console, forcing a Accept-Encoding Specifically, and reviewing the answer:

curl -H "Accept-Encoding: br" -I https://tu-dominio.com
curl -H "Accept-Encoding: gzip" -I https://tu-dominio.com

If you see `Content-Encoding: br` or `Content-Encoding: gzip` in the response, everything is working. Also, take this opportunity to check that `Vary: Accept-Encoding` is being sent , which is essential for caches and CDNs.

Impact on performance, CPU, and security

Enabling Brotli and Gzip is one of the most cost-effective optimizations for web and API performance, but its implications for resources and security should not be forgotten.

On the performance side, compression drastically reduces file size, resulting in less download time, better metrics such as First Contentful Paint and perceived Time to First Byte, and a direct decrease in bandwidth consumption (something that is noticeable on the bill from providers like AWS).

The cost lies in the CPU and memory required for compression and decompression. Brotli, especially at higher levels, is more demanding than Gzip. Therefore, for dynamic content, it's best to use intermediate levels (3-5) , and reserve the extreme levels for pre-compression of static content or for very specific scenarios.

In security, compression can be affected by theoretical attacks like BREACH , which exploit variations in the size of compressed responses to try to deduce sensitive data. Although these are fairly specific scenarios, it's a good idea to:

• Avoid compression highly sensitive responses that mix secrets with user-controlled data.
• Separate tokens and credentials from any input provided by the client.
• Apply classic measures such as CSRF tokens, rate limiting and monitoring of suspicious patterns.

With a sensible configuration, Brotli and Gzip become key allies for accelerating websites, APIs, and streaming and download services without compromising security.

This entire compression ecosystem—from Gzip, which remains the de facto standard, to Brotli, which maximizes size reduction with advanced dictionaries and much larger analysis windows—gives you enormous leeway to optimize how your data travels across the network. By combining both algorithms with reasonable compression levels, carefully choosing which types of content to compress, relying on CDNs that support Brotli end-to-end, and always verifying headers and the real impact on your performance metrics, you can make your website, APIs, streams, and downloads feel much lighter and more agile without touching a single line of business logic.