How to Configure Apache for Content Compression

Abdul Wahab Junaid

3 years ago

How to configure Apache for content compression

If a website feels sluggish, one of the first things I check is whether compression is turned on. It’s one of those settings that takes minutes to configure but can shave a huge chunk off page load times. In this guide, I’ll walk through exactly how to set up content compression on Apache, why it matters, and how to avoid the common mistakes that trip people up.

What Is Content Compression, and Why Does It Matter?

Content compression is the process of shrinking the size of files (HTML, CSS, JavaScript, JSON, XML, and more) before Apache sends them to a visitor’s browser. The browser then decompresses the file on arrival and renders it normally. The visitor never notices anything except that the page loaded faster.

Apache handles this through two modules:

mod_deflate – uses the Gzip compression algorithm, widely supported and the de facto standard for years.
mod_brotli – uses Google’s Brotli algorithm, which typically compresses better than Gzip but requires a newer Apache build and isn’t available everywhere.

Compression matters because:

Faster load times – smaller files transfer faster, especially on mobile or slow connections.
Lower bandwidth costs – less data transferred means lower hosting bills, especially at scale.
Better SEO – page speed is a ranking factor for search engines, and compression is one of the easiest wins.
Improved user experience – faster sites reduce bounce rates and improve conversions.

Prerequisites

Before diving in, make sure you have:

A server running Apache 2.4+ (most modern Linux distributions ship with this)
Root or sudo access to the server
Basic familiarity with the command line and editing configuration files
Apache installed via a package manager (apt, yum/dnf) or compiled from source

Enabling mod_deflate

Step 1: Check if the Module Is Installed

On most distributions, mod_deflate ships with Apache by default. Verify it’s available:

apache2ctl -M | grep deflate

On CentOS/RHEL systems, use:

httpd -M | grep deflate

If you see deflate_module (shared) in the output, it’s already loaded. If not, enable it.

Step 2: Enable the Module

On Debian/Ubuntu:

sudo a2enmod deflate
sudo systemctl restart apache2

On CentOS/RHEL:

The module is usually compiled in by default. If it’s missing from your httpd.conf, add this line:

LoadModule deflate_module modules/mod_deflate.so

Then restart:

sudo systemctl restart httpd

Step 3: Configure Compression Rules

Open your Apache configuration file (commonly /etc/apache2/apache2.conf, /etc/apache2/conf-available/deflate.conf, or a virtual host file) and add the following block:

<IfModule mod_deflate.c>
    # Compress HTML, CSS, JavaScript, Text, XML and fonts
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
    AddOutputFilterByType DEFLATE application/x-font
    AddOutputFilterByType DEFLATE application/x-font-opentype
    AddOutputFilterByType DEFLATE application/x-font-otf
    AddOutputFilterByType DEFLATE application/x-font-truetype
    AddOutputFilterByType DEFLATE application/x-font-ttf
    AddOutputFilterByType DEFLATE application/x-javascript
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE font/opentype
    AddOutputFilterByType DEFLATE font/otf
    AddOutputFilterByType DEFLATE font/ttf
    AddOutputFilterByType DEFLATE image/svg+xml
    AddOutputFilterByType DEFLATE image/x-icon
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/xml

    # Don't compress already-compressed formats
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|rar|zip|exe|flv|mov|wma|mp3|avi|swf|mp?g|mp4|webm|webp)$ no-gzip

    # Remove the 'Vary' header for proxies that don't handle it correctly
    <IfModule mod_headers.c>
        Header append Vary User-Agent env=!dont-vary
    </IfModule>
</IfModule>

Save the file, test the configuration, and restart Apache:

sudo apachectl configtest
sudo systemctl restart apache2

Setting the Compression Level (Optional Tuning)

You can control how aggressively Apache compresses content using DeflateCompressionLevel, which ranges from 1 (fastest, least compression) to 9 (slowest, best compression):

DeflateCompressionLevel 6

Level 6 is a good balance between CPU usage and compression ratio for most sites. Going to 9 rarely provides meaningful savings but noticeably increases CPU load under heavy traffic.

Enabling Brotli for Even Better Compression

If your Apache build supports Brotli (2.4.26+), it generally compresses 15-25% better than Gzip for text-based assets.

Install the module (Debian/Ubuntu):

sudo apt install brotli
sudo a2enmod brotli
sudo systemctl restart apache2

Configuration:

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css application/javascript application/json
</IfModule>

Many setups configure Apache to serve Brotli to browsers that support it and fall back to Gzip for older browsers, which Apache negotiates automatically based on the Accept-Encoding header sent by the client.

Verifying Compression Is Working

Once configured, confirm compression is actually happening:

Using curl:

curl -H "Accept-Encoding: gzip" -I https://yourdomain.com

Look for Content-Encoding: gzip in the response headers.

Using browser DevTools:

Open Network tab → click a request → check the Response Headers for Content-Encoding: gzip or br.

Online tools:

Sites like GTmetrix or the “Check GZIP Compression” tools will confirm compression and show the percentage of savings.

Real-World Use Cases

E-commerce sites with large product catalogs and heavy CSS/JS bundles benefit enormously — compression can cut page weight by 60-80% on text assets.
News and content sites serving large amounts of HTML text see faster time-to-first-byte perception.
API servers returning JSON payloads can compress responses significantly, which matters for mobile clients on constrained networks.
Single Page Applications (SPAs) with large JavaScript bundles see some of the biggest gains, since JS often compresses very well.

Common Mistakes to Avoid

Compressing already-compressed files – Images (JPEG, PNG), videos, and ZIP files are already compressed. Trying to Gzip them wastes CPU and can even increase file size slightly.
Forgetting to restart Apache – Configuration changes don’t take effect until Apache is reloaded or restarted.
Setting compression level too high – Level 9 barely improves ratio over level 6 but costs significantly more CPU under load.
Not testing with real headers – Some CDNs or proxies strip the Accept-Encoding header, which prevents compression from happening even if the server is configured correctly.
Ignoring the Vary header – Missing this header can cause caching proxies to serve compressed content to clients that don’t support it, breaking the page.

Security Considerations

Compression isn’t purely a performance feature — it has a security dimension too.

BREACH attack – Compression can, in specific scenarios, leak information about secrets embedded in HTTP responses (like CSRF tokens) when combined with attacker-controlled input reflected in the same response. Mitigate this by disabling compression on pages that reflect user input alongside secrets, or by using CSRF tokens that aren’t length-predictable.
Rate-limit compression on dynamic content if you’re concerned about CPU exhaustion from malicious high-volume requests targeting compressible endpoints.

Performance Optimization Tips

Combine compression with browser caching (see our companion guide on Apache caching) for maximum effect.
Pre-compress static assets at build time (e.g., generate .gz versions of CSS/JS during deployment) and serve them directly with mod_deflate‘s static file support, reducing CPU overhead on every request.
Monitor CPU usage after enabling compression, especially on high-traffic servers with limited cores.
Use a CDN in front of Apache; most CDNs handle compression at the edge, reducing load on your origin server.

Troubleshooting

Compression not applying:

Confirm the module is enabled with apache2ctl -M.
Check that your MIME types match what’s actually being served (text/html vs text/html; charset=UTF-8 can behave differently on older Apache versions).
Clear any caching layer (CDN, browser cache) that might be serving stale, uncompressed responses.

High CPU usage after enabling:

Lower the DeflateCompressionLevel.
Consider pre-compressing static files instead of compressing on every request.

Errors after config changes:

Always run apachectl configtest before restarting to catch syntax errors early.

Frequently Asked Questions

Does compression affect image files? No, and it shouldn’t. Images should be excluded from compression rules since formats like JPEG and PNG are already compressed.

Is Brotli always better than Gzip? Generally yes for compression ratio, but Gzip has broader compatibility and slightly faster compression speed in some cases. Serving both and letting the browser choose is the safest approach.

Will compression break my site? Properly configured, no. Issues typically arise from double-compression (e.g., compressing at both the CDN and origin) or missing Vary headers.

How much can I expect page size to shrink? Text-based assets (HTML, CSS, JS) typically compress by 60-80%. Overall page weight reduction depends on how much of your page is text versus already-compressed media.

Summary and Key Takeaways

Content compression reduces file sizes before they’re sent to browsers, cutting load times and bandwidth costs.
mod_deflate (Gzip) is the standard choice; mod_brotli offers better ratios where supported.
Configure compression by MIME type, exclude already-compressed formats, and set a sensible compression level (6 is a solid default).
Always test with apachectl configtest before restarting, and verify with curl or browser DevTools.
Be aware of the BREACH attack vector when compressing dynamic pages with reflected secrets.
Pair compression with caching and pre-compression at build time for the best performance gains.