Every time a user wants to reach your site, they make a call to your web server with their browser. The call goes out to load the data of the page, which includes your HTML, your CSS, and any media you have on the page.
The larger the files that need to load, the longer it takes for the page to load as a whole. This applies even if you’re lazy loading or asynchronously loading content; that content still needs to load. You can load a page faster by loading everything at once rather than all at a time, but you still have to content with sending the files. The larger the files, the longer they take to send, period.
Ideally, what you’d do is find a way to make your files smaller. There are a lot of different ways to do this.
On top of all of that, though, you can enable Gzip compression. Gzip is a form of zip-based compression purshed in the Unix community under GNU, which is where the G comes from. It uses the DEFLATE algorithm, which is quite technical if you want to read about it. I find it fascinating but, at the same time, recognize that knowing how compression works isn’t necessarily important to getting it to function.
When installed properly, it can greatly speed up your site. Keyword, properly. Let’s figure out how why it isn’t working and how to enable it.
There are a lot of different ways you might enable Gzip compression on your web server, and it depends a lot on what architecture your server is running.
If your server is running IIS, all you really need to do is go into your configuration settings and enable compression. The server software will handle the rest. You can read the documentation here.
If your web server is running Apache, you will need to add some code to your .htaccess file. Basically, you’ll be added an output compression filter on your files, and will need an individual line for each type of file. You can read more about using that all over the web. Here’s a discussion on the differences between mod_deflate and mod_gzip, both forms of compression you can enable using .htaccess.
If you’re running a server architecture where you can’t modify your .htaccess file directly, such as when you’re using a website builder or a locked-down shared host, you will need to add some PHP code to your HTML files. You can read about that method here.
There are a lot of ways that Gzip can fail. As you can probably tell from the above methods and the links I’ve added, there’s a lot of precise code you need to add to some file or another on your site.
The very first thing you should check is whether or not your web host supports Gzip compression. Believe it or not, there are some out there that don’t care about compression or page loading speed, and thus don’t bother having compatibility for it. Contact your web host to see if they allow Gzip, and if they don’t, you will have to do the best compression you can without using an automatic compression protocol.
The second thing you should do is check your code to see if it’s functional. There could be a syntax error, a missed character, or just malformed code that doesn’t work with your architecture. There are dozens of examples of code to add to your .htaccess or code for PHP compression that you can find all over the web. If one doesn’t work, try a different one. There’s no reason to struggle to debug code if you can just wholesale replace it with something more likely to work.
It’s also possible that you simply don’t have access to the right files to enable Gzip compression, but your web host does. You might need to contact them and just tell them to enable it. It could also be that your code doesn’t work because there’s a different method of compression already enabled, and your code is conflicting with the existing compression. Did you check to see if your files were compressed to begin with, or did you just assume that since you didn’t turn it on yourself, it must not exist?
To test whether or not Gzip compression is in effect, you can either use a tool like Firebug to examine the files that you get from your website when you visit it, or you can use a third party website like Check Gzip Compression to just test and see. What’s cool about this site is that if your compression is not enabled, it will tell you how much size could be reduced if you enabled it properly.
There are two other reasons why Gzip might not be working on your site. One of them is that you’re testing it from an out of date browser. Some browsers, particularly old versions of Internet Explorer – I know – don’t handle the server call properly. You will need to take special consideration if you expect people to be using your site from such an old browser.
Now, why would people be using an old browser like that? Unfortunately, in the corporate world, old browsers are often mandated because old corporate web apps require old versions of Java, which don’t work in newer browsers. As much as people would prefer to be using real modern browsers, they sometimes can’t. Now, does that mean you need to cater to them? I don’t think so. Honestly, those people can just deal with a slower Internet, and hopefully it puts more pressure on them to update.
The other reason Gzip might not be working is that you have extremely large files on your site. Older version of Gzip have a file size limit of something like 2GB. Any file larger than that will not be compressed using the Gzip algorithm. That is, however, relying on the older algorithms. Newer versions of Gzip work with larger files, though it can often take a bit of time to compress them and uncompress them. The larger a file is, the less it benefits from being compressed, unless it’s purely text. Text compresses very well. Videos don’t compress well at all. Additionally, if the content is already compressed using some other algorithm from some other source, it won’t give you any benefit to re-compress it.
You can experiment with other compression algorithms if you like, but I don’t know enough about them offhand to give you a recommendation.
Another consideration you might have is using WordPress. If you’re using a WordPress installation, you can likely use the .htaccess method above without any issues. However, you can also take a shortcut and use one of the many plugins available for exactly this purpose. Here are some options:
There are other options as well, I just listed some of the best and easiest to use. Feel free to browse the WordPress plugin directory yourself if none of these suit your needs.
Remember that, while compression saves time in terms of transfer rates, it does tax the performance of the server more than sending uncompressed content would. The question you have to ask yourself, then, is this: does your server lack CPU power, or does your audience lack in web browser speed? If you’re operating on a very low cost shared host with an underpowered CPU, you might not want to enable compression. Your site will be slower, but it helps prevent overuse of your server resources. It’s fairly rare to be in this situation unless you have an incredible number of users and a pretty old, underpowered web host. In that case, it might be beneficial to consider changing web hosts, because who knows what other ways they’re holding you back.
On the other hand, if your users are using mobile devices or using slower connections, like in rural areas, it’s probably a good idea to enable compression. Heck, if nothing else, compression is going to give you a page load time decrease, which is a PageSpeed increase, which means you’re going to get some SEO value out of it. Not a ton, but some, and all the little sources of “some” SEO value add up over time.
Personally, I feel like there’s almost never a good reason to not enable compression. If nothing else, it does no harm to be enabled; if people who can’t decompress files try to use your site, your site will send the uncompressed data, because it’s better than sending nothing at all.