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

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 e开发者_Python百科asy 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

---

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.

---

There are a couple of things you can do to improve performance of your screens and static content/libraries/java scripts

1. GZIP filter will reduce the initial load time significantly. It compresses the page contents while transferring to client browser. Refer to https://stackoverflow.com/a/35567295/5076414
2. You can additionally implement a cacheFilter to bring performance of your screens at par with JavaScript based UI. This will cache the static content of your screen such as icons, images, stylesheets, javascripts etc. You can control what to cache and what to exclude. Refer to https://stackoverflow.com/a/35567540/5076414
3. For client side UI components, you can use Primefaces which is JQuery based UI.

How to verify if my screen is using gzip and cache

To see if your contents are already usign gzip and cache, In your Google Chrome Browser -> right click on your screen -> inspect -> click network tab -> refresh your screen. Click on the images, icons, stylesheets and see if you see following in response header

Cache-Control:max-age=2592000 if the status of element is 304 (coming from cache)

Content-Encoding:gzip if the status of element is 200