Looking at this latest test I am wondering if WebPageTest . org is not seeing the Brotli compression correctly from our CDN77 service and that is why we get poor grades Compress Images and Cache static content.
Does anybody have idea if this true?
See test here: http://www.webpagetest.org/result/160510_MN_24BA/1/performance_optimization/#compress_images
I’ll let someone with dev experience in WebPageTest reply to anything specific to WebPageTest, but given how HTTP works, I’m not sure that’s your problem.
The client browser only knows that the data it requested was compressed based on the information provided in the server response.
For example, take one of the requests in your test: https://1671625845.rsc.cdn77.org/core/getthumb?user=2637&site=3505&w=150&h=150&mode=crop&file=uploaded%2Fimages%2Fcake%20pans%2F2105-0801.jpg&overlay=out_of_stock.png
I can see that the client browser specifies in its request header to the server that it can accept compressed data with accept-encoding.
Request Headers:
:method: GET
:authority: 1671625845.rsc.cdn77.org
:scheme: https
:path: /core/getthumb?user=2637&site=3505&w=150&h=150&mode=crop&file=uploaded%2Fimages%2Fcake%20pans%2F2105-0801.jpg&overlay=out_of_stock.png
accept: image/webp,image/,/*;q=0.8
user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36 PTST/276
referer: https://shopbakersnook.com/
accept-encoding: gzip, deflate, sdch
accept-language: en-US,en;q=0.8
If the server has compressed the data and wants to tell the browser it did so, it should do so with the content-encoding header field. This field does not exist in the response header, so the browser believes the data was not compressed.
Response Headers:
:status: 200
date: Tue, 10 May 2016 20:40:49 GMT
content-type: image/jpeg
content-length: 32452
cache-control: public, max-age=1209600
content-transfer-encoding: binary
etag: W/“PSA-wwL4K8YglR”
expires: Tue, 24 May 2016 13:57:47 GMT
last-modified: Fri, 01 Apr 2016 20:01:08 GMT
strict-transport-security: max-age=0;
server: CDN77-Turbo
x-edge-ip: 185.59.223.20
x-edge-location: newyorkUSNY
x-cache: HIT
x-age: 23287
If you look at other requests to say shopbakersnook.com, you should find content-encoding in the header responses.
Also, to my understanding, Google developed the Brotli compression algorithm, so I’d be surprised that their own Chrome browser doesn’t support it.
There may very well be an issue with WebPageTest, but I think you should also take a look at the compression at the CDN as well to ensure that this is occurring. One way I would do that would be to compare the actual size of an image file you know of, and look at the content-length that the CDN sends in the response header. If it’s compressed, the actual size should be greater than the content-length.
Hope that helps.
WPT does not currently decode brotli but that is unrelated to theissues you are seeing (which are not false positives). Looks like the image thumbnail service/code you are using (getthumb) is not compressing the thumbnails at low enough of a quality setting (it must be using 90-05). Generally 75 is safe but WPT checks against quality 85 just to be extra conservative.
The static asset caching also has nothing to do with compression. The expires lifetime on several of the images have a fairly short cache lifetime (WPT requires 30 days minimum for static objects).
