Compressing webpages to make them smaller is crucial to ensure fast webpage load times. Gzip and Brotli are the web’s two most used compression formats. A third contender, HTTP Deflate, has been around as long as Gzip, but it never caught on. Do you still need to support it on your websites and apps? or is it time to retire HTTP Deflate from the web platform?
Every major web browser and all sorts of other tools and apps send an Accept-Encoding: deflate, gzip header to every web server they connect to. The request header advertises to the server that the client support the listed compression formats (“encodings.”) Both HTTP Deflate and Gzip have been supported since HTTP version 1.1 back in 1999. Most modern web browsers also announce support for the newer Brotli (br) format.
The Gzip format is much more common than HTTP Deflate, despite their similar history. The 2020 Web Almanac analyzed more than 7,5 million website homepages to study compression trends. If found that only 0,015 % of servers returned an HTTP Deflate encoded response. Roughly 30 % of responses used Gzip, and about 10 % used the newer Brotli compression format.
It’s unclear if the surveyed sites just preferred HTTP Deflate or if they didn’t support Gzip and Brotli. It’s astonishing that a full 60 % of websites are served uncompressed. (Check. Your. Web server.)
The conclusion is clear: You don’t need to implementing and maintain HTTP Deflate in new software. Your time is much better spent on Gzip and Brotli. Most websites literally fail on the basics here. You can always fall back to sending an uncompressed response to clients that don’t support the other two methods.
Come to think of it, it’s high time that web browsers and web servers deprecated HTTP Deflate. It isn’t a failed technology, but it isn’t relevant anymore either. The format is rarely used and thereby poorly tested on clients and servers alike.
HTTP Deflate is slightly better compared to Gzip. It saves 12-bytes and slightly reduces processor load. It’s not a big difference, though. So, what’s wrong with HTTP Deflate and why did it fall so far behind Gzip?
In this article, I’ve called what the HTTP/1.1 specification refers to as “deflate” for “HTTP Deflate” instead. HTTP Deflate — or Zlib (RFC 1950) as the format is really called — and Gzip (RFC 1952) are wrappers for the Deflate (RFC 1951) compression format. The naming confusion obviously led to incompatible client and server implementations. Gzip is less ambiguous, and thus it became the safer compression format to use.
I can’t speak for the server-side of things, and I don’t know whether they return Zlib or “raw” Deflate. Web browsers, many HTTP libraries, and other client software have format detection logic. This lets them decompress either format variations using only a small computational overhead. However, it’s not worth the extra work.
The HTTP Deflate bubble burst over a decade ago, and Gzip won the Deflate-wrapper format war. It’s way past time to remove HTTP Deflate support from the web platform.
Update (): I just learned that WebPositive, the web browser in Haiku OS, stopped announcing support for Deflate in . It’ll still attempt to decode Deflate responses, however. It’s the first (and only) web browser to drop Deflate.