In my last post about the vagaries of Internet Explorer, I touched upon a technical solution we’d implemented to get Internet Explorer respecting our cache directives.
As we are using Apache, its mod_expires module should be loaded with which we can specify for how long the user agent should cache the images. In this case we use a LocationMatch to specify the paths as a regular expression to where our assets are located:
<LocationMatch "^(/path/to/images|/another/path/to/images)">
FileETag All
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 14 days"
ExpiresByType image/jpeg "access plus 14 days"
ExpiresByType image/gif "access plus 14 days"
ExpiresByType image/png "access plus 14 days"
</IfModule>
</LocationMatch>
In this instance, we’re telling the client to cache jpg, png and gif images for 14 days and we are also ETag-ing these files – another useful measure to force the point on IE.
Even with this in place, it wouldn’t be Internet Explorer without having to deal with yet another of its quirks. If you gzip or deflate content in Apache but exclude images from this compression (for obvious reasons), Internet Explorer will refuse to cache those uncompressed images if a Vary header is being sent to the client. Luckily both mod_gzip and mod_deflate have workarounds for this :
mod_deflate (for Apache 2)
SetOutputFilter DEFLATE SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|gz2|sit|rar)$ no-gzip dont-vary
mod_gzip (for Apache 1.3)
mod_gzip_on Yes mod_gzip_send_vary Off mod_gzip_dechunk Yes mod_gzip_item_include file \.(html?|txt|css|js|php)$ mod_gzip_item_include mime ^text/.* mod_gzip_item_include mime ^application/x-javascript.* mod_gzip_item_exclude mime ^image/.* mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
The relevant entries here that turn off the Vary header are “mod_gzip_send_vary Off” for mod_gzip and “dont-vary” for mod_deflate. You’ll know it’s working when you start seeing Expires, Cache-Control and no Vary headers when requesting images in the relevant locations.
With this in place, Internet Explorer speeds up no-end! The flip-side of that from a development point-of-view is that more people will hang on to their crusty old browser for longer. Patience is required for the next 6 months or so.
The costly legacy of Internet Explorer 6 (and some tips on how to work around it)
February 19th, 2009 by James Ellis
Thankfully, the footprint of Internet Explorer 6 is declining at a steady rate but until it reaches less than say 15% of a general audience we’re going to have to put up with it. The best we can do to speed its decline is provide some subtle hints about upgrade paths to its user-base.
To do our part, we thought illustrating practical example of problems caused by IE and the flow-on effects of those problems.
Recently, we completed an overhaul of EuroCheapo’s homepage, implementing a snazzy and lighter new layout. We think it’s great, especially as we are able to find budget accommodation for our next European jaunt using CheapoSearch. Our development methods involve test-as-you-code processes in Firefox 3 followed up by Internet Explorer 7 testing as the go-live date draws nearer. It’s a method that works quite well as we can be pretty sure that layouts, even complex ones, are going to work just as well in Safari 3, Chrome, Konquerer and Opera 9 as they do in Firefox.
During the IE testing phase of this project I booted up our trusty-but-rusty XP box containing a pristine copy of Internet Explorer 6 and went to work trying to smooth out the expected rough edges. One of the most perplexing of these was that where Firefox flew through the dynamic CheapoSearch box we’d added to the homepage, IE became bogged down just loading the calendar widgets and the background images in.
Checking our access logs, stepping through the Javascript and a few googles later confirmed that Internet Explorer was refusing to cache any images associated with the dynamic parts of the CheapoSearch box, even though our caching rules were being respected by every other browser. Laughably, every time a form was switched in and out of view the access logs would fill with requests to the various images that had popped into view.
From an IE6 user perspective, the site was taking up to 25 seconds to completely load the page and make the page elements interactive (IE7 was not much better) along with a 2-3 second wait for dynamic elements to become visible.
While there is a technical solution, which we’ll cover, the process of implementing it couldn’t but make me wonder about the side effects of IE6 usage on its users and systems it connects to:
Will IE6 ever fully go away? Developers dream of IE6 extinction – it will happen – but until then the costs associated with testing and hacking around its various idiosyncrasies will still be a burden, time and dollars wise, for developers and site owners.
Back to the technical solution for this … what forces IE to cache those images ?.
Footnote: Internet Explorer 7 isn’t much better in that it displays this behaviour as well. What’s the best solution IE browser users can implement? Easy: use another browser.
Tags: bandwidth, browser, deflate, firefox, internet explorer, mod_gzip, opera, overhead, safari, standards, support, upgrade
Posted in commentary, web development | No Comments »