False-positive cache-control records in report

Web Performance Discuss Test Results
1

I’m observing discrepancy in my reports specific to cache-control response headers.
Some resources are listed as “FAILED - (No max-age or expires)” in Cache section of the report, but I do see this header displayed in Details section for the given sub-request
Sample report:

Following resource is listed as “FAILED - (No max-age or expires)”:

FAILED - (No max-age or expires) - https://www.toyota.com/imgix/content/homepage/img/explore/ToyotaRacing.png?w=552&dpr=1&q=80&fm=jpg&lossless=false&fit=max&cs=strip&bg=fff&

But here is what is listed in the Details section:

[code]Request 11: https://www.toyota.com/imgix/content/homepage/img/explore/ToyotaRacing.png?w=552&dpr=1&q=80&fm=jpg&lossless=false&fit=max&cs=strip&bg=fff&
URL: https://www.toyota.com/imgix/content/homepage/img/explore/ToyotaRacing.png?w=552&dpr=1&q=80&fm=jpg&lossless=false&fit=max&cs=strip&bg=fff&
Host: www.toyota.com
IP: 13.32.250.125
Error/Status Code: 200
Priority: Low
Protocol: HTTP/2
HTTP/2 Stream: 21, weight 147, depends on 19, EXCLUSIVE
Initiated By: https://www.toyota.com/?removeEnsighten=true line 2202
Client Port: 65068
Request Start: 1.060 s
Time to First Byte: 79 ms
Content Download: 27 ms
Bytes In (downloaded): 36.3 KB
Uncompressed Size: 35.9 KB
Bytes Out (uploaded): 0.1 KB
Request Headers:

:method: GET
:authority: www.toyota.com
:scheme: https
:path: /imgix/content/homepage/img/explore/ToyotaRacing.png?w=552&dpr=1&q=80&fm=jpg&lossless=false&fit=max&cs=strip&bg=fff&
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36 PTST/396
accept: image/webp,image/apng,image/,/*;q=0.8
referer: https://www.toyota.com/?removeEnsighten=true
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.8
Response Headers:

:status: 200
content-type: image/jpeg
content-length: 36802
cache-control: public,max-age=604800
last-modified: Tue, 26 Sep 2017 17:10:51 GMT
server: imgix-fe
accept-ranges: bytes
date: Wed, 11 Oct 2017 22:09:11 GMT
x-content-type-options: nosniff
x-served-by: cache-lax8626-LAX, cache-iad2123-IAD
age: 1028091
x-cache: Hit from cloudfront
via: 1.1 cf6dfc066230dcf69540e8c3f8d6f9de.cloudfront.net (CloudFront)
x-amz-cf-id: K-rD5hX3vwu8Xtvf-m3qeBUZxesQxKPwAJe0UFl7uoJ-hKuXRnF3sw==
[/code]

There are like ten resources like this listed in that report.

Please help me to interpret results properly. What is actually wrong with it?

2

I do see your confusion, as I can verify the response headers on those images are “cache-control: public,max-age=604800”

One thing to try is to do a repeat-view test. When you do that, is the image actually re-downloaded again? If so, then there must be something off in the cloudfront settings. If not, then perhaps this is a bug within WPT.

3

Thank you for responding! That was very good suggestion. Luckily, that run was configured to hit on First view and the Repeat view, so I checked it out, and… the http response code was 304 - definitely cached :slight_smile:

:status: 304 date: Mon, 16 Oct 2017 20:46:19 GMT cache-control: public,max-age=604800 server: imgix-fe x-content-type-options: nosniff x-served-by: cache-lax8626-LAX, cache-iad2123-IAD age: 1028111 x-cache: Hit from cloudfront via: 1.1 98dbec6ba78c561cf37410a3bbd19a4e.cloudfront.net (CloudFront) x-amz-cf-id: yZXWoDUdEUbaVQym6hkaYgVOM0QCA27407IIieZyTCIdpaqjfr0TuQ==

So, I’m tending to feel that it is WPT bug.

4

Interesting, glad you can see that your headers are working as expected. If it bugs you enough, you can file issues with WPT here: Issues · WPO-Foundation/webpagetest · GitHub