7

I was looking at Chirpy for css/js minifying,compression, etc. I noticed it doesn't support caching. It doesn't have any logic for sending expires headers, etags, etc.

The absence of this feature made me question if caching content is not as much of a concern; YSlow! grades this so I'm a little confused. Now I'm researching caching and cannot explain why this css file, SuperFish.css, is being retrieved from cache.

  1. Visit http://www.weirdlover.com (developer of Chirpy)

    Initial Download

  2. Look at initial network track. Notice, there is no expiration header for SuperFish.css.

    First pull

  3. Revisit the page and inspect the network trace again. Now SuperFish.css is retrieved from cache.

    Cached image

Why is the SuperFish.css retrieved from cache upon revisiting the page? This happens even when I close all instances of chrome and then revisit the page.

BartoszKP
  • 34,786
  • 15
  • 102
  • 130
Scott Coates
  • 2,462
  • 5
  • 31
  • 40
  • Thats why you see the ads from browsing companies....All that speed they showcase, actually comes from these caching techniques only. The browser developers have made sure, caching happens even if the server doesn't tells it. – Pankaj Upadhyay Jan 05 '12 at 17:07

2 Answers2

4

This seems to fall with in the HTTP specification.

13.4 Response Cacheability

Unless specifically constrained by a cache-control (section 14.9) directive, a caching system MAY always store a successful response (see section 13.8) as a cache entry, MAY return it without validation if it is fresh

13.2.2 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.

It would seem by not providing a cache-control header, and leaving out the expires header the client is free to use a heuristic to generate an expiry date and then caches the response based upon that.

The presence of an etag has no effect on this since the etag is used to re-validate an expired cache entry, and in this case chrome considers the cached entry to be fresh (the same applies to last-modified), thus it hasn't yet expired.

The general principle being if the origin server is concerned with freshness it should explicitly state it.

Chris Chilvers
  • 6,429
  • 3
  • 32
  • 53
  • If anyone is curious why the request contains a Cache-Control header but the response doesn't: Cache-Control headers in HTTP requests allow clients to control how downstream caches operate. In APIs like XMLHttpRequest, they can also be used to control how the local (i.e., in-browser) cache operates. http://www.mnot.net/javascript/xmlhttprequest/cache.html – Scott Coates Jan 05 '12 at 22:19
  • Indeed, I tried to use that to improve caching control at the client only to discover most browsers don't support things like max-stale, or max-age with a value other than max-age=0 – Chris Chilvers Jan 06 '12 at 00:17
0

In this case (when server doesn't return Expires header), the browser should make HTTP request with If-Modified-Since header, and if the server returns HTTP 304 Not modified then the browser gets the data from the cache. But, I see, nowadays browsers don't do any requests when the data is in the cache. I think they behave this way for better response time.

Pavel Surmenok
  • 4,584
  • 4
  • 30
  • 33