1412891 - Use brotli compression on MDN

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Performance, enhancement, P1)

Description

[Florian Scholz (Open Web Docs)]

Brotli beats gzip in compression ratio and decompression speed.
Browsers not supporting brotli should fallback to gzip.

https://en.wikipedia.org/wiki/Brotli
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding
https://github.com/illagrenan/django-brotli

Comment 1

[Anthony Maton [:anthony]]

I believe that if we want to use the middleware 'django-brotli', we will need to apply the same workaround as in https://github.com/mozilla/kuma/commit/3ac345b97aa439d3d778bf82a3a4fdbb58dec9f2#diff-313b818106ff2f77d2c6ffc02643cf5fR215

Except for that, it doesn't seem extremely complicated. I will give it a try.

Comment 2

[Anthony Maton [:anthony]]

Using whitenoise is also an option since we already use it in Kuma.

Their documentation regarding brotli seems fairly straightforward: http://whitenoise.evans.io/en/stable/django.html#brotli-compression though there is an issue on Github suggesting to use the binding provided by Google which is driving brotli forward 
https://github.com/evansd/whitenoise/issues/154 so I think it would be more interesting to use those.
I checked and they are compatible interfaces.

There is still need to check if whitenoise is playing nicely with our way of managing eTag or not.

Comment 3

[Anthony Maton [:anthony]]

See https://github.com/mozilla/kuma/pull/4686

Comment 4

[[github robot]]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/d2c454cd3f0395d5e225d8bdc33c854d75d723fe
bug 1412891: Test compression middleware conflicts

In Kuma we use both Brotli and GZip as compression algorithm depending
on browser support.

Double compression is prevented in the middleware, which is tested with
this commit.

https://github.com/mozilla/kuma/commit/44b1a7d23a2079cade9952ac5c6c5bd8c5d8a589
bug 1412891: Update comments, Vary header patching

* Format so that lines of code are less than 80 characters.
* Google's brotli supports streaming, but it is complicated, so skip it
  and let GZipMiddleware do the hard part.
* Don't add Accept-Encoding to the Vary header unless the content is
  going to be Brotli-compressed

https://github.com/mozilla/kuma/commit/da6f8320bcd4df041560bc568bde95ba5817ea0a
bug 1412891: Semi-alphabetize requirements

https://github.com/mozilla/kuma/commit/e797df4b0c582300842f09536542db4fcadc0747
Merge pull request #4686 from MatonAnthony/1412891

bug 1412891: Enable brotli on MDN

Comment 5

[John Whitlock [:jwhitlock]]

Pushed to production and staging. Server response time went from about 75 ms (50 ms in Python) to 110 - 125 ms (100 ms in Python), which is probably due to Brotli compression of each response. We should look into end-user page load time in Google Analytics in 3-7 days, and see if this has a positive or negative effect.

Comment 6

[John Whitlock [:jwhitlock]]

I think we need to disable Brotli until we have a CDN that supports it. It doesn't make sense to compress with Brotli unless the content will be cached, and it makes more sense to perform compression on the CDN.

New Relic shows that the average time spent in Python doubled from about 50 ms to 100 ms after this change. There is also appears to be an increase in database time, but it is unclear why this would be related to the Brotli change.

Google Analytics shows that generating Brotli-compressed content on each page request is slowing the site down:

* A 6% improvement in average page download time, from 0.10 to 0.10 seconds (less than 0.01s improvement)
* A 23% decline in average server response time, from 0.46 seconds to 0.56 (0.1s worse)

Further, it appears that CloudFront (used for code samples and user attachments) is not serving Brotli-compressed content, and will not do it. The default setting is that CloudFront requests uncompressed files, and gzip compresses some file types. It allows you to compress files with gzip in the origin server for unsupported filetypes. It does not permit other compression types, such as Brotli. This means we'll lose Brotli anyway when we switch to CloudFront for the HTML content, and we may remove the gzip middleware as well and rely on the CDN to compress content.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html#compressed-content-custom-origin

Comment 7

[John Whitlock [:jwhitlock]]

Attachment: new-relic-brotli.png

New Relic shows the impact of adding the Brotli middleware on time spent in Python and in the Database.

Comment 8

[Anthony Maton [:anthony]]

I'm not sure it's the CDN job to do the compression for us and CloudFront is not serving Brotli.

If we decide to go the way where the CDN makes the compression, the Brotli middleware become indeed irrelevant.

Regarding the performance tradeoff it could likely be compensated by using Brotli at compression level 5 or 6 and not 11.
I shouldn't have let the default settings.

Do you want me to provide a patch that remove the Brotli middleware? I don't propose to simply revert the PR since I also added a test to the GZipMiddleware in it.

Comment 9

[John Whitlock [:jwhitlock]]

Some possible next steps:

* Try a different compression level, run it for 4-7 days to see the effect.
* Remove the middleware from the settings but leave it in the code for a while
* Remove the code, tests, and library

I'd merge a PR for any of these, if you have time to write it.

Comment 10

[Anthony Maton [:anthony]]

I would be interested by trying the first proposal with a brotli settings at 5 or 6.
And if the effect are not those expected to go with the third proposal.

I believe that proposal 2 could end up with us forgetting it exists while considering how simple the code is, reimplementing it based on the PR would be very easy.

Comment 11

[[github robot]]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/82f17ca2646766f20781d92e0b812e98b4468c42
bug 1412891: Adjust Brotli compression level

The current settings for Brotli compression level is too high and it's
increasing our average page load time as a side effect.

This patch put the compression level at a more reasonnable level to
lower the tradeoff.

https://github.com/mozilla/kuma/commit/6be8bc24d6fa97d601c7f07ab34faea66d45ca8e
Merge pull request #4712 from MatonAnthony/1412891-fine-tuning

bug 1412891: Adjust Brotli compression level

Comment 12

[John Whitlock [:jwhitlock]]

Attachment: new-relic-brotli-5.png

With compression level 5, the performance is back to before Brotli was added.  According to this blog post, the compression is comparable to gzip 9:

https://samsaffron.com/archive/2016/06/15/the-current-state-of-brotli-compression

We will still probably remove gzip and br middlewares when we place MDN behind a CloudFront CDN.