Forum Moderators: phranque
Be aware that the caching effectiveness curve is not linear. That is, allowing the browser to cache an object for twice as long does not result in a bandwidth reduction of 50%. The effectiveness curve rises sharply from zero cache time time to a few hours, and then levels out after a a day or so. Caching an object for more than a few days brings almost zero benefit, since it is likely that the cached object will have been replaced by a different entry (i.e. a different object from a different site) because the size of the cache is finite; Old entries are discarded to make room for newer entries once the allocated cache space is all used.
So I'd suggest that you re-evaluate the likelihood that any given script will have to be updated and the "seriousness" of having stale cached scripts run for a few hours after you update the version on the server, and then choose appropriate cache-control settings based on those factors.
You can always use Apache configuration containers to set different cache-control headers for each file in addition to declaring a default caching time for all the others. Look into using the <Files> container.
Take a look at the scripts you're concerned about: How long ago was each one updated? How big was the change? How likely is it that that script will need another update soon? How serious would it be if the user missed the update for a few hours? Those considerations should help you decide how long you can afford to have each one cached.
Consider also that if your site is "sticky" -- If people tend to enter it and then spend a long time on it, then you'll get a good benefit from even a short cache time (a few hours, or twice the average visit time). It won't really matter if they re-load everything once a day, because your benefit comes from them not reloading the objects during their once-a-day visit.
If your site isn't sticky, then think about the likelihood that any given visitor will return to your site. If it is high, then caching will benefit you. If not, then it doesn't matter how long you set the cache for -- If they don't stick around and they don't come back, then almost all visits will result in all objects being requested from your server.
If I had to guess, I'd say that most people set their caching time too long. I generally consider anything over a 12-hour expires time to be something that needs to be considered carefully. The only objects that I cache for longer than 12 hours are images, since out of all object types, I find them to be least likely to change (without changing the filename).
There is also a "halfway" solution that you might consider: By setting the Cache-control "Must-revalidate" header, you can force the browser to check with your server using an If-Modified-Since header. If the object has been modified since the time that the browser last cached it, then the server will send a new copy. If not, then the server will send a 304-Not Modified response. While this results in a request to the server each time the browser renders an object, most of these requests will result in 304 responses. But you still save the bandwidth of sending the entire object most of the time.
To see a benefit, this approach requires that your server send accurate Last-Modified headers with every object. So before using this method, be sure that you don't send an updated Last-Modified header for script-generated content. The header must accurately indicate the last time the content actually changed, and not just the last time the content was generated; This is a common problem on sites where the content is dynamically generated, but doesn't really change every time the page is generated.
There are some methods (such as iFrames) that can be used to overcome the problem where most of the page doesn't change, but small sections do change every time the page is loaded. Further discussion of these methods is outside the scope of this forum, though.
Using the Live HTTP Headers add-on for Firefox/Mozilla browsers can be quite helpful in evaluating your current and modified Cache-control and Expires settings, the interaction of the browser cache with your server, and the effectiveness of settings changes.
Jim