css - Google Chrome Audit says "The following resources are explicitly non-cacheable" on JSF resources from library -


i used chrome's auditing feature try find performance bottlenecks in web site. found lot of reports of non-cacheable resources.

i did dry run single-page containing stylesheet in library , found 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 audit log entry:

the following resources explicitly non-cacheable. consider making them cacheable if possible:     style.css.jsf 

the interesting thing is, if remove library, message goes away. so, looks there problem caching resources in libraries.

is there way fix this?

edit: according 1 of comments in answer, perhaps css not cached if normal refresh performed on page: set http headers force caching on js, css , png files

can right? why can't bookmark or typed in url re-used cached copy?

this false error.

the library attribute adds library value query string, see what jsf resource library , how should used? chrome audit appears penalize any query string in resource url, though response headers , actual browser behavior during refreshs valid. tried on own chrome , can indeed see false error too.

if tab "network" tab, must notice valid expires, etag , last-mofidied response headers (and no cache-control) , must observe below browser behavior:

  • on fresh request in empty cache, or on hard reloading page via ctrl+f5, must see http status of 200 on resources.
  • on navigating page referencing same resources, or on clicking same (bookmark) link again, or on pressing enter in browser's address bar once again, must see grayed out http status of 200 , "from cache" in size column.
  • on reloading page via f5 or ctrl+r, must see http status of 304 on resources (and browser receive smaller response — response headers, no body — , continue using cached version).

if resources "explicitly non-cacheable" literally mentioned chrome audit, you'd have seen full http 200 response in each single case.

query strings in resource urls used cache busting technique. when resource updated in server side, developer of course want force fresh reload in client side. 1 way renaming resource path/filename, , more common way changing query string parameter value (usually, 1 representing version or timestamp).

try more decent web performance testing tool. e.g. yslow. in case, didn't flip on query strings in resource urls.


Comments

Popular posts from this blog

c# - Better 64-bit byte array hash -

webrtc - Which ICE candidate am I using and why? -

php - Zend Framework / Skeleton-Application / Composer install issue -