I hope everyone enjoyed the holidays! After months of periodic troubleshooting, I finally solved my gzip compression mystery. The strange part is that it worked fine on all my websites for the root domain/homepage. However, any other page besides the homepage would result in no compression. It was a painstakingly tedious process of elimination. Usually, I can find an answer to a technical problem by scouring Google. And while I did come across a few other folks who described the same issue I was having, there were no solutions. Before I dive into my own solution, I’ll explain what GZIP does and why it is so important.
Gzip in a nutshell
As it relates to web hosting and server administration, gzip is a form of HTTP compression. Files and even pages themselves are compressed and served to visitors on websites with gzip enabled. You can expect to save a maximum of 75% – 80% of data being transferred vs. an uncompressed page. In the age of broadband, most users are not going to be impressed with trimming a 46.3 kb page down to 11.3 kb. However, Google and other search engines DO care. The speed of a website does contribute to its’ overall ranking factor in organic search results. Another consideration is to appease the mobile user. Connections can be spotty for some in certain locations. Compressing a page and serving it faster for those with weak connections can improve the odds that they will stay on your website.
Gzip compression example – tested on checkgzipcompression.com
As shown in the above screenshot, you can test to see if gzip is working on your website with checkgzipcompression.com or similar gzip checker tools. If you do not see compression being used it may simply mean that it is not enabled. There are far too many server configurations and variables to explain how to do this. Your best bet is to search google with your configuration and how to enable gzip. I guarantee you someone has written a tutorial for your specific needs.
How I resolved my Gzip woes
If you’ve followed the proper steps to enable gzip, there is a good chance you won’t have any issues with it working properly. However, if you have some exotic server configuration or are using experimental software, problems may arise. After going around in circles troubleshooting in Webhosting Manager, Cpanel, and .htaccess, a thought occurred to me. Of course, I have tested gzip on many of my websites with different WordPress themes, all plugins disabled, different versions of PHP, with PHP-FPM toggled on/off. Nothing seemed to work. It dawned on me that perhaps I should disable clean or “pretty” permalinks. It’s the URL structure that makes use of mod_rewrite to show a nice clean URL such as /my-example-page.html. Instead of the plain and ugly structure of /?p=123. And what do you know? Gzip finally worked outside of the home page on all of my sites! My theory is that compression was taking place before mod_rewrite had a chance to convert the URL. Perhaps breaking the compression process. But why?
Some ModSecurity configuration options
Taking a look at my security plugins
I started to look at my security and firewall plugins. Specifically, ModSecurity – an application for Web Hosting Manager that helps prevent attacks on your web server. It is a great firewall application and a must have if you are running WHM in my opinion. Interestingly enough, I noticed that if I disabled the Rules Processing engine compression, would work WITH pretty permalinks. This led me to where the rules came from. Which happens to be Pxysoft Anti Malware, another great plugin which I plan to review later. So I went through the rules directives located in the file modsec2.antimalware.conf (where the rules came from). I started commenting out every option and rule and then toggling the rules engine on and off – one by one. I did this by connecting via SSH. Which if you’re not familiar with, you really should read in-depth tutorials before messing around. Anyways, I came across the option SecDisableBackendCompression On and commented it out. After restarting the rules engine, gzip worked on all URLs! Finally!
Editing the Pyxsoft Anti Malware Rules File through SSH
Even though Backend Compression was enabled in the main ModSecurity Configuration page in WHM, the directive in the Pyxsoft Anti-Malware file overrode it. It remains to be seen whether my changes will be overwritten in the next Anti Malware update. At least, for now, my pages are all compressed and I can concentrate my efforts elsewhere. For anyone else who has this issue but doesn’t have Pxysoft Anti-Malware, try enabling Backend Compression in ModSecurity if it isn’t already.
Thanks for the article. I had the same issue on my website GarageDoorGuide.com – according to gtmetrix GZIP compression was only working on the homepage, but not on any blog posts. Here is how I fixed it.
Moved this line of code to the very bottom of the .htaccess file ….that way I could keep the short/clean URL permalinks AND have GZIP.
MOVE THIS CODE BELOW TO BOTTOM OF HTACCESS.
“# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
Thanks for your feedback! Perhaps this might be a clever way to get a backlink but I’ll allow it 😛
Just curious… did my solution work for you? It worked for me with one important exception. My “store” page (garagedoorguide.com/parts) in woocommerce will NOT compress as tested by gtmetrix.com. –
Moving the above code to the very bottom of my htaccess fixed every page except my store page. Any ideas on how to fix this? (my google search for an answer landed me right back on your page again)
I did not hyperlink the address using https prefix so that might not even count as a backlink. but thanks regardless. 🙂
Yeah I remember that moving the rewrite code in htaccess did have an effect in certain instances with gzip working. If I had to guess it’s probably an order of operations type of deal.
I checked your store page in 3 different tools and the results are saying gzip compression is enabled. Looks like you figured it out? I haven’t had the opportunity to test any sites with eccommerce/woocommerce pages, so I’m not sure if there is a reason the developers of that plugin would force gzip to be disabled.
The product pages etc are gzipped but the main store/shop addresss won’t compress.
https://garage door guide.com/parts
/parts is the main store page ALL of my other pages gzip fine but not the woocommerce page. Any ideas?? 🙂
Are you adding the trailing slash when testing? I noticed that /parts (and other pages without trailing slash) do not compress. However, when the slash is present (/parts/) compression works. It looks like your site’s navigation does load urls with the trailing slash, even though the pages still load either with or without it. Might try looking at your redirect script to ensure trailing slash is added regardless. But since the navigation (and i assume indexed pages in Google) make use of trailing slashes I would say not too worry too much.
^^^Solved
Wow that was it thanks… it was the “/” !!!!
Now I have even bigger problems with permalinks settings. At this point i’m going to have to leave the permalinks as is with the / at the end.
I think it just boils down to adjusting your rewrite code in htaccess. Found this snippet to enforce the trailing slash: https://docs.wp-rocket.me/article/131-redirection-to-enforce-trailing-slash-on-urls
Great POST!
Thanks. Works for me.
I’m glad that you found it helpful!