Prefer Brotli over Gzip
See original GitHub issueI see that Brotli was released in v4.1.0 - awesome, thanks for adding!
There’s one small issue. Chrome’s typical Accept-Encoding
header looks like this:
Accept-Encoding:gzip, deflate, sdch, br
It seems that koa-send interprets the order as a preference, and if it sees gzip, serves that first. That means if both .gz
and .br
files are available, the Brotli variants will never get sent:
In instances where more than one compression algorithm is accepted, I think it’d be better to automatically send the smallest file.
Issue Analytics
- State:
- Created 6 years ago
- Comments:10 (4 by maintainers)
Top Results From Across the Web
The Difference Between Brotli And GZIP ... - SiteGround
When Brotli was benchmarked against gzip, it was found that it compresses files better: ... Since Brotli was designed to compress streams on...
Read more >Brotli vs GZIP Compression: Which One is Better for WordPress?
The data is clear that Brotli offers a better compression ratio than GZIP. That is, it compresses your website “more” than GZIP. However, ......
Read more >Brotli Compression: A Fast Alternative to GZIP ... - Kinsta
Brotli has a better compression ratio (i.e. it produces smaller compressed files) across every level of compression. While GZIP does beat Brotli ...
Read more >Brotli VS GZIP || Which Of These Will Make Your Website ...
Here is my short answer to this: Brotli has proven to be a superior file compression algorithm to GZIP, and yes, it can...
Read more >Will Brotli Replace Gzip? - Bits and Pieces
According to research by CertSimple, Brotli compresses JavaScript files 14% smaller than Gzip, while HTML and CSS compression rates are 21% and ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@leebenson It happens. Anyways I looked into why chrome was not retrieving the brotli assets and it’s because brotli is https only. Here is the relevant chromium issue https://bugs.chromium.org/p/chromium/issues/detail?id=452335
I too have run into this issue last weekend. Wanting to get it to work I spent some time analysing the issue.
First of all as @nickhstr mentioned ‘deflate’ shouldn’t be included in
ctx.acceptEncodings()
. What is the point of checking whether deflate would be a better match when the library doesn’t provide an option for serving deflate compressed data. The problem is that chrome sendsbr
as the last entry of accepted encodings andctx.acceptEncodings()
seems to process the encodings in the order specified in the header (at least in the absense of priority specifications), thus always matchingdeflate
instead ofbr
.Changing this however totally broke my website: The
type()
function for setting the correct MIME-Type in the face of encryption only deals with.gz
, which means that.br
files will be served asapplication/octet-stream
, which chrome doesn’t like to much for html files (which it always tried to download) or css files (which weren’t applied correctly). Besides this problem the type function might also set the wrong MIME-Type when trying to serve actual .gz files, so the correct fix is to only remove the outer file extension when actually using the appropriate compression algorithm.Having fixed both of these issues it works correctly. If there is interest I could provide a patch for this, however there is still a small caveat I couldn’t fix: Fixing the MIME-Type leads to the Unittests for brotli failing with a timeout. I haven’t looked too far into it, but it seems that the testing framework doesn’t comprehend brotli responses for text content.