5

Right now I am trying to minimize the 304 requests to my website. I have implemented the suggestions called for here:

Asking browsers to cache as aggressively as possible

However no matter what I do some images refuse to be pulled from the cache even though they are similar to other ones that are pulled. Right now we are using IIS 7.5 and chrome to view the network traffic.

Here is an example of the initial response for the image, btn-blue.png, that will pull from the cache:

Accept-Ranges:bytes
Content-Length:49585
Content-Type:image/png
Date:Fri, 27 Jan 2012 16:02:26 GMT
ETag:"26cb96cdccc1:0"
Expires:Sat, 31 Dec 2012 00:00:00 GMT
Last-Modified:Thu, 26 Jan 2012 20:49:46 GMT
Server:Microsoft-IIS/7.5
X-Powered-By:ASP.NET

Here is an example of the response header for the image, topnav-blue-poweredbyipipeline.png, that will never pull from the cache:

Accept-Ranges:bytes
Content-Length:2680
Content-Type:image/png
Date:Fri, 27 Jan 2012 16:02:17 GMT
ETag:"b85767a6cdccc1:0"
Expires:Sat, 31 Dec 2012 00:00:00 GMT
Last-Modified:Thu, 26 Jan 2012 20:49:47 GMT
Server:Microsoft-IIS/7.5
X-Powered-By:ASP.NET

Any idea why one would pull and the other one won't?

Community
  • 1
  • 1
Brian S.
  • 405
  • 3
  • 10
  • Did you mean "maximize" 304 responses? You need to look into adding caching-related headers into responses (there are a couple of them, treated differently by different browsers), then ETag and Expires are also relevant. –  Jan 27 '12 at 16:20
  • Actually I am looking to make it so that the browser doesn't need to call the server at all. Just pull it from the cache. Right now it is getting a 304 message back but I was hoping that it wouldn't have to make that call in the first place. – Brian S. Jan 27 '12 at 16:23
  • The browser has to download the content that lives at any particular url at least once. It is up to the server to "ask" the browser to cache it (while also specifying "how" and "for how long"), and it is up to the browser to respect that. The server provides these instructions via the response-headers (a separate research; I'm just giving you pointers), and I'm pretty sure all popular browsers will honor those instructions without lying to you. –  Jan 27 '12 at 16:30
  • Can you define exactly what you mean by "pull from cache" and "not pull from cache"? – Andrew Barber Jan 27 '12 at 16:40
  • Sure! In chrome when viewing the network tab in the developer tools some images will say "(from cache)" under the size column and others will say "250B" or something like that. Also under the Status column it will say "304" if it asked the server or "200" if it didn't. So I am assuming that the ones that are marked "(from cache") are from the cache and "304" are used from the cache but are not pulled initially from it . – Brian S. Jan 27 '12 at 17:39
  • 304 is a response from server that means "content not changed"; browsers that have the same content CACHED but also E-TAGGED will ask the server if that content changed. If you remove the ETag from the response headers, while keeping the caching/store headers, the browser will use it from cache. Now, you'll ask, how do you do that for images? From within IIS, per file extension, per folder, or write code to intercept every request (even for static files) and add caching headers to those responses, and remove ETag. BTW, ETag is good; I think you're wasting a little time looking for perfection. –  Jan 27 '12 at 17:45
  • BTW, if you do decide to go "global" on changing response headers for static content (such as images, css, js), then plan on how to tell the browser to actually re-request those files when they are updated. Otherwise, you'll never be able to update any of those files (without breaking the site for some clients), and you'll always have to rename files (or paths with query) in order to force browsers to request them again. –  Jan 27 '12 at 17:49
  • @Hari I understand what you are saying, but notice the Etag is in both responses however one of them is still pulled from the cache and the other one is not. You are right it sounds like am looking for perfection however in this case I have a bunch of metrics showing if I can minimize these calls the page will render noticeably faster. – Brian S. Jan 30 '12 at 21:08
  • I'm pretty sure that you can control that via code: make sure IIS passes these requests to your app, and have appropriate handlers add caching and etag headers as you like. ETag is typically added by webserver (IIS); however, you obviously don't want them at all. So, intercept these requests, add/remove headers. BTW, there are also ways to remove unnecessary things such as `Server:Microsoft-IIS/7.5` and `X-Powered-By:ASP.NET` from your responses (a perfectionist would want that also; you'll find that googling). Also, force compression for those browsers that report supporting it in requests. –  Jan 30 '12 at 22:20

2 Answers2

5

So we figured out why this was happening. It turns out if you use the Enter button to navigate to a web page Chrome will aggressively use its cache. If you use the refresh button Chrome will make a call out for almost every element.

Brian S.
  • 405
  • 3
  • 10
0

Everything in that other post that you linked has a Cache-Control: max-age= header. Have you tried that? I don't think expires and etag is enough, I think you need the Cache-Control also, but I haven't actually tested it.

eselk
  • 6,764
  • 7
  • 60
  • 93
  • Actually yea I have tried to use Cache-Control as well but I get the same results. I don't think I can get IIS to use both but if you know a way I would love to try! – Brian S. Jan 27 '12 at 17:34