Google Chrome Audit says "The following resources are not explicitly cached" in JSF resources from the library
I used Chrome's auditing feature to try and find performance bottlenecks on my website. I have found many reports on non-cached resources.
I did a dry start with one page containing a stylesheet in a library and found the same thing:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html" >
<h:head>
<h:outputStylesheet library="default" name="style.css"/>
</h:head>
<h:body>
<div><h:outputText value="test"/></div>
</h:body>
</html>
Here's the audit log entry:
The following resources are explicitly non-cacheable. Consider making them cacheable if possible:
style.css.jsf
Interestingly, if I remove it from the library, this message goes away. So it looks like there is a problem with resource caching in libraries.
Is there a way to fix this?
EDIT: As per one of the comments in this answer, maybe the CSS is not cached if the page is doing a normal refresh: Set the HTTP headers properly to force JS, CSS and PNG files to be cached
Is it really so? Why can't the bookmark or entered URL be added to the cache?
source to share
This is a false error.
The attribute library
adds the library value as a query string, see also What is the JSF resource library and how to use it? A Chrome audit report appears for the penalty of any query string in the resource URL, even though the response headers and actual browser behavior during updates are fully valid. I just tried my own Chrome and I actually see this false error.
If you go back to the Network tab, you should notice that the response headers are valid Expires
, ETag
and Last-Mofidied
(and no Cache-Control
), and you should observe the following browser behavior:
- On a new request in an empty cache, or on a hard page reload with Ctrl + F5, you should see HTTP status 200 on those resources.
- When you go to another page that links to the same resources, or click on the same link (bookmark) again or press Enter again in the browser address bar, you should see an inactive HTTP status 200 and "from cache" in the column size.
- When reloading the page via F5 or Ctrl + R, you should see HTTP status 304 on those resources (and the browser will get much less response - only response headers, no body is the cached version).
If these resources are indeed "explicitly not cached", as the Chrome Audit literally mentions, you would see the full HTTP 200 response in every case.
Query strings in resource URLs are often used as a cache busting method. When a resource is updated on the server side, the developer of course wants to force a new reload on the client side. One way is to rename the resource path / name, but another and more common way is to change the value of the query string parameter (usually a value representing a version or timestamp).
Try using a more decent network performance testing tool. For example. YSlow. In my case, it did not flip query strings in resource urls.
source to share