As with any site, speed is often an important requirement for those built using Divi. With Google using the speed at which your site loads as a factor in determining how high to rank it in their search results, if you want a good ranking, a fast site is critical.
Enabling GZip compression allows your site to shrink the download sizes of your web pages before sending them to the user, resulting in faster loading of your site.
Test whether Compression is enabled on your Divi Site
A number of online tools will let you check for compression on your site, including Page Speed Insights and Pingdom.
Google Page Speed Insights
If you're after good Google rankings, then you could do worse than test your site with Google's own PageSpeed Insights tool. PageSpeed Insights will flag when compression is not enabled, like so:
Pingdom
Similarly, the popular Pingdom website speed test can be used to detect a lack of compression. It will report it like so:
Enabling Compression using Divi Booster
I've just added an option to Divi Booster to enable compression for Divi, so your site loads faster and should rank higher in Google as a result. You can find it under "General » Site Speed":
Once enabled, wait 30 seconds then test your site again with PageSpeed Insights and you should see that your site scores higher and tucked away under "passed rules" you'll see:
Enabling Compression with htaccess
To manually configure your site to enable compression for Divi, you can add the following to your .htaccess file:
<ifmodule mod_deflate.c>
Addtype font/truetype .ttf
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/xhtml+xml application/rss+xml application/x-javascript application/javascript text/javascript font/truetype
</ifmodule>
Does this conflict with SG Optimizer or Hummingbird?
The Divi Booster "Enable Compression" feature shouldn't conflict with the Hummingbird Pro or SG Optimizer GZIP compression features. That said, they're all doing essentially the same thing, so it is probably best to enable it in just one of the plugins. If you're hosted with Siteground, I'd be inclined to use the SG Optimizer feature since they'll presumably make any tweaks necessary to optimize the the compression for their servers.
A couple of general notes on using these plugins with Divi Booster. I've seen at least one case where it was necessary to clear hummingbird's cache after making a change in the Divi Booster settings, so that's something to bear in mind if your changes don't show up straight away. Also, the SG Optimizer "Remove Query String" feature messes with Divi Booster's (and presumably other plugins') CSS / JavaScript file versioning and can result in old versions of these files being used. I'd suggest disabling that feature if possible. I'll hope to be able to update Divi Booster in the future to better manage cache clearing with these two plugins.
Hi Dan. My site went from 32 til 49/100 still poor – but better. Thank you :-) I don't know much about this. But I just installed Wp Smush Pro after I have run this – hardly any thing happend with the speed. Do you have any advice what else to do? Kind regards Elisabeth
Hey Elisabeth, compression is just one piece of the puzzle, so your slight improvement is inline with what I'd expect from that.
For the images, I think WP Smush optimizes images at the time they are uploaded. This means that by default new images will be optimized but ones that were there before you installed it won't be. I'm pretty sure there's an option somewhere in its settings to make it go through and optimize older images. If that doesn't help, on there page speed insights results page you'll find a link at the bottom that says "Download optimized image, JavaScript, and CSS resources for this page". You can use this to download optimized versions of your images – use these to replace the ones already on your site and you should then pass the image optimization checks.
Next, I'd install a plugin such as Autoptimize to perform CSS and JavaScript "minification" (just shrinking the files by removing unnecessary stuff). Also install a caching plugin such as Cache Enabler.
Also, go through and remove any plugins you no longer need, etc.
That should hopefully help improve things!
Dan,
Do we still need to use this … what with the new Divi Compression and minification.
Also, I note that your htaccess rule is slightly different to mine. Anything significant.
# compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddType x-font/otf .otf
AddType x-font/ttf .ttf
AddType x-font/eot .eot
AddType x-font/woff .woff
AddType image/x-icon .ico
AddType image/png .png
Many Thanks
Mark
Hey Mark,
I believe it's still needed. The "compression" added by the recent Divi updates is really minification – i.e. it's removing white-space and such from the CSS, JS, etc, files to make their file sizes smaller. The compression discussed in this post is gzip compression where the server essentially zips up the files (post-minification) to further reduce their file size before sending the to the browser to be unzipped and displayed. I haven't seen any indication that Divi has added support for gzip compression yet. They're promising more performance updates though, so it may still be on the way.
I don't think the differences between our rules are going to be particularly significant in real performance terms. It looks like the difference is that I'm including text/text and truetype fonts while you have application/xhtml+xml and application/rss+xml. I don't think any of these will have a major impact on the overall performance of the site. Still, there's no harm in including them all so I'll add in the ones I was missing.
The "AddType" declarations at the end of yours aren't related to compression – they set the mime type by file extension, basically telling the browser how to handle them.
Thanks!
This… really works!! Nice!
It should be included in the Divi documentation, what a difference this just made.
Thank you Dan!
You're very welcome, Verdi!
Hello,
I have checked the box to compress the site, and I did not notice any change in the speed. Is there a way to check to see if it is functioning properly? Thank you in advance for your help!
Hi Nick, you can check that GZIP compression is working with a site such as this: http://checkgzipcompression.com/
Note that enable compression is only one piece in the puzzle of speeding up a site. While it should improve download times by decreasing the download size of your webpages, you may find that the improvement is small relative to the total page load time. Depending on your site there may be other things which can make a bigger difference, such as optimizing image sizes and reducing the number of HTTP requests required to produce the page. I hope to add more Divi speed improvements in the future to help address some of these. But it's definitely worth having GZIP compression enabled all the same.
Does compression in divi booster work with WP Rocket or is there no need for compression because WP rocket already doing it?
Hi Tim, there should be no need to enable compression in Divi Booster if you have it enabled in WP Rocket. As long as either one of them enables compression your site speed should benefit. While it should be possible to enable both at the same time there will be no additional benefit from doing so and it would be best not to, just to avoid any complications.
Hi Dan, this is great. I had a question about compression. Is there any reason against enabling this? I'm just curious why people wouldn't want this.
Hey Mike, there are a couple of situations I can think of where you may not want to use it, but they're pretty rare. Compressing increases the load on the server slightly, so if you have very high traffic site you may find enabling it pushes you up against some resource limits. Also, some (very old or custom) browsers may not support compression and wouldn't be able to view the site. Finally, there are some security issues around the use of compression (an attacker who could control part of the server response could infer details of the remaining response content based on the observed level of compression), but these are difficult attacks to mount and not a serious threat for most sites (attackers will prefer simpler attacks like password guessing).
For almost all sites, particularly blogs, the use of compression will be beneficial. The improved user experience (faster page loads) will almost certainly offset the risk of any of the above.
Brilliant Dan. Thank you so much for this. I have always tried to retain my page speed and the Booster fix has given an immediate 20% increase taking my site back up to 88/100. I've appreciated all the Booster additions, but this one is the one I've valued most :)
Hi Dan,
Thanks so much for the quick fix on the compression issue! Seems to be working great and improved site speeds by nearly 20%!
I did however notice a small issue I thought I'd see if there might be a fix for – specifically I ran a backup of the site (I use BackWPup) and warnings popped up for all minified files, as having file names that are too long to back up properly. I presume this file name is a result of the compression and I have not honestly had the need to restore from backup to see if this will actually pose any future problems, but I did wonder if there is any way to change the file naming conventions? Just curious!
Thanks for your hard work!
Aleks
Hey Aleks, glad you're seeing a nice increase in the site speed :)
The backup issue has nothing to do with the compression. The compression just shrinks the contents of files as they are being sent to the browser, it doesn't affect file names in any way.
I don't know BackWPup, but a search showed that other people have the same issue with it and this post seems to offer a couple of possible fixes:
https://wordpress.org/support/topic/warning-file-name-too-long-to-be-saved-correctly-in-targz-archive-1
Hope that helps!
Thanks so much for the quick fix – it works perfectly now!
I am trying to enable this feature on my site but it doesn't show under the "general" tab. I'm using Version 1.6.4 currently so I don't know if that's current or not but it says it is.
Hi Ben, I added compression in 1.6.5 (the current version is 1.6.7). Updates are only shown as available once your license key has been activated on the Divi Booster settings page – if you activate the license key and then on the plugins page click "Check for Updates" beside Divi Booster, it should should the available update.
I activated it a few months ago and still can't update. Can you send me a download link for the updated version please?
Hi Ben, I've just resent your purchase confirmation email with the download link. Let me know if you don't receive it. Thanks.
Hi!
Thanks for all the great work. I just updated and checked on the 'enable compression' checkbox to improve site speed, however it crashes the site with internal server error 500 every time I turn it on, and I have to delete the .htaccess file every time to restore the site. Can you let me know if there is a fix for this, aside of completing all the pagespeed insight recommendations?
Thanks,
Aleks
Hi Aleks. There was a bug in the way the plugin generated the .htaccess file. I've fixed this in the latest version of the plugin, so if you update it and then save the settings you should be able to use the Enable Compression feature without errors.