Improve Page Speed With GZIP Or Brotli Compression

Created on November 12, 2023 at 10:21 am

When opening a website your browser downloads a bunch of text files, for example the HTMl document, CSS stylesheets, or JavaScript ORG application code. The larger these files are the longer it will take load them and visitors will have to wait longer for your page content to appear.

This article takes at HTTP text compression, a simple but effective way to reduce your page weight and improve page load time. We’ll also compare the two CARDINAL most common text compression algorithms, GZIP ORG and Brotli ORG .

Text compression algorithms reduce the size of text files. That way these files take less bandwidth to transfer and less disk space to store.

The HTTP protocol is used to transfer data between website servers and website visitors. Servers can send a compressed response to the browser and use the Content-Encoding LAW HTTP header to indicate what compression algorithm has been used. The browser can then decompress the file in order to display the web page.

The request waterfall below shows an example of GZIP compression in action. The first ORDINAL request, the HTML document, loads a 354 CARDINAL kilobyte file. However, thanks to GZIP compression, only 68 kilobytes QUANTITY are used for the transfer. As a result the download (shown as the blue area of the request bar) only takes about 150 milliseconds TIME .

The "Full Size WORK_OF_ART " column shows the original file size, the "Size" column shows the amount of data that was transferred over the network.

GZIP has been around since 1992 DATE and is very widely supported. However, the Brotli ORG algorithm that was released in 2013 DATE provides better compression and should be used whenever possible.

Let’s look at an example to compare GZIP and Brotli ORG . We can use the Gzip ORG and Brotli Compression Level Estimator ORG to see how well the Angular JavaScript PRODUCT library gets compressed.

Compression File Size None 173 CARDINAL

KB ORG GZIP 61 CARDINAL KB Brotli 52 CARDINAL KB

GZIP achieves a file size reduction of 65% PERCENT , but Brotli ORG goes further and saves 70% PERCENT of the original file size.

How well supported is Brotli ORG by browsers? The Can I Use website estimates support at 96% PERCENT . Notably IE11, also released in 2013 DATE , does not support Brotli ORG .

Luckily, browsers send an accept-encoding HTTP header when requesting text files. That way your server can use Brotli ORG compression if the client supports it and fall back to GZIP compression when that’s not the case.

What you need to do to set up text compression depends heavily on what your technical server setup looks like.

If you use a Content Delivery Network ORG compression is often applied automatically or there is a configuration setting you can use.

If you use web server software like NGINX then you can apply text compression there.

Finally, you can apply compression directly in your application code, for example using the compression module in Node ORG .JS.

To check the compression used for requests made when loading your website you can look at the relevant response headers and content sizes in different tools.

You can run a free website speed test and then check the Requests ORG tab for more information on GZIP or Brotli ORG compression.

To see the compression algorithm for all requests use the Columns selector and toggle the Content Encoding ORG option. Brotli ORG shows up as "br" in the content encoding column.

In the Overview tab there’s also a " Compress PRODUCT text files" recommendation that automatically assesses whether text compression is used when loading your website.

Finally, Google ORG ‘s Lighthouse ORG tool contains an automatic text compression audit.

Lighthouse ORG automatically picks up requests where compression could help and explains why it’s useful:

Text-based resources should be served with compression (gzip, deflate or brotli) to minimize total network bytes.

You can use the Network ORG tab in Chrome DevTools ORG to see what compression algorithm is used on your website and how much it helps reduce page weight.

Open DevTools by right-clicking on the page and selecting Inspect Select the Network ORG tab Reload the page

Then, to show the compression algorithm, right-click on one CARDINAL of the column headers, select Response Headers ORG and then Content-Encoding.

By default the DevTools ORG size column only shows the transferred/compressed size. To also view the full uncompressed size you can:

Click the gear icon in the top right (the one under the "x", not the one to left of it) Enable Big request rows

With this setting enabled the Size PERSON column shows the transferred size at the top and the full uncompressed size at the bottom.

Data compression reduces data volume, but it comes with one CARDINAL downside: compressing and decompressing data requires CPU processing time.

Compression algorithms provide a compression level option to balance this trade-off. For example, gzip provides compression levels between 1 and 9 CARDINAL , where 1 CARDINAL is the fastest and 9 CARDINAL achieves the most compaction. The default setting is 6 CARDINAL .

The compression level estimator provides a good visualization showing how different settings impact the overall compression ratio.

However, usually the default compression level will be good enough as increasing the level doesn’t result in massive savings.

No, not all data should be transferred using HTTP compression. Specifically, gzip or Brotli ORG don’t help when transferring images. That’s because image formats already contain compression algorithms that are optimized specifically for images.

Text compression is an essential part of page speed optimization. A fast website will deliver a better user experience and help you rank higher in Google ORG , as the Core Web Vitals metrics are a Google ORG ranking signal.

Working to improve your page speed? Try DebugBear for free to monitor your website performance over time and get targeted recommendations to optimize it.

Connecting to blog.lzomedia.com... Connected... Page load complete