Chrome compresses web pages using shared dictionaries: what it means

Chrome compresses web pages using shared dictionaries: what it means

Communications between Web servers and browsers, when “browsing” online, involve the automatic activation and use of various forms of data compression. For a long time, the well-known gzip algorithm was used to manage “talks” between client and server (and vice versa), reducing the “weight” of the information exchanged. From 2016 onwards, however, Google has decided to introduce in Chrome the algorithm Brothlycapable of ensuring even higher compression rates.

With the release of Chrome 123, now on the starting blocks, Google has planned the adoption of ZStandarda tool that uses a “shared dictionary” mechanism to further improve the Compression ratio. Google explains that these new approaches allow for compression that in some cases even exceeds 90%.

What are dictionaries and how do they work for data compression on the Web

In the case of shared dictionaries, compression identifies redundant sequences and uses them to create a smaller output. Let’s imagine a site uses Angular 1.7.9. Angular is an open source framework developed by Google for building dynamic, single-page web applications. It uses the TypeScript language and offers a robust structure for managing the frontendfacilitating the development, testing and maintenance of complex applications.

Here, the compression algorithms used in Chrome, which work very well for static resources such as HTML, JavaScript and CSS, compress the Angular framework to around 70%. If you upgrade to Angular 1.8.3, a custom dictionary it can leverage the previous version and compress the new version to 98%. The fact is that if you use a certain dictionary to compress a resource, you need the same dictionary to decompress it. Chrome addresses this challenge with shared dictionaries.

How shared dictionaries will work in future versions of Chrome

Browsers communicate supported compression algorithms through a header called Accept-Encoding. Chrome indicates support for gzip, Brotli and ZStandard. The server, if it recognizes the dictionary, can respond with a compressed resource using the dictionary in question.

In the case of a compression method that does not use a shared dictionary, the amount of data is “lightened” by replacing the same information with data that certifies that that portion of code has already appeared previously. It’s evident in the image below, taken from a recent demonstration by Google software engineers:

Web data compression dictionary

By using a shared dictionary, you can prepare recurring parts in advance and compress data extremely effectively right from the start.

Chrome compression, shared dictionary

Website developers can also prepare and declare the use of a dictionary, in the case of static resources. As Google explains, just use the header Use-As-Dictionary: it must contain a reference to the resource containing the dictionary. For example:

Use-As-Dictionary: match="/dist/styles.*.css"

In the case of dynamic resources, it is instead necessary to load the dictionary on the client and then use it later. “Hope in these cases“, Google notes, “is that the website receives enough traffic to pay for the cost of the dictionary over a large number of visits“.

The first step is to specify the dictionary location via an element <link> in the HTML code of the page:

<link rel="dictionary" href="/dictionary.dat">

If you wanted to get ahead of the curve and immediately try data compression via dictionary, on the client side – on Chrome – simply type chrome://flags/#enable-compression-dictionary-transport in the address bar, click on Enabled the setting Compression dictionary transport then restart your browser.

Leave a Reply

Your email address will not be published. Required fields are marked *