Dylan,
The problem you have run into is a very well known one. Don’t bother playing around with PNG, JPG, GIF etc - it will not make a blind bit of difference. Given below is the explanation to the problem and then the solution. If you can’t be bothered understanding the explanation just skip to the solution.
Explanation
IE, as is rather well known, is particularly dumb. When it encounters an image tag it does the following
1. checks to see if the image is available in its local cache.
2. Should the image not be available it, quite reasonably, gets it from the server in question. The request it sends goes like this
GET /scripts/justlogo.png HTTP/1.1
Referer: http://localhost/btest.html
Accept-Language: en-us,en-gb;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 2.0.50727)
Host: localhost
Connection: Keep-Alive
3. Should the image be available it checks to see when it was downloaded and then sends of a request to the server anyway. Here is that second request
GET /scripts/justlogo.png HTTP/1.1
Referer: http://localhost/ctest.html
Accept-Language: en-us,en-gb;q=0.5
Accept-Encoding: gzip, deflate
If-Modified-Since: Thu, 05 Jun 2008 10:44:37 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 2.0.50727)
Host: localhost
Connection: Keep-Alive
The important bit here is If-Modified-Since:. The server - quite resonably - responds saying that the image has not been modified since the date in question.
HTTP/1.1 304 Not Modified
Content-Type: text/html
Content-Length:
Connection: Keep-Alive
Keep-Alive: timeout=30000, max=15
Date: Thu, 05 Jun 2008 14:04:24 GMT
Server: Abyss/2.4.0.3-X1-Win32 AbyssLib/2.4.0.3
Content-Length:
The important bit here is 304 Not Modified which persuades IE to use the cached image. The trouble is that this wholly unecessary round trip to the server causes a perceptible delay. Other browsers - Firefox, Opera, Safari… - do make more logical assumptions and do a better job. How? They check the Last Modified value from the header sent with the original (first) image request
HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 8346
Last-Modified: Thu, 05 Jun 2008 10:44:37 GMT
Connection: Keep-Alive
Keep-Alive: timeout=30000, max=15
Date: Thu, 05 Jun 2008 14:04:18 GMT
Server: Abyss/2.4.0.3-X1-Win32 AbyssLib/2.4.0.3
and make a decision as to whether they should attempt to download the image again.
Solution
IE users can deal with this problem by adjusting their browser settings. Needless to say, you cannot rely on that. It is possible to persuade IE to behave using a small bit of JavaScript that instructs it to Use that Cache!. However, this may not always work
a. The user is using IE5.5 or earlier, or IE6 without Windows XP Service Pack 1 (unlikely but not impossible) or
b. JavaScript has been turned off.
In my experience both possibilities are somewhat theoretical - none of my sites have any significant traffic that uses IE6- and less than 3% of visitors have JavaScript turned off. Nevertheless it is best not to make any client side assumptions and use a server-side solution instead. The steps involved are these
a. Modify your image url. For instance instead of
body{background-image:url(image.png)}
make it
body{background-image:url(image.php)}
b. Then write this very simple PHP script
<?php
header("Expires: Fri, 31 Dec 2010 23:59:00 GMT");
header("Content-type: image/png");
$img = @imagecreatefrompng('image.png');
imagepng($img);
?>
What this does is simple
a. We inject a header into the response from the script to indicate when the contents being squirted down expire. I have put in a date at random. Note that you need to add these custom headers before you do anything else.
b. Specify the content type - could be different in your case.
c. Load the image. If your image is not located in the same directory as your script (it should not be) you will have to make sure you specify the path to it correctly.
d. Squirt the image back to the browser in question
That is it! This way you don’t end up with any ugly IE-specific JavaScript code, don’t have to worry about which IE the user is using, whether JavaScript is turned on or not… .
In case you are curious it is well worth examining the requests sent out by IE to see just what happens under the covers. Here is a freebie Freeware HTTP Packet Sniffer.
Hope this helps.
