"We should setup caching for "blank", set to forever"

Added cache controls to the blank page.

"Caching is not setup, and the files are set to expire in half an hour, from when they were first served. So, after using the app for over a half hour, they're expired."

Currently resource that are served through the ResourceRegistry API get a expiration time based on session's forecasted timeout. Next time the browser asks for the registered resources the server will send a HTTP 304 if the content is still valid (also with an updated expiration time).

"For some reason, some of the CSS files are getting served out several times"

This comment needs to be more specific. Maybe a separate issue would be better.

"The CSS and most of the JS are not minified"
"We're getting killed by all the copyright notices in every file"

This should be a separate issue that is more related to the build process.

"Some small files ~2KB seem to be taking disproportionately long to serve. Might be just due to disk access. Might be worth caching in RAM in an application scoped bean."

A separate issue & test case would be useful.

I suspect the reason for the multiple requests is related to the reload mechanism used whenever the HEAD of the page needs to be updated (such as when new JS links are added for the inputRichText component).

Basically, the HEAD is updated to add the new JS link, which requests the JS, then the page is reloaded by the bridge to ensure the revised HEAD is used, the the JS is requested a second time. As the reload mechanism for HEAD updates is necessary at this time we need to rely on browser HTTP caching of the resources to reduce the latency and overhead associated with the multiple requests.

Need to isolate why we're seeing multiple requests for the same resources.

Also need to configure the resource api use to cache these resources for a longer duration (1 week)? At least 1 day. The only time they will change is if a new ICEfaces version is used, and that would require a server restart, etc.