JSF libraries for static content - or normal static files - performance?

Question

We have two ways we can serve items like images, javascript, css.

• A static area, say "/images/foo.png"
• A JSF library, which renders something such as "/javax.faces.library/foo.png?ln=images"

The latter seems the way that things go in JSF. It's easy to do. There's a lot of support for it.

The former allows interesting tricks in a situation where performance counts. We can arrange our server to not pass /images to the servlet engine but use something faster instead. To be fair I don't know of anyone using our software who has done this, or how much a cost having something like Tomcat or JBoss serve static content over something native such as Apache and how much this is against the cost of the business logic that is also going on to provide the application itself.

We hope that in both cases the images will be served with a long time to live so the browser can cache them. I note the JSF version has a query string part, so hope that a browser doesn't decide it knows better and refuses to cache. We'll have to look at some traces to see what's happening.

So which to do? JSF libraries? Take advantage especially of support in things like the h:outputScript and h:outputStylesheet controls? Or an images area of the site?

Thanks - Richard

Answer 1

For performance reasons, I found myself better off using a custom solution where jsf did NOT manage my page dependencies. Having your own dependency resolution mechanism via some sort of custom "resource management" servlet gives you a lot of flexibility with what you can do when each resource is requested

Some of the advantages of doing so,

• Adding caching headers according to your requirements
• Being able to serve concatenated resources instead of serving one resource at a time. So if you build your resource urls like "http://server.com/app/resources/one,two.js, you could serve both files one.js and two.js in one request by concatenating them in memory.
• Being able to use a custom cache invalidation strategy by simply changing the query parameters on images. for eg. http://server.com/app/resources/images/apple.jpg?version=1 where "version" could be the version of your application.
• Maintain your own directory structure of static resources and not having to strictly rely on jsf's resource directory structure.

Alternatively, you could also delegate all of these to some other application or third party to do all of these better.