Add gzip and expires to nginx server config. #5700
Conversation
|
Hi, thanks for your contribution! |
|
LGTM! Just in case, @aaronkvanmeerten @damencho thoughts? |
|
As for the expires headers, not all content has a version string appended (take watermark.png for example). I haven't checked. but iirc browsers only send an If-Match for an etag when a cache expires with Cache-Control: public. Landing this would mean changing the watermark would take at least 30 days to show up for all clients. No objection to the gzip part, perhaps we can land just that part now? |
|
Yes, the gzip part seems ok. Can you leave only that one. Thanks |
Per discussion, expiration seems likely to cause more confusion than it solves. Add gzip_vary to prevent content caches from caching un-compressed versions of the content and confusing browsers.
|
Ok, gzip left, expires headers removed. I can open a separate tracking issue for content caching, as I think it would be useful, but given the bandwidth of videoconferencing, probably not a huge savings. Current change just adds gzip to nginx config. |
* Add gzip and expiration to nginx server config. * Add application/json to gzip_types line to cover translations. * Add gzip_vary for content caches, remove expires section. Per discussion, expiration seems likely to cause more confusion than it solves. Add gzip_vary to prevent content caches from caching un-compressed versions of the content and confusing browsers.
luixxiul
added
config
The provided nginx configs do not enable gzip by default, nor do they enable caching of the content. This pull request enables both gzip and content caching, via the expires header.
As the content has a version string appended, it should be safe to cache the content for longer periods of time, though the etag field should cover content changes as well. I'm flexible on the content caching part of this, if people have strong opinions there.
However, the gzip option changes the main page load from 4.6MB of content to 2.0MB of content - which makes a difference on low bandwidth connections, for minimal server CPU. The compression applies for meeting resources as well, and I see no downsides for enabling compression in the default configuration.
I've not added Apache config changes, as experimentally Apache has gzip enabled by default (but no expires headers - though mod_expires isn't enabled by default, so enabling caching headers would require playing with the enabled modules). As Apache is a second choice for servers, I don't think the change to enable mod_expires and then enable caching is worth the effort, although I could be convinced.
I've signed the contribution agreement document, you should be able to find that under my email address.