Now, what's really annoying is, if you've done all that and added expires headers, just to find out, that your company decides to deploy a browser setting by policy, that makes it reload each page completely every time (because some stupid Intranet applications based on oh so cool Oracle and Struts can't cope with the standard setting). As if it wasn't bad enough to develop for IE 6 ...
One more hint: If you are using an Expires header anyway, why not make it a "far future Expires header" (as Yahoo puts it), like 1 year ahead or even more? If any of your cached resources change, you will have to make sure that they are reloaded, anyway. Adding a version number to the file name still looks like the best approach to me and using an automated build process (as mentioned by Jeff) can even make it pretty easy to do.
Talking about gzipping JS files almost automatically brings up the topic of minifying JS (or not). There's been a lot of argument pro and con on this, and definitely, when compared, gzipping alone is far more effective than minifying alone. But if you are willing to take the hassle and generate gzipped versions anyway (unless you're running a version of Domino that can do it on-the-fly, which will not be before 8.5, if I remember right), in my mind you can just as well minify them. Even more so, if you choose to provide an uncompressed version as well for browsers that might have trouble with gzipped contents (see {Link}
Also, I'd like to take the opportunity to take up the cudgels for Yahoo's YSlow. I've seen a number of bloggers questioning the usefulness of this tool. Usually the argumentation is like: Hey, my site loads blistering fast anyway, why do I get a page rank of "D" then? In my eyes, this is a misunderstanding. YSlow is not intended to rate the absolute performance of a site (under given conditions like bandwidth, CPU power, browser's rendering speed and so on). It's really just about adopting patterns. To what extend it pays off will depend a lot of factors, but there's no reason to not do it right in the fist place.
And by the way: Your site's resourced could use a far future Expires headers as well, Jake. ;-)
Now, what's really annoying is, if you've done all that and added expires headers, just to find out, that your company decides to deploy a browser setting by policy, that makes it reload each page completely every time (because some stupid Intranet applications based on oh so cool Oracle and Struts can't cope with the standard setting). As if it wasn't bad enough to develop for IE 6 ...
One more hint: If you are using an Expires header anyway, why not make it a "far future Expires header" (as Yahoo puts it), like 1 year ahead or even more? If any of your cached resources change, you will have to make sure that they are reloaded, anyway. Adding a version number to the file name still looks like the best approach to me and using an automated build process (as mentioned by Jeff) can even make it pretty easy to do.
Talking about gzipping JS files almost automatically brings up the topic of minifying JS (or not). There's been a lot of argument pro and con on this, and definitely, when compared, gzipping alone is far more effective than minifying alone. But if you are willing to take the hassle and generate gzipped versions anyway (unless you're running a version of Domino that can do it on-the-fly, which will not be before 8.5, if I remember right), in my mind you can just as well minify them. Even more so, if you choose to provide an uncompressed version as well for browsers that might have trouble with gzipped contents (see {Link}
Also, I'd like to take the opportunity to take up the cudgels for Yahoo's YSlow. I've seen a number of bloggers questioning the usefulness of this tool. Usually the argumentation is like: Hey, my site loads blistering fast anyway, why do I get a page rank of "D" then? In my eyes, this is a misunderstanding. YSlow is not intended to rate the absolute performance of a site (under given conditions like bandwidth, CPU power, browser's rendering speed and so on). It's really just about adopting patterns. To what extend it pays off will depend a lot of factors, but there's no reason to not do it right in the fist place.
And by the way: Your site's resourced could use a far future Expires headers as well, Jake. ;-)