Caching and Repeat View
|
01-05-2013, 07:47 AM
(This post was last modified: 01-05-2013 07:48 AM by rviscomi.)
Post: #1
|
|||
|
|||
Caching and Repeat View
On a private instance test, I'm seeing an F for "cache static content". Resources that are flagged have response headers similar to this:
Code: HTTP/1.1 200 OK 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. |
|||
01-05-2013, 08:27 AM
Post: #2
|
|||
|
|||
RE: Caching and Repeat View
Modern browsers will use heuristics to guess how long resources without caching headers can be cached.
|
|||
01-05-2013, 08:37 AM
Post: #3
|
|||
|
|||
RE: Caching and Repeat View
(01-05-2013 08:27 AM)pmeenan Wrote: 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? |
|||
01-07-2013, 11:23 PM
Post: #4
|
|||
|
|||
RE: Caching and Repeat View
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. |
|||
01-18-2013, 01:50 AM
Post: #5
|
|||
|
|||
RE: Caching and Repeat View
This section from the HTTP/1.1 spec is relevant to the topic of heuristic expiration:
Quote: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/rfc2...#sec13.2.2 So... what Pat said. ![]() |
|||
01-31-2013, 07:33 AM
(This post was last modified: 01-31-2013 08:05 AM by rviscomi.)
Post: #6
|
|||
|
|||
RE: Caching and Repeat View
(01-07-2013 11:23 PM)pmeenan Wrote: 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. 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/...rer-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. [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. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)