Has anyone added a cache header to static content?

smm

If we're editing metadata when a large directory tree is open in the folder pane, it often takes more than 1 minute for the action to complete. It appears that this is because the static content ( *.js, *.css, look images etc...) has no specific cache properties, and for certain features, the browser asks if the content has expired for each static component. This operation takes a lot of time due to network latency (Sometimes more than 50 requests are sent to the web server when a page is reloaded,even if the browser cache is set to "automatically").

To solve this problem, we would like to add a cache header to static content by making the following setting change:
•Go to the IIS mmc
•Go to the MediaBin Virtuel Directory
•Right click on "images" directory for properties
•Click on "HTTP Headers" tab
•Select "Enable Content Expiration"
•Select 1 days
•Then Click "OK"
•Do the same thing with "css" and "js" directory.
Has anyone else done this? We've tested this in our dev environment and know that making this change improves performance significantly, but we'd like to know if anyone has any recommendations or warnings about this setting. Will checking expiration only once a day cause any problems? I saw a KB article for TeamSite about this, but if anyone has any info re MediaBin, that would be great.

Migrateduser

For the benefit of all, here's some information on what Interwoven does in terms of interfacing the web application with the browser cache.

The browser will always cache javascript, image, and css files on a per session basis. In other words, when a users logs into the web client, the files are pulled from the web server when they are used, then cached for the lifetime of the user’s session. The browser will always send the file modification date with the HTTP request for a file. If the file on the web server is newer, it will be returned; if not, a return code of 304 is returned to the browser and the file is loaded from cache. Therefore, even though the file is cached, the browser will still send a request to the web server to verify the file is current. Note the both FireFox and Safari have problems managing cached files. Those browsers frequently grab the files from cache without first determining if they are up to date, which can sometimes result in the user seeing stale pages. This issue would normally only occur after an upgrade or patch was applied that affected javascript files.

Thumbnails are also cached on a session basis. The asset GUID, modification date, and version are part of the URL used when the browser requests a thumbnail from the browser. MediaBin code checks the date and version of the asset to determine if the thumbnail is current, and returns the thumbnail content if not (otherwise 304, as described above).

You should never cache ASP pages because the HTML content is not static. The only ASP page that is cached is the page used to retrieve thumbnails (PreviewImage.age). The contents of a folder may change. A “no-store” directive is included in all ASP files to inhibit caching.

Adding custom HTTP headers should increase performance, as has been witnessed by the poster. Including an EXPIRES attribute in the HTTP header saves the browser from having to check with the web server to verify files are current. Also cached pages would persist even after the user's session had terminated. If an upgrade or patch is applied, users therefore may see out of date files unless they manually clear the browser cache or override the cache by using CNTRL-F5 to reload pages. Once a page is delivered to a browser with an EXPIRES date, it will remain in the browser cache across sessions so the web administrator will not be able to remove it; the user must do this. That should be the only downside to using the EXPIRES header.