Caching and Repeat View

[rviscomi]

On a private instance test, I’m seeing an F for “cache static content”. Resources that are flagged have response headers similar to this:

HTTP/1.1 200 OK Server: Apache/2.2.15 (Red Hat) Last-Modified: Fri, 04 Jan 2013 05:30:30 GMT Accept-Ranges: bytes Content-Type: application/x-javascript;charset=utf-8 Content-Encoding: gzip Content-Length: 226225 Date: Fri, 04 Jan 2013 16:44:42 GMT Connection: keep-alive Vary: Accept-Encoding

The browser used for the test was IE 9.

So if these resources lack a max-age or Expires header, why aren’t they 304ing in the repeat view? The repeat view appears as if the resources were cached.

Because this was a private instance test, I’m not able to link to the results.

[pmeenan]

Modern browsers will use heuristics to guess how long resources without caching headers can be cached.

[rviscomi]

@pmeenan

Modern browsers will use heuristics to guess how long resources without caching headers can be cached.

Thanks Pat, that was my feeling.

Given that, how important are caching headers when the browser pretty much fills in the blanks for you?

Related question; how can we simulate the behavior when browsers don’t make any assumptions about resource cachability?

[pmeenan]

You can’t really simulate it but if you test with IE 8 you should be able to see what it looks like without the heuristics.

It’s still a pretty important optimization. If your site will work if the browser caches content (like it will with the heuristics) then explicit headers are no more risky and give you full control over it. If the site doesn’t work (resources aren’t versioned) then it will also break with the heuristic caching.

[rviscomi]

This section from the HTTP/1.1 spec is relevant to the topic of heuristic expiration:

Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on their results. Since heuristic expiration times might compromise semantic transparency, they ought to used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.2

So… what Pat said.

[rviscomi]

@pmeenan

You can’t really simulate it but if you test with IE 8 you should be able to see what it looks like without the heuristics.

It’s still a pretty important optimization. If your site will work if the browser caches content (like it will with the heuristics) then explicit headers are no more risky and give you full control over it. If the site doesn’t work (resources aren’t versioned) then it will also break with the heuristic caching.

This topic has been on my mind so I did some more research. I’ve found some useful information from Microsoft about heuristic caching in IE 9.

http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx

I was happy to see that there actually is a way to disable heuristic caching, which will make developers’ caching mistakes much more obvious:

[quote]Best practices recommend that web developers should specify an explicit expiration time for their content in order to ensure that the browser is able to reuse the content without making conditional HTTP requests to revalidate the content with the server. However, many sites deliver some content with no expiration information at all, relying upon the browser to use its own rules to judge the content’s freshness.

Internet Explorer allows the user to configure what should happen when content is delivered without expiration information. Inside Tools > Internet Options > Browsing history > Settings, you will see four options:

[list=1]
[]Every time I visit the webpage
Any resource without explicit freshness information is treated as stale and will be revalidated with the server before each reuse.
[]Every time I start Internet Explorer
Any resource without explicit freshness information is validated with the server at least once per browser session (and every 12 hours thereafter in that session).
[]Automatically (Default)
Internet Explorer will use heuristics to determine freshness.
[]Never
Any cached resource will be treated as fresh and will not be revalidated.
[/list]

These options only control the browser’s behavior when content is delivered without expiration information; if the content specifies an explicit policy (e.g. Cache-Control: max-age=3600 or Cache-Control: no-cache) then the browser will respect the server’s directive and the options here have no effect.[/quote]

[Edit] I’ll take the extreme stance that WPT should disable heuristic caching by default where possible. If the purpose of a repeat view is to demonstrate which resources are not cacheable, this change would add value and insight.