1.12.34.1 brotli ¿expected behavior?

[Longinos]

I use nginx with brotli module. In NPS version 1.11.33.4 optimized resources are served with content-encoding: br header, but in the new version are served with content-encoding: gzip header, resources excluded to NPS maintain the br header. Is this expected results?

[Steve Hill]

It sounds like NPS is re-compressing the resources to gzip. Can you confirm that the content-encoding is actually correct?

Did you change your configuration when you upgraded to 1.12? There's nothing that immediately makes me think this should have changed.

On Tue, Dec 13, 2016 at 8:25 AM, Longinos <longinos.int...@gmail.com> wrote:

I use nginx with brotli module. In NPS version 1.11.33.4 optimized resources are served with content-encoding: br header, but in the new version are served with content-encoding: gzip header, resources excluded to NPS maintain the br header. Is this expected results?

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.

[Longinos]

No changes in any config file, only changed nginx version from 1.11.6 to 1.11.7 and NPS from 1.11.33.4 to 1.12.34.1.
Files excluded from NPS with pagespeed Disallow have the br conten-encoding. Seems that only rewriten subresources have the content-encoding changed.

[Hans van Eijsden]

I can confirm the issue, rewritten resources are served with gzip in stead of br, as you can see at https://www.weblogzwolle.nl/.

The Brotli module I use is https://github.com/cloudflare/ngx_brotli_module.git (so, not the older Google one but the Cloudflare module). And you?

-Hans

Op maandag 19 december 2016 21:51:36 UTC+1 schreef Longinos:

[Joshua Marantz]

I could see it working either way, and arguments for both of them.  I confess I haven't dived into what it actually does.

Most likely, serving the resources with "br" they will be smaller than when served with "gzip".  However, NPS will cached gzipped versions of its optimized results in its server-side cache, and will not have to be recompressed on each request.

So if the Cloudflare module takes the PageSpeed gzipped responses, unzips them, brotli-encodes them, and then puts them in another cache (maybe on the Cloudflare CDN), that would be fine.  The server will have done a little extra work every time the resource changes, but on a warm CDN cache that will be fine.  The PageSpeed optimized results will be cacheable for a year, so it would be worth it.

However, if the brotli-encoded results are not cached, I think on-the-fly Brotli re-encoding of static assets would be bad for performance: both the load-time of the CPU running nginx, and the latency seen by the end user.  If the gzip-decode & brotli-encode has to happen on *every* request, it would probably add more to the latency than the smaller encoding format would save in transmit time.

I looked at https://github.com/cloudflare/ngx_brotli_module/blob/master/ngx_http_brotli_filter_module.c and while I didn't read all the code, the word 'cache' does not appear in it.  Of course the Cloudflare CDN caching would still help, as long as it's configured to incorporate the Accept-Encoding request-header into its cache lookup logic.

-Josh

[Longinos]

HI Hans van Eijsden

I ´m using the google module from https://github.com/google/ngx_brotli

Hi Joshua Marantz

I don´t use cloudflare but time to page load is aprox. the same, measured with https://www.webpagetest.org/ on bot cases with 1.11.33.4 and 1.12.33.1.
This issue is not a big concern, all most for me, but is a change in the behavior of the module and, I think, the NPS team must have knowledge of it.
This module is a great job and I think that users should contrbute with our feed-back.

This change is perhaps for using redis db instead of memcached?
As soon I can I revert the use of redis and return to memcached, see whats happends and post here.

[Longinos]

Using memcached don´t change this issue

[Steve Hill]

I guess what's happening is that ngx_pagespeed is producing gzipped output and ngx_brotli won't re-compress that to gzip, which is probably right. I'm not sure why that would have changed when you upgraded to 1.12, though. Did you happen to upgrade ngx_brotli at the same time?

If you really want brotli compression, you probably need to disable gzip, which we enable by default. What happens if you add "gzip off" to your config? You might also need to set 'pagespeed HttpCacheCompressionLevel 0'.

It's worth noting that using ngx_brotli may use significantly more CPU as NPS can gzip resources to disk and serve the pre-compressed version:

https://developers.google.com/speed/pagespeed/module/system#gzip_cache

On Tue, Dec 20, 2016 at 1:01 PM, Longinos <longinos.int...@gmail.com> wrote:

Using memcached don´t change this issue

[Longinos]

Hi Steve
No brotli module not was changed, only nginx and NPS. As soon I can try to disable gzip on nginx and HttpCacheCompressionLevel 0, first separated and late both. I post here results.

[Longinos]

pagespeed HttpCacheCompressionLevel 0;

This do the trick. optimized resources are served with content-type br.

[Longinos]

But the reverse is that if you set pagespeed HttpCacheCompressionLevel 0; then no Vary: Accept-Encoding header

[Longinos]

I found a workaround that post here for share it.
set pagespeed HttpCacheCompressionLevel 0; and enable gzip_vary on; this make resources be served by brotli and have the vary: acept-encoding

[Joshua Marantz]

Excellent; that sounds like a reasonable workaround.

Happy Holidays!

-Josh

On Fri, Dec 23, 2016 at 2:31 PM, Longinos <longinos.int...@gmail.com> wrote:

I found a workaround that post here for share it.
set pagespeed HttpCacheCompressionLevel 0; and enable gzip_vary on; this make resources be served by brotli and have the vary: acept-encoding

--