JSF Cache Static Resources Filter

by

How do I write a filter which will appropriately cache static resources as recommended by Google

If you mean with JSF resources the files in /resources folder which are fully handled by JSF builtin resource handler (and thus all referenced via <h:outputStylesheet>, <h:outputScript>, <h:graphicImage>, #{resource} and thus not via the plain HTML way), then you don’t need to homegrow a filter for the job. The only thing which you need to do to satisfy Google recommendations is to set the Expires date a bit further in the future. It namely defaults to 7 days (604800000 milliseconds) while performance testing tools like Google Page Speed and Yahoo YSlow recommends a minimum of 30 days (2592000000 milliseconds).

In Mojarra, you can set it with the following context parameter in web.xml:

<context-param>
    <param-name>com.sun.faces.defaultResourceMaxAge</param-name>
    <param-value>2592000000</param-value> <!-- 30 days -->  
</context-param>

And in MyFaces with the following one:

<context-param>
    <param-name>org.apache.myfaces.RESOURCE_MAX_TIME_EXPIRES</param-name>
    <param-value>2592000000</param-value> <!-- 30 days -->  
</context-param>

Is it sufficient to create a filter which sets the last-modified date to some static date (this will change every time the server restarts)?

You don’t and shouldn’t need to set the Last-Modified. The JSF resource handler already does that automatically. If you’d like to force reloading by resources because you changed them, then use resource library versioning. See also What is the JSF resource library for and how should it be used?

Note that changing it everytime the server restarts makes no sense as the Expires header would still keep telling the browser to re-test the validity of the cache after a certain period only. Until the browser actually requests the resource, the browser would never notice the change in the Last-Modified of a resource. The only thing which forces the browser hard to re-request the resource fully is a change in the URL, usually achieved by a changed query string parameter value. The JSF resource library versioning does exactly that.

Also note that the OmniFaces CombinedResourceHandler uses the resource’s last modified timestamp as “resource version” in the query string instead of the resource library version. So if you’re using that, you don’t necessarily need resource library versioning mechanism.

The link above seems to suggest you need to specify Expires or Cache-Control. Why is that necessary?

The Expires header tells the browser when to re-test the validity of the cached resource by a conditional GET request. So, until that time the browser won’t do that and will keep using the one in the cache. The Cache-Control tells the browser which caching strategy to use. Note that when it’s set to e.g. no-cache instead of public, then the Expires header would have no effect. Also note that the absence of Cache-Control header implies public (as done by JSF resources).

More Related Contents:

  1. How implement a login filter in JSF?
  2. Is there any easy way to preprocess and redirect GET requests?
  3. How control access and rights in JSF?
  4. Conversion Error setting value for ‘null Converter’ – Why do I need a Converter in JSF?
  5. How and when should I load the model from database for h:dataTable
  6. Conditionally displaying JSF components
  7. How to save uploaded file in JSF
  8. When using templating, where should I declare the ?
  9. How do PrimeFaces Selectors as in update=”@(.myClass)” work?
  10. Packaging Facelets files (templates, includes, composites) in a JAR
  11. Default action to execute when pressing enter in a form
  12. What is the usefulness of statelessness in JSF?
  13. How to use with DefaultStreamedContent in an ui:repeat?
  14. What URL to use to link / navigate to other JSF pages
  15. How to compare a char property in EL
  16. PrimeFaces CSS skin not showing in login page, also JavaScript undefined errors
  17. Does view scope bean survive Navigation JSF
  18. Invoking methods with parameters by EL in JSF 1.2
  19. String concatenation in EL for dynamic ResourceBundle key
  20. NullPointerException while trying to access @Inject bean in constructor
  21. Overview of all JSF-related web.xml context parameter names and values [closed]
  22. JSF 2 Global exception handling, navigation to error page not happening
  23. How do UISelectOne and UISelectMany components preselect defaults in f:selectItems
  24. JSF 1.2: How to keep request scoped managed bean alive across postbacks on same view?
  25. Difference between managed bean and backing bean
  26. How to use java.time.ZonedDateTime / LocalDateTime in p:calendar
  27. How detect and remove (during a session) unused @ViewScoped beans that can’t be garbage collected
  28. Passing parameters to a view scoped bean in JSF
  29. Calling Primefaces dialog box from Managed Bean function
  30. Pass method argument/parameter to composite-component action attribute

Leave a Comment