False Positive?
|
05-11-2016, 06:48 AM
Post: #1
|
|||
|
|||
False Positive?
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...ess_images |
|||
05-11-2016, 07:30 AM
Post: #2
|
|||
|
|||
RE: False Positive?
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/ge..._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. Jean Tunis Principal Consultant, RootPerformance Consulting http://www.websiteevals.com Author, Analyzing HTTP http://www.analyzinghttp.com |
|||
05-11-2016, 09:43 AM
Post: #3
|
|||
|
|||
RE: False Positive?
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). |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)