Gzip compression shrinks your HTML, CSS, and JavaScript before they travel to the browser, which makes it one of the cheapest speed wins a site can get. In this guide I will show you how it works, how to check whether you already have it (you probably do), how to enable and test it, and where Brotli has quietly taken over the job.
Key Takeaways
- Gzip compresses text files (HTML, CSS, JavaScript, SVG) on the server and often cuts them to a fraction of their size before they are sent.
- Check before you configure anything: most modern hosts and CDNs already compress responses, and double configuration causes odd bugs.
- Enable it via your hosting panel or caching plugin first; the .htaccess and Nginx snippets are the manual fallback.
- Never compress images or videos with gzip; formats like JPEG, WebP, and MP4 are already compressed and gain nothing.
- Brotli compresses smaller than gzip and every modern browser supports it, so where your server or CDN offers it, prefer it and keep gzip as the fallback.
How gzip compression works
When a browser requests your page, it announces what compression it understands through the Accept-Encoding header. The server compresses the response, sends the smaller file with a Content-Encoding header, and the browser unpacks it instantly on arrival.
Text compresses beautifully because code and markup are full of repetition, so gzip routinely shrinks HTML, CSS, and JavaScript to a fraction of their original size. Fewer bytes on the wire means faster loads, which feeds directly into your Core Web Vitals, and it even helps on the crawling side, since Googlebot caps what it fetches per file.
The sensible order for setting up compression
- Test whether your site already serves compressed responses
- If not, enable it at the host, CDN, or caching-plugin level
- Only then reach for manual .htaccess or Nginx rules
- Verify the Content-Encoding header and move on
Check first: your site is probably already compressed
Here is the step most gzip tutorials skip: modern hosts, LiteSpeed servers, and CDNs like Cloudflare compress responses out of the box, so many sites already have this handled. Configuring it again on top achieves nothing and occasionally causes double-compression weirdness.
The quickest check is one command from any terminal:
curl -s -I -H "Accept-Encoding: gzip, br" https://yoursite.com | grep -i content-encodingIf it returns content-encoding: gzip or content-encoding: br, you are done; close this tab and spend the time on a heavier bottleneck. If it returns nothing, or Lighthouse flags “Enable text compression”, keep reading.
How to enable gzip compression in WordPress
Start with the easy levers. Most caching plugins (LiteSpeed Cache, WP Rocket, W3 Total Cache) have a compression toggle, and on cPanel hosts the Optimize Website tool switches on Apache’s compression for your whole account in two clicks.
Some hosts expose it through PHP instead: in cPanel’s MultiPHP INI Editor, switching on zlib.output_compression makes PHP compress its own output. Use this only when the server-level options above are not available, because compressing at the server is cleaner than compressing inside PHP.
Enabling gzip manually in Apache and Nginx
Apache: the .htaccess mod_deflate rule
On Apache, add this to your .htaccess file. It tells the mod_deflate module to compress the text-based types and leaves everything else alone:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/json image/svg+xml
</IfModule>Nginx: the gzip directives
On Nginx, the equivalent goes in your server configuration (there is no .htaccess). The gzip_min_length line skips tiny files where compression costs more than it saves, per the Nginx gzip module docs:
gzip on;
gzip_types text/html text/plain text/xml text/css application/javascript application/json image/svg+xml;
gzip_min_length 256;One nuance on compression levels: gzip accepts levels 1 to 9, but chasing 9 is a bad trade, because the file barely gets smaller while your CPU works noticeably harder on every request. The defaults (around 4 to 6) are the sweet spot, which is why I do not tune them on client sites.
How to test that gzip compression is working
The curl command from earlier is the fastest check, but the browser shows you the same thing: open DevTools, load your page, click the main request in the Network tab, and look for content-encoding in the response headers. You will also see the transferred size sitting far below the resource size, which is the compression working.
Test a CSS file and a JS file too, not just the page itself, because a misconfigured setup often compresses HTML while static files ship uncompressed. PageSpeed Insights catches this as well; a passing site simply stops showing the text-compression warning.
Gzip vs Brotli: which compression should you use in 2026?
Brotli is the newer algorithm from Google, it compresses text meaningfully smaller than gzip at comparable cost, and every modern browser supports it. Cloudflare and most performance-focused hosts serve it automatically, which is why the earlier curl test checks for br as well.
That does not make gzip obsolete: it is universally supported, built into every server, and the difference on an already-lean site is small. The practical rule is simple, serve Brotli where your stack offers it and let gzip be the fallback; what you should not do is spend an afternoon hand-tuning gzip when flipping on a CDN gives you Brotli for free. The same logic applies to minification, which I covered when Cloudflare retired Auto Minify: compression at the edge quietly does the heavy lifting now.
Common gzip compression mistakes
The big one is compressing media. JPEG, PNG, WebP, and video formats are already compressed internally, so running them through gzip wastes CPU for zero gain, which is why the snippets above list text types only.
The second is stacking layers: a plugin compressing output while the server compresses it again, which shows up as garbled pages or mysterious encoding errors. Pick one layer, ideally the server or CDN, and switch the others off. And if your host handles all of this behind a managed panel, that is not a limitation, it is the product working as intended.
So, is gzip compression still worth your attention?
Text compression is absolutely still worth having; what has changed is how much of it you should be doing by hand. On most 2026 stacks the right move is to verify compression is on, prefer Brotli where it is offered, and resist the urge to fiddle further, because the header either says compressed or it does not.
If your site genuinely serves uncompressed text today, this is one of the best five-minute fixes available to you. Just fix it at one layer, confirm the header, and move your energy to images and hosting, where the bigger wins usually hide.
Compression header still missing after all this?
Don’t hesitate to contact us or email me and I will help you find which layer is refusing to compress. It is usually a two-minute fix once you know where to look.
Update Logs
03 Jul 2026
- Rewrote the guide around the check-first workflow (most hosts and CDNs already compress), added the Brotli comparison and a one-command test, and kept the Apache and Nginx snippets with clearer explanations of what each line does.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
