How to Enable GZIP Compression in WordPress

Your site almost certainly already does this. Compression has been standard on hosting for years, and most of the guides telling you to edit files are describing a job that was done for you when you signed up. So the first step is not to enable anything. It is to spend ten seconds finding out whether you need to.

Check it in ten seconds

If you have a terminal, one command answers it:

curl -sI -H "Accept-Encoding: gzip, br" https://example.com | grep -i content-encoding

Three possible answers:

• content-encoding: br means Brotli, which is what modern browsers get. Nothing to do.
• content-encoding: gzip means compression is working. Nothing to do.
• No output at all means the response came back uncompressed, and the rest of this applies.

No terminal? Open your site in Chrome, press F12 for DevTools, choose the Network tab, reload, click the first request in the list, and look under Response Headers for content-encoding.

One trap worth avoiding. Click an HTML, CSS or JavaScript request, not an image. Photographs are already compressed, so a correctly configured server deliberately sends them uncompressed. Testing on a JPEG makes a working setup look broken.

What compression is actually doing

Every browser tells the server what it can handle, in a request header:

Accept-Encoding: gzip, deflate, br, zstd

The server picks one it also supports, compresses the response, and says which it used in the Content-Encoding header. The browser decompresses it before anything is rendered. All of it is invisible and takes single digit milliseconds.

The reason it is worth having is the size of the difference. Measuring this site's own home page:

Roughly three quarters off, for one line of server configuration. HTML, CSS and JavaScript are extremely repetitive, and repetition is exactly what these algorithms remove. That is why text compresses so well and a photograph does not compress at all.

Note the third row, because it undercuts the usual advice about Brotli. More on that below.

If it is off, find your setup first

Where you make the change depends entirely on what is in front of your site. Work down this table and stop at the first row that describes you.

Most people are in the first three rows and finish here.

Apache

Compression is handled by mod_deflate. Add this to .htaccess in your site root, above the # BEGIN WordPress line so a core update cannot overwrite it:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
  AddOutputFilterByType DEFLATE application/javascript application/json
  AddOutputFilterByType DEFLATE application/xml application/rss+xml
  AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

Download a copy of .htaccess before you edit it. A syntax error in this file returns a 500 on every page of the site, including the dashboard, and the only way back is to replace the file over FTP.

The <IfModule> wrapper matters. If mod_deflate is not loaded, it makes the block do nothing instead of taking the site down.

Note what is missing: no fonts. WOFF2 is Brotli compressed internally already, so compressing it again burns processor time to save nothing. Plenty of copied snippets include it.

Nginx

In the http block of nginx.conf, per the gzip module documentation:

gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_types
  text/plain
  text/css
  text/xml
  application/javascript
  application/json
  application/xml
  application/rss+xml
  image/svg+xml;

Then test the configuration before you reload it, because reloading a broken config takes the server down:

sudo nginx -t && sudo systemctl reload nginx

Three of those lines are the ones people leave out.

• gzip_vary on adds Vary: Accept-Encoding, which stops a proxy caching a compressed response and serving it to a client that cannot read it.
• gzip_min_length 256 skips tiny files, where the compression header costs more than it saves.
• text/html is deliberately absent from gzip_types. Nginx always compresses it and listing it causes a warning.

gzip_comp_level 5 is a deliberate middle. Level 9 costs noticeably more processor time for around one per cent smaller output, which is a bad trade on a busy server.

What it will not do

Compression only helps text, and this is where expectations usually go wrong.

Which leads to the honest caveat about all of this. If your pages are slow and your home page is 4MB, compression will take a few hundred kilobytes off the HTML and leave the 3.5MB of unoptimised photographs exactly as they were. It is worth having and it is rarely the thing that was wrong. Our guide to why WordPress sites run slowly covers what usually is.

Brotli, zstd, and whether to chase them

Brotli is newer than gzip, supported by every current browser, and it compresses text better. It is genuinely the better algorithm, and it is what your visitors are already getting from any CDN.

What it is not is a reason to spend an afternoon. Look again at the measurement from earlier: gzip produced 12,226 bytes and Brotli produced 12,236, so Brotli was ten bytes larger.

That is not a mistake, and it is worth understanding. Brotli's advantage shows up at high compression levels, which are slow. When a server compresses a page on the fly it uses a low level to keep response times down, and at low levels the two algorithms are near enough identical. The large Brotli wins quoted in benchmarks come from static assets compressed once at maximum level and served from disk.

Zstandard is newer still and appears in browser Accept-Encoding headers now. Support on the server side is patchy, and asking for it against this site returns no compression at all, which is the correct behaviour when a server does not offer it.

The practical position: if your CDN or host offers Brotli, it is already on and you have gained from it. If it does not, gzip captures nearly all the available benefit, and your time is better spent on images.

When it looks on but is not

Five things account for nearly every case where the header is missing after you have configured it.

1. You tested an image. By far the most common. Re-test against the HTML document itself.
2. A cache is serving an old copy. The page was cached before you made the change, so it is replayed uncompressed. Clear the site cache, then the CDN cache. Our guide to clearing WordPress cache covers the order.
3. Two layers are both compressing. A plugin and the server, or the server and the CDN. Symptoms are odd rather than obvious: garbled output for some visitors, or double-encoded responses. Pick one layer and switch the other off.
4. The module is not installed. The <IfModule> wrapper means a missing mod_deflate fails silently by design. Ask your host whether it is loaded.
5. Cloudflare Development Mode is on. It bypasses the edge, including compression, and it switches itself off after three hours, which is long enough to cause real confusion.

After any change, re-run the curl command from the top rather than judging by how the site feels.

The short version

Run the check. If you get br or gzip back, you are done and this was never your problem. If you get nothing, the fix is a support ticket on managed hosting, a checkbox in cPanel, or one block of config on your own server.

Then go and look at your images, which is where the actual weight is.

Frequently asked questions