Are you looking for free ways to make your website faster? One way that every website owner can get a little free speed is to turn on compression at the server. When both the webserver and the browser it is conversing with understand a common compression algorithm, then the data that is actually sent over the wire can be compressed. Compressed data is smaller. Smaller data is received faster. <\/p>\n\n\n\n
When you type in a URL into your browser, your browser starts a conversation with the server<\/strong> and one of the things it tells it is if it can decompress content and if so, what compression \u201calgorithms\u201d it understands.<\/p>\n\n\n\n Your server listens<\/strong>, and if you have turned on compression and it knows one of the compression algorithms the browser does, it will compress all the data and send it to the browser<\/strong>.<\/p>\n\n\n\n Most modern web browsers understand or \u201caccept\u201d content encoded in one of three algorithms<\/strong>:<\/p>\n\n\n\n When a web browser contacts a server, it sends a header<\/strong> that looks like this:<\/p>\n\n\n\n Accept-Encoding: br, gzip<\/em><\/p>\n\n\n\n That tells the server that it understands data compressed in either Brotli (br) or Gzip (gzip). Servers do have the option of ignoring this and returning uncompressed data as well. <\/p>\n\n\n\n Overall though, compressed data travels faster than uncompressed data<\/strong>. So your website gets to the browser faster if the data is compressed.<\/p>\n\n\n\n Compression mainly applies to text:<\/p>\n\n\n\n These make up a large chunk of modern websites these days and all of these can be compressed by server-side compression algorithms. <\/p>\n\n\n\n On the other hand, most image formats<\/strong> (jpg, png, etc.), most audio<\/strong> formats (mp3s) and other non-text binary files are already compressed<\/strong>. Compressing these won\u2019t make any difference so regardless of the Accept-Encoding header, servers will send these as it is.<\/p>\n\n\n\n As stated above, most modern web browsers will accept 3 main compression algorithms. Most servers have now migrated to one or both of the two most popular ones, Gzip and Brotli.<\/strong><\/p>\n\n\n\n The two most common compression algorithms are Gzip and Brotli. Gzip is the oldest and most common of the two. It was written by Jean-loup Gailly and Mark Adler. The initial beta release was made in 1992. The first actual version, version 1.0, was released in early 1993. back in 1992 just as the web was coming online for most people. <\/p>\n\n\n\n Gzip was designed as an all-purpose compression library<\/strong>. The theories behind Gzip were based on the earlier compression algorithm, DEFLATE. <\/p>\n\n\n\n Because of its popularity – and the fact that it is very good at making files small – it is still<\/strong> widely used today <\/strong>both in different operating systems as well as a primary compression algorithm for web servers<\/a>. <\/p>\n\n\n\n Brotli was developed by Google employees Jyrki Alakuijala and Zolt\u00e1n Szabadka in 2013. Google was originally looking for a better way to compress WOT files which are web fonts. <\/p>\n\n\n\n Gzip was originally intended to compress files and has been adapted to compressing streams so it could work on the web. Brotli on the other hand, was designed from the beginning to compress streams<\/strong>. This makes it a better choice for web servers<\/strong> to compress content before streaming it to a browser.<\/p>\n\n\n\n In 2015, Google released the Brotli specification for HTTP<\/strong>. In addition to specifying how the browser should notify the server that it can decompress Brotli by sending a \u201cContent-Encoding: br\u201d<\/em> header, Google engineers also made other improvements to Brotli that made it even faster for compressing web content<\/strong>.<\/p>\n\n\n\n While they both have their origins in the LZ77 algorithm, Gzip was designed specifically to compress files<\/strong>. The library has been incorporated into a lot of different programs that need to compress files. The library was incorporated into web servers as compressing content started to be the norm. It was one of two compression algorithms specified in RFC 2616, the HTTPS 1.1 specification. While it wasn\u2019t specifically designed for streaming operations like web servers, it was adapted to it.<\/p>\n\n\n\n Brotli<\/strong>, on the other hand, was specifically designed for the web<\/strong>. Google recognized the need for a way to compress streams more efficiently so they designed Brotli.<\/p>\n\n\n\n Both algorithms do a good job at what they were designed to do. Gzip still continues to be used on the web because it is still better than nothing at all. However, as Brotli grows in popularity, more and more web servers are preferring Brotli over Gzip<\/strong>. Given the choice of the two, Brotli is the default many servers will use. It’s been the default choice on all SiteGround servers<\/a> for a while now.<\/p>\n\n\n\n Check the following video for more reference on the differences between Brotli and Gzip!<\/p>\n\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n<\/ul>\n\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n<\/ul>\n\n\n\n<\/span>What is Gzip Compression?<\/strong><\/span><\/h2>\n\n\n\n
<\/span>What is Brotli Compression?<\/strong><\/span><\/h2>\n\n\n\n
<\/span>What\u2019s The Difference Between Brotli and Gzip Compression?<\/strong><\/span><\/h2>\n\n\n\n