Why is ngx_brotli installed with Nginx but not use on the front end?

(Dan) #1

(Alan Tan) #2

What do you mean by not used on the front end?

(Dan) #3

Discourse sites still use gzip not br/brotli.
Front end I mean serving the website itself.

(Alan Tan) #4

In your app.yml file, you can add COMPRESS_BROTLI: 1 and see the magic happen.

(Jay Pfaffman) #5

Wait, what? I am almost certain that brotli is supposed to be enabled by default.

At some point in the recent past, I configured caddy in front of my multi site instance and this blog post is also suggests that. There was also a thread here (edit: here it is) in which @sam warned against sticking a stock nginx in front of Discourse because it would remove brotli.

I think that either @RoldanLT is wrong that brotli is not enabled or that there has been some kind of regression.

If it’s the case that app.myl needs a env variable to enable brotli, it should be added to standalone.yml, but I don’t think that’s the case.

I just looked at Meta and (unless I totally don’t know how to tell if brotli is being used, which is quite likely, but I asked google, and looked at @sam’s example), it seems that meta isn’t using brotli:

(Rafael dos Santos Silva) #7

It is:

We use brotli only for JS, since CSS will change live when you edit a theme, and brotli compression can be 10x slower than gzip.

I tested some sites, on DO, hosted by us, Jeff’ blog, installs by @pfaffman and all are using brotli.

(Jay Pfaffman) #8

But I just checked again and see content-encoding: br in all the places I’d expect it.

Further, I checked my site that’s got caddy-server reverse proxying sites to provide https and it too reports content-encoding: br.

Aha! That explains my earlier mistake.

It appears that nothing special is needed to enable brotli.

edit: No. Wait. Brotli requires https, right? The sites that I checked that don’t have brotli don’t have https.

(Dan) #9

Ah okay :).
Only enable for JS.


(Rafael dos Santos Silva) #10