|Any way to have browsers use cached images for https?|
| 8:42 pm on Jun 23, 2009 (gmt 0)|
We use expires headers and are generally picky about our site speed, so this speed issue with https is bothering me greatly.
Our expires headers on images works great when browsing the site via http but as soon as visitors browse to the shopping cart (https) their browsers re-load all of the global site images (header, footer, etc) and it slows things way down.
Is there any way to direct the browsers to use the images they've already cached?
| 1:03 am on Jun 25, 2009 (gmt 0)|
It's not easy to get consistent results because many browsers by default don't conserve anything served over a secure connection in the browser cache, this for security reasons.
One possibility is to set a HTTP header for "Cache-Control public" for certain cacheable documents. Note that I've never tested this personally, but I'm led to believe that it works, at least in Firefox 3.x. For Apache you can try something like:
<Files ~ "\.(jpe?g¦gif¦png¦ico¦swf¦css¦js)$">
[b]Header set Cache-Control public[/b]
ExpiresDefault "access plus 1 month"
Internet Explorer tends to be more liberal in accepting cached documents over SSL, the default settings should allow for caching according to the server headers, even over a secure connection. Of course, when you switch from a non-secure to a secure page the images will always have to be downloaded once again by the browser (you can't use non-secure elements on a secure page, so the change in URI for the images means that they will always be seen by the browser as "new" elements), but at least you need to try to avoid the static elements being reloaded for every page view on the secure site.
Are you having issues with a particular browser or is it generalized? What do your cache settings indicate?
| 2:48 pm on Jun 25, 2009 (gmt 0)|
if you've got some little icons on there, then you code them as data strings directly into your HTML, rather than as images.
<img src="data:image/gif;base64,blah blah blah">
that will do away with a HTTP request
| 3:01 pm on Jun 25, 2009 (gmt 0)|
Thanks guys, I'm going to try some of these suggestions and report back. I have noticed the issue more in Firefox than IE, but I'll try to control the experiment somewhat in that regard as well.