----
Understanding Brotli's Potential
// The Akamai Blog
When it comes to compression on the web, GZIP reigns supreme. In the 18 years since GZIP was first supported by browsers, other compression methods have been introduced but none have matched GZIP's combination of speed, support and results.
Brotli, the compression algorithm Google released as open-source back in September, may soon change that. Chrome (version 49, due in early to mid March) will be shipping with Brotli support, and Firefox (version 44) already has it. Particularly given Chrome's significant reach on the Android platform, this means that Brotli support will go from zero to sixty in no time--bringing reduced file sizes along with it.
To get a better understanding of just how big those savings could be, and what the trade-offs are, we ran a few independent experiments.
Testing the Top 1000 URL's According to HTTP Archive
For the first set we took a list of the top 1000 URL's on the web (pulling the list from HTTP Archive) and downloaded the HTML for each page, as well as all JavaScript and CSS assets. For each asset, we recorded the original weight. We then recorded the weight of the asset with GZIP applied, as well as the weight of the asset with Brotli applied. We kept the quality level of each to the default provided on each tool. We did not unminify any assets, but we did uncompress those who were pre-compressed with GZIP.
HTML
| Median GZIP Savings | 78% |
| Median Brotli Savings | 82% |
| Brotli Improvement over GZIP, Median | 21% |
| Brotli Improvement over GZIP, 90th percentile | 39% |
Javascript
| Median GZIP Savings | 63% |
| Median Brotli Savings | 68% |
| Brotli Improvement over GZIP, Median | 14% |
| Brotli Improvement over GZIP, 90th percentile | 26% |
CSS
| Median GZIP Savings | 79% |
| Median Brotli Savings | 82% |
| Brotli Improvement over GZIP, Median | 17% |
| Brotli Improvement over GZIP, 90th percentile | 27% |
The results are really promising! All three types of resources--HTML, JS and CSS--saw significant savings from using Brotli instead of GZIP.
NOT SO FAST
We can't judge a compression algorithm purely by the amount of bytes saved, however. If we could, GZIP would've been dethroned long ago. Another major consideration is the compression speed: how long does it take to perform the actual compression.
There's a fair amount of chatter about Brotli being much slower than GZIP. And on the surface it is. Run a benchmark on your machine using the default settings of GZIP versus the default settings of Brotli and you'll see the Brotli is much, much slower.
But the key phrase there is "default settings".
GZIP has nine quality levels. If you run GZIP using a quality setting of "1", you won't get a lot of file savings, but the compression will occur incredibly quickly. If you run GZIP using a quality setting of "9", you'll maximize your file savings, but the process will be quite slow. GZIP uses a default setting of "6": it provides a nice blend of file savings and compression speeds.
Brotli has eleven quality levels. Just like GZIP, a quality of "1" is very fast but less effective, whereas a quality setting of "11" is very slow but provides big savings in file size. While GZIP's default setting has been chosen to provide a balance of speed and compression; Brotli's default setting has not. Out of the box Brotli runs on a setting of "11" meaning you get a huge savings in data, but a much slower compression speed.
By playing around with the quality setting on Brotli, you can find a much safer balance.
To get a better idea of where that magic setting is, we looked at the HTML for the top 1000 sites.
We compressed each file individually at different settings of Brotli and GZIP to see what the results would be. For each setting, we ran the compression 20 times and recorded the median speed. The tests were run on a MacBook Air to make it easier to see the impact the settings had on the compression rate. These compression speeds are going to be slower than if you ran them on a more powerful machine. The results (sorted by throughput) are below.
We've highlighted GZIP's default settings in bold, as well as the Brotli setting that had a comparable speed.
| Compression Method | Savings | Throughput, Median | Difference in Speed from GZIP Default | Difference in Size from GZIP Default |
| GZIP (1) | 78.4% | 88.2 MB/s | 128% | -19% |
| GZIP (2) | 79.1% | 84.6 MB/s | 119% | -15% |
| Brotli (1) | 80.9% | 83.2 MB/s | 115% | -5% |
| GZIP (3) | 79.6% | 76.5 MB/s | 98% | -12% |
| Brotli (2) | 82.5% | 71.5 MB/s | 85% | 4% |
| Brotli (3) | 82.7% | 66.1 MB/s | 71% | 5% |
| GZIP (4) | 80.8% | 53.4 MB/s | 38% | -5% |
| Brotli (4) | 83.4% | 47.0 MB/s | 21% | 9% |
| GZIP (5) | 81.4% | 45.6 MB/s | 18% | -2% |
| GZIP (6) | 81.8% | 38.7 MB/s | 0% | 0% |
| GZIP (7) | 81.8% | 31.0 MB/s | -20% | 0% |
| Brotli (5) | 84.5% | 26.4 MB/s | -32% | 15% |
| GZIP (8) | 81.9% | 23.9 MB/s | -38% | 1% |
| GZIP (9) | 81.9% | 20.9 MB/s | -46% | 1% |
| Brotli (6) | 84.8% | 17.1 MB/s | -56% | 16% |
| Brotli (7) | 85.2% | 10.4 MB/s | -73% | 19% |
| Brotli (8) | 85.3% | 8.0 MB/s | -79% | 19% |
| Brotli (9) | 85.4% | 5.8 MB/s | -85% | 20% |
| Brotli (10) | 86.8% | 2.7 MB/s | -93% | 27% |
| Brotli (11) | 86.8% | 2.6 MB/s | -93% | 27% |
There were a few interesting takeaways from the speed test. The first, is that GZIP certainly plateaus in terms of improvement around a quality setting of "6". It's unsurprising then that "6" was chosen as the default.
Brotli has an early peak around a quality setting of "7", but then once you hit "10" it leaps forward again. This leap also corresponds with a significant decrease in speed. Changing the quality setting from "10" to "11" provides no improvement here, nor was improvement seen when testing a handful of individual files to verify the results.
As you can see from the results, if you tweak the Brotli settings a little bit, the compression speeds can actually surpass the speeds of GZIP while still providing some significant savings. Based on these 1000 HTML files, running Brotli at a setting of "4" would not only save more bytes than GZIP's default setting, but it would compress about 21 percent faster as well. That same setting--"4"--showed up consistently as the break-even point when tested on individual files as well.
This is great news as it means that if the defaults are carefully tuned, Brotli could be a suitable replacement for GZIP compression of both static and dynamic assets.
Testing Akamai URL's
In another test, we took 100 domains on the Akamai platform and downloaded the HTML, CSS, JS, XML and JSON files. For each file, we applied GZIP at its highest level of compression (9), as well as Brotli at its highest level (11). The improvements were similar to our prior experiment with the median showing an improvement of 16% and the 90th percentile showing an improvement of 27%.
| Percentiles | 50% | 60% | 70% | 80% | 90% | 95% | 99% |
| Brotli improvement vs GZIP | 17% | 18% | 19% | 22% | 27% | 33% | 58% |
In this experiment, we decided to remove all files smaller than 1KB to see the impact the size of the file had on the compression results. After doing this, Brotli still showed an improvement over GZIP, but it was slightly less pronounced.
| Percentiles | 50% | 60% | 70% | 80% | 90% | 95% | 99% |
| Brotli improvement vs GZIP | 16% | 17% | 18% | 20% | 23% | 26% | 31% |
While it's clear that the smallest files are the ones seeing the highest benefit from Brotli, the impact is still very noticeable.
And your point is?
Brotli isn't quite the revolutionary jump forward that a technology such as HTTP/2 is, but we should welcome every chance to save bytes on the wire. As far as website owners are concerned, it's virtually a flip of the switch that can result in anywhere from 14-39 percent file savings on text-based assets when running full-blast.
Though Brotli slows down the higher the compression setting, it's entirely possible to trade-in some of those bytes for a faster compression setting. If you're going to replace GZIP for compression of dynamic assets, a Brotli quality of "4" is a good place to start. If you're running it ahead of time and queuing up those resources for a later request, then run it full blast and watch the bytes fade away.
Given that images dominate the weight of pages today, you shouldn't expect Brotli to be a magical fix-all for your performance woes. Still, 14 percent savings on text-based assets is nothing to sneeze at--particularly given that it is these text-based assets that stand in the way of the critical path. As sites continue to steadily increase in weight and complexity, any improvement is one worth considering.
----
0 件のコメント:
コメントを投稿