Improving Google Search with Compression Dictionaries

Carlos Mateo Muñoz

Barry Pollard

Published: May 14, 2025

Compression Dictionary Transport is a new standard that allows us to compress repeated content across requests and was released in Chrome 130 in late 2024. Google Search has adopted this new technology and seen huge improvements.

The opportunity

There's a lot of duplication in the web pages we visit. Many pages on the same website consist of large parts of the same code—whether HTML, CSS, or JavaScript with only the content in between all this code changing. While each result is a unique combination of hundreds of features resulting in totally unique content, there is still a lot of commonality in the code sent to the browser to produce them.

Visually, most Search result pages are somewhat similar no matter what the search term entered is: At the top we have the Google logo, the search bar, some controls. In the middle we have some tabs for the search type, and then a list of search results on the left interspaced with various widgets to help the user, and additional context on the right with "about" panels:

Finally at the bottom, we have the pagination options and the standard footer. This is just what's visually available—behind the scenes there is a lot of code (HTML, CSS, and JavaScript) to produce this page. Much of this code is inlined directly into the HTML of the page as a performance optimization. While this does allow for a quicker page load, it comes with the cost of not sharing that code between different results pages—like an externally cached resource would allow.

Compression on the web

Compression is a heavily used technology for the web. Compressing resources with gzip, or newer algorithms like Brotli or Zstandard, allows repetition within a file to be avoided with lossless compression to pack all the information as tightly as possible on the server before sending. The browser can then unpack the compressed bytes to restore the original content. For images, lossy compression offers similar benefits by removing extra bytes that may not be perceptibly different to users.

Until recently, compression on the web has been limited to compression within resources. It was not possible to compress across different resources, and certainly not across different pages. This has long been recognized as a limitation web engineers sought to fix.

Compression Dictionary Transport to the rescue!

Compression Dictionary Transport is a new standard that allows compression across resources with the use of shared "dictionaries" that allow common series of bytes to be replaced with references from that shared dictionary.

Modern compression algorithms like Brotli and Zstandard support the use of dictionaries of common terms that allows for greater compression by replacing those terms with a smaller reference to the dictionary. Brotli even ships with a built-in dictionary of common web terms. Compression Dictionary Transport builds upon this by providing ways for the server and browser to share custom dictionaries.

Custom dictionaries can either be a resource that is already used on the site. For example, you can use app.v1.js as a dictionary when downloading app.v2.js to basically only download the difference (often known as "delta-compression"). Alternatively, a separate dictionary resource can be specified with a <link rel="compression-dictionary"> tag (or equivalent Link HTTP header).

This can dramatically reduce the download size of resources with a lot of shared content or code, such as the Search results pages mentioned previously.

Google Search's use of compression dictionaries

The Google Search team is continually looking to improve the performance of Search. They were an early adopter of compression dictionaries as they saw the potential of this technology.

Search uses shared Brotli compression for their result pages with a separate dictionary file built from a representative sample of search results. A robust automated pipeline ensures the dictionary remains fresh, keeping pace with frequently changing SRP content that is released multiple times a day. You can use DevTools to see exactly how this works.

When a client first loads a search results page, the server provides a link to the dictionary using the Link: HTTP header with a type of rel=compression-dictionary:

If the client supports Brotli dictionary compression, but hasn't yet cached the shared dictionary, the browser downloads this dictionary during idle time. The dictionary response includes the Use-As-Dictionary response header that tells the browser what resources it can use this dictionary for:

The dictionary will use standard cache-control semantics and will be available for any resources matching the rules defined in that header—in this example pages started with /search.

For future search result page loads, the browser can tell the server it has a dictionary using the Available-Dictionary HTTP request header. Reloading the page shows this in action:

With the Preserve log checkbox enabled and filtering, we can compare the two responses:

In this example, the first request is the full 107 kB response and uses Brotli (br) compression, while the second reload request is nearly half the size at 60 kB and uses Dictionary-Compressed Brotli (dcb) compression, resulting in a faster download time.

In Chrome, you can view the chrome://net-internals/#sharedDictionary page to view Shared Dictionaries and clear them if you want to repeat this example from the beginning.

The results

The change was rolled out to Search users in spring of 2025, initially to Chrome users. This reduced the average size of the HTML payload across all Chrome users by 23% compared to standard Brotli compression. This overall average includes both non-dictionary-compressed results (for example first-time users without a dictionary), and dictionary-compressed search results. For dictionary-compressed results the savings are even larger—as we saw with the near 50% improvement in the previous example we looked at.

This resulted in a Largest Contentful Paint (LCP) improvement of 1.7% overall, and up to 9% on high latency networks. This may seem small, but Google Search is a hyper-optimized site, so gains of this magnitude are huge. Other sites may see even larger improvements with this technology.

Try it on your site!

Compression Dictionary Transport is ready to use now in all Chromium-based browsers (Chrome, Edge, Opera and so forth). It's a progressive enhancement that will be ignored by non-supporting browsers, but as more browsers support this, they can benefit too.

The challenges this technology addresses are far from specific to Google Search. Many sites can benefit from Compression Dictionary Transport, whether with a separate dictionary like Search used, or by using an existing resource as the dictionary (like the previous version of an app when rolling out a new version).

Check out the guide on MDN for more details on how this technology works and how you can implement it on your site.

This does require some setup on your server or build process to create dictionary-based compressed resources and serve them as appropriate—but the results can be seriously impressive in terms of performance!