[Sep 10, 2010] - Browser Caching and Image Swaps

Client Side/Browser Cache Settings:

A nasty gotcha exists for client side script authors. 
One of the "oldest tricks in the book" is the ever popular dynamic image swap. 
Based on observation of image tags and tags whose background-image property is set, 
when any change to an image is made the browser checks for a current copy of the image. 
For Internet Explorer users, under normal circumstances this means the local browser 
cache looks at itself and finds a current copy of the image and thus pulls the image 
from itself.  

The gotcha is that most web developers who use IE change their browser 
cache setting from "Automatically" to "Every visit to the page" in order to see the 
frequent changes that occur during development.  When this setting is changed, all 
client side image changes no longer check the local cache and instead initiate another 
GET to the server. This means if your animation loop is set to run every 100 milliseconds 
you potentially hit the server 10 times a second for each graphic that is modified 
while running through the loop.  

This will cause all sorts of problems ranging 
from poor performance of your animation sequence, to burning up your allotted 
bandwidth, and even up into the realm of getting banned by your server admins 
since they'll undoubtably see your animation as some cyber-terrorist trying to 
dos the web server where your site is located.

One potential solution we tried was to create new Image objects, check them 
for a completed readyState (an IE-ism) before trying to operate on them, 
then at each iteration of the loop, checking to see if the readyState changed 
and if so, then at least stop the animation and warn the visitor that 
their browser cache settings must be changed back to allow caching before the 
animation routine will permit itself to run.... but alas... the readyState 
always reported back as "complete" no matter how far from or close to the 
actual rendering change it was located. 

Worst of all perhaps is that there appears to be NO WAY to determine if a 
visitor's browser has the local caching disabled.  This is a damning barrier 
to client-side browser based game development, and any animation oriented 
development that will use JavaScript, VBScript or even client side PerlScript. 

Write your congress person today (care of bill@microsoft.com) and beg for 
a DOM property that can be used to determine the friendliness or hostility 
of a visitor's client-side cache setting.  Simply being able to warn a 
visitor that their cache setting is preventing them from seeing the page 
at the discretion of the author would go a long way toward bridging the 
gap between web developers and system administrators.  

...Don't be hating.

Comments and suggestions are welcome:
Contact thomas2003*esqsoft^om (antibot: *=@, ^=.c)