Hello Community,
A question abut the cache-control setting in the request/response headers. Do they have to match? I have set the max-age in the response (IIS config) to X days, but when the request header is showing max-age set to 0. Is that expected? I would think NOT.
I assume you mean the response header, not request, right? Any chance you have a link to a result with the headers? Sounds like the IIS setting isn’t being applied for some reason.
Thanks. So when I run a webpagetest, it always fails on the category of not setting any static files to have an expiration or max-age. I would of thought with my setting in IIS "Cache-Control: public, max-age=xyz", would do the trick, but I see that it is not the case. Any ideas on why this is happening or how to get this accomplished so webpagetest will mark it as NOT an F?
Do you have a link to a test result? That will help in identifying the specific requests it is having a problem with and show the headers that WebPagetest is seeing.
Yes, in a forced refresh it is normal for the client to request max-age: 0
That is the browser’s way of telling the server and any intermediate proxies that it needs the current version of the file and not to serve a version that was cached somewhere along the path. A reload of the page behaves very differently from actually navigating to a page for a second time. WebPagetest’s repeat views are done by closing the browser and then loading the page again in a new instance (browsers have an in-memory cache that behaves differently from the normal caching as well which is why we close the browser out).
Run WebPagetest and look at the repeat view test result? You can also use HttpWatch (for IE) or Chrome’s developer tools, both of which should tell you which resources came from local disk cache.