Conventional wisdom for performance optimization says that you should only enable HTTP content negotiated compression for plain text data formats and leave it off for binary data formats. Many binary image formats natively support compression so there would be little gained from compression them again. However, there are a number of exceptions to this rule and one of them is the ubiquitous favicon.ico file.
A few weeks ago I wrote about image metadata in the Extensible Metadata Platform (XMP) format and mentioned that images with XMP metadata can benefit from enabling HTTP negotiated compression. That one was a bit of a niche optimization for sure, so let’s look at a scenario so common that it affects just about every website out there.
The ICO file format, which folks may recognize from the standard /favicon.ico file found on pretty much every website (statistically speaking), can contain multiple size and color representation of an icon. You can enable compression for each of these representations in the file individually but software support is lacking.
You’ll also get a much better compression ratio when compressing the entire file as the different size representations may have a lot of data in common. The standard HTTP content negotiation mechanism is perfectly suited to handle compression for favicons as they’re being delivered over the pipes.
For example, Ctrl blog’s favicon.ico file contains the same icon at four different resolutions and totals 32 KiB uncompressed, 2,8 KiB with Gzip compression, and 2,4 KiB with Brotli compression. That’s a whooping 92,5 % reduction in file size and 90 % reduction in IP packets with Brotli compression!
The HTTP Archive dataset of favicons from 4 million websites crawled from desktop devices on shows that 73,5 % of all favicons are offered without any compression with an average file size of 10,5 KiB, 21,5 % are offered with Gzip compression at an average file size of 4 KiB, and 5 % offer Brotli compression at an average file size of 3 KiB.
Compressing your favicons is an optimization well worth making considering that it benefits practically every visitor to your website.
You can enable favicon compression in the Apache HTTP Server by including the two common media types used for favicons in the BROTLI_COMPRESS (when supported) and DEFLATE output buffer chains. Locate and adjust these filter chains in your configuration files and include the two media types as indicated below:
AddOutputFilterByType BROTLI_COMPRESS \
image/vnd.microsoft.icon image/x-icon
AddOutputFilterByType DEFLATE\
image/vnd.microsoft.icon image/x-iconHere is the same configuration again for the Nginx web server; optionally with the Brotli module installed:
brotli_types image/x-icon
image/vnd.microsoft.icon;
gzip_types image/x-icon
image/vnd.microsoft.icon;Make sure that you don’t overwrite your existing compression media type variables. You should just add the favicon media types in these sections of your server configuration file
I started looking into this after I learned that BunnyCDN, my Content Delivery Network (CDN) provider, were stripping away the optimizations I’ve done on the origin server and only deliver the uncompressed and bloated version of the favicon. They’ve begun compressing favicons properly after I contacted them about the issue.
However, their compression rates are still worse than what my origin server produces for both Brotli and Gzip variants. (I pre-compress using the Zopfli encoder instead of zlib.)
You should also verify that any caching layers between you and your visitors are HTTP standard compliant and don’t try to undo your optimizations.
Bonus content
66,82 % of favicons use the media type image/x-icon with image/vnd.microsoft.icon making up the rest. The latter is technically correct according to IANA, but the inventor of the file format — Microsoft — never submitted or ratified that media type. (The history here’s a bit complicated.) Which of the two media types you use makes no difference whatsoever to modern web browsers and other favicon consuming programs.