---
title: "What is mod_brotli"
source: "https://docs.nexcess.com/hosting/server-administration/linux/apache-web-server/what-is-mod_brotli/"
description: "Boost web speed with Brotli compression. Learn how it compares to GZIP, offering smaller files & faster decompression for a better user experience."
vertical: "Hosting"
date: "2025-05-28"
last_modified: "2026-07-29"
---

# What is mod_brotli

### **Understanding and using mod\_brotli for web compression**

Enhancing website performance is crucial, and one effective method is using compression to reduce the size of files transferred between your server and visitors’ browsers. While GZIP has been a long-standing standard, **Brotli** is a newer compression algorithm designed specifically for the web.

Brotli was **developed by Google employees**. Google released the **Brotli specification for HTTP in 2015**. Google engineers also made other **improvements to Brotli that made it even faster for compressing web content**.

#### **Brotli vs. GZIP**

Understanding the difference between Brotli and GZIP is key to appreciating Brotli’s benefits. **GZIP was designed specifically to compress files**. **Brotli, on the other hand, was specifically designed for the web**. Google recognized the need for a way to compress streams more efficiently, which led them to design Brotli.

While Brotli is not the most compressive option available overall, its **main tenant is to get the fastest decompression from the highest level of compression**. It’s actually **overall slower than GZIP at the initial compression**, but usually **beats it when decompressing the source**. The underlying idea is to **offload work from the client** so they see a site that renders slightly faster. Brotli is **faster at decompressing than GZIP**. When a browser supports Brotli, it notifies the server by sending a **“Content-Encoding: br” header**.

#### **Compression benchmarks**

To illustrate the difference, the source performed a rudimentary test using a file named media-views.js which was **227K** in size.

For Brotli compression, the following command was used to time the process on this file:

```
time brotli media-views.js
```

The result showed a **real time of 0m0.985s** for Brotli compression. The resulting compressed file media-views.js.br was **37K** in size.

For Gzip compression, the following command was used to time the process on the same file, aiming for the best compression:

```
time gzip --best media-views.js
```

The result showed a **real time of 0m0.016s** for Gzip compression. The resulting compressed file media-views.js.gz was **45K** in size.

In this test, Brotli was significantly slower at compression (0m0.985s vs 0m0.016s), but achieved a smaller file size (37K vs 45K).

#### **Decompression benchmarks**

The source also compared the decompression speed of the compressed files.

For Brotli decompression, the following command was used to time the process:

```
time brotli -d media-views.js.br
```

The result showed a **real time of 0m0.003s** for Brotli decompression.

For Gzip decompression, the following command was used to time the process:

```
time gunzip media-views.js.gz
```

The result also showed a **real time of 0m0.003s** for Gzip decompression.

In this specific test, the decompression times were nearly identical (0m0.003s for both). However, the source notes that typically Brotli is faster at decompressing than GZIP.

#### **Conclusion**

Based on this rudimentary test, the **compression time was a little slower with Brotli but offered better compression** (smaller file size). Despite the slower compression, **decompression was (marginally) faster** in this specific test. Scaling this up to hundreds of thousands of requests, even marginal savings in decompression time and bandwidth from smaller file sizes could be worthwhile. The idea is to shift the computational cost from the client (browser) to the server during compression, so the client benefits from faster decompression and less data transfer.