More Site Speed Gains with Brotli Compression Algorithm
We are happy to announce that we have deployed and enabled by default the Brotli compression algorithm on our Site Tools servers so websites hosted there could get up to 15-20% speed gains from using it.
What is Brotli?
Brotli is a next generation compression algorithm developed by Google as a successor to the popular gzip method that we’ve had running on our servers for ages. The idea is simple – once your application produces the HTML output of your website and the output is compressed together with all the resources it loads, the data is transmitted over the Internet and then the browser decompresses the content before rendering it. This process significantly reduces the size of data that’s been moved from the server to the visitor, resulting in speed gains multiple times bigger than the milliseconds lost for compression and decompression.
How much faster is Brotli compared to gzip?
The new algorithm provided by Brotli compresses the website into smaller data size, which makes it faster to transfer. JavaScript files compressed with Brotli are roughly 15% smaller than the ones compressed with gzip. HTML files are around 20% smaller and CSS files get around 16% size reduction. Those numbers of course will differ depending on your particular files.
Comments ( 27 )
Thanks! Your comment will be held for moderation and will be shortly published, if it is related to this blog article. Comments for support inquiries or issues will not be published, if you have such please report it through
dr.newdell2015@gmail.com
Many thanks! The article is well written. The service is very much appreciated. In that we don't have to do anything, we can all be thankful to you for this excellent upgrade. SN
david marsh
Its great to know that you guys are contently improving the platform. Its also great when these types of improvements are made without us having to do anything. Much appreciated. Thanks.
Krunoslav
Hello! I plan to become a new SG customer and have few very short questions. As I have read here, there is a server side caching. That is off course great news. So do I need to install any cache plugin at all if the server side caching is available? And if I decide to install a cache plugin can I choose some other plugin (for example WP Rocket), or it has to be SG Optimizer plugin? And finally, on my existing site which I plan to transfer to SG I use premium Cloudflare service (not free version). I would like to continue to use that also, but I wonder if there is going to be some conflict between those 3 things since they are all doing the same thing. For example I can enable Brotli Compression by Cloudfare, by plugin, and it's already enabled from the server side. So should I use just one of those 3 things for the same thing (brotli Compression, for example) or it's ok to use both plugin and Cloudflare for the same thing. The same applies for other things such as auto minify java script, css, html etc. Thank you very much on your answer.
Hristo Pandjarov Siteground Team
You need to use the SG Optimizer plugin in order to get the best loading speeds for your site and utilise our server-side caching. Since it provides all the necessary front-end and media optimizations too, you do not need to use an other plugin like WP Rocket for example. Now, if you have full-page caching on Cloudflare you can keep the Dynamic caching off at SG Optimizer in order to avoid potential caching issues. Same goes for front end optimizations - do them at SGO or at the Cloudflare plugin, just don't duplicate functionality.
MiamiCityMan
Just to be clear: no futher internal caching plugin should be used if full CLOUDFLARE caching is activated?
Hristo Pandjarov Siteground Team
Yes, you don't need anything else
Patrick Bianconi
Thanks for the CloudFlare Full Page tip.. I will have to check.
Lazhar
Noticed a speed improvement over the last week or so. Probably due to Brotli compression as nothing else changed. Thank you for constantly improving the service behind the scenes!
Kris
Hi Hristo, This is so great news for me that Brotli is now implemented on SG. I remembered that late 2018-2019 I have ever recommended you about Brotli compression algorithm. So now I couldn't wait enjoying it and awaiting migration to Site tool :) Totally appreciated SG Hosting Service since 2016 on GoGeek plan.
Hristo Pandjarov Siteground Team
I hope that we will migrate everyone to Site Tools by the end of march so you will soon be able to benefit from it :) Once we completely move awawy from cPanel our hands will be untied to implement new technology much, much faster!
Jerry
Good news on Brotli. Even better news is the end of March date to complete the migrations to Site Tools! Been waiting for that for quite a while :-)
LM
Hello, we have a Cloudflare account that all our SiteGround sites are added to. For each site, we already had the 'Brotli' option enabled from within our Cloudflare account. So we want to ask if there is any potential issue with having Brotli now enabled in both SiteGround and Cloudflare? If there is, is it best to have it enabled just in SiteGround or just in Cloudflare? If it is best to have it enabled just in Cloudflare, is there any way we can have it disabled for all our sites in SiteGround? We're not sure where this option could be located in our account. Thank you.
Hristo Pandjarov Siteground Team
There isn't any issue, since you have Cloudflare being "man in the middle" it will only optimze the connection between the server and the CF end point. If you're using CF it is best to have the full page caching working there otherwise you're slowing your site down probably. Brotli on or off won't have signifficant effect compared to that.
LM
Okay, wonderful. Thank you for answering our questions about this!
Minu
Is it available on google cloud hosting?
Hristo Pandjarov Siteground Team
All our accounts are on GCP and they hahve it available :)
WebKiwiNZ
What is the decompression time like is the algorithm compared to gzip? It is good to improve network performance but what is the impact on cpu utilisation at the users end? On older hardware that would have a significant impact if it has a much higher workload to decompress.
Hristo Pandjarov Siteground Team
Savings in networking traffic dramatically outweight the time needed for compression and decompression. However, they are better than the gzip ones too.
Patrick Bianconi
Thank you for this. SG constantly improving and keeping costs at a minimum.
Scott P
Is there a browser-side way to test if it's in operation?
Hristo Pandjarov Siteground Team
Yes, you can used the right click -> inspect element and check the Networking tab -> headers for your site. Refresh and if the browsers supports Brotli, you should see a response header: Content-Encoding: br
Judy Burns
Thank you so much for all the work you do to make SG a great hosting company.
Tim Krueger
Just wanted to say a big thank you. The moves you've made since I switched all my sites to sitegeound a little over 3 years ago are greatly appreciated.
ts1g
Submitted this as a comment back on February 6, and got a confirmation that it had been received / was waiting for moderation, but it never posted: "Brotli compression is great, and much needed, but equally needed is for SG to upgrade from Postgresql 11.8 to Postgresql 12.x or 13.x since no version of 11 supports calculated fields (generated columns in Postgres speak). The combination of Brotli and stored calculations would significantly bump throughput from Postgres databases, and Postgresql 12 has been supported on Google Cloud for some time now.
Hristo Pandjarov Siteground Team
The upgrade is in our roadmap but at this point I can't give you an ETA when exactly it will be performed. We will do it as soon as possible.
Chris Bennett
I love the idea of automating Brotli with Gzip fallback for all customers. The less manual htaccess needed, the better. However, I noticed that .ico and .webmanifest files don't appear to be compressed. It seems, very likely due to the new-ish automated compression, that htaccess can't do anything. Attempts to add htaccess compression rules in the "old" way seems to result only in additional and unnecessary Vary: accept-encoding headers being added and only on the files which are already successfully compressed. Is there any chance .ico and .webmanifest files could be added to the compression?
Hristo Pandjarov Siteground Team
Those are not mime types that we compress by default. It doesn't make much sense to do so since those are very, very small files and the difference will be insignifficant anyway.
Start discussion
Thanks! Your comment will be held for moderation and will be shortly published, if it is related to this blog article. Comments for support inquiries or issues will not be published, if you have such please report it through