Static resources have private cache-control header
Why is this important?
Private cache-control headers are typically intended for customizing the browsing experience for a single user (e.g. a logged in user), whereby the resources are only cached privately - within the end-user's local browser cache.
When the cache-control header is set to private, this means that the resource can only be cached locally, and not on a shared cache. A shared cache is a cache that stores responses to be reused by more than one user. For example, an ISP or your company might have set up a web proxy as part of its local network infrastructure to serve many users so that popular resources are reused a number of times, reducing network traffic and latency.
What does the Hint check?
This Hint will trigger for any internal resource URL that sets the cache-control header to private.
Examples that trigger this Hint:
Resource file URLs that set a private cache-control header:
How do you resolve this issue?
Static content should available to all users, and presents an opportunity for aggressive caching, so setting the cache-control to private is wasteful. Once you have checked the resource files in question, and determined that they do not require a private cache-control header, replace 'private' with 'max-age=<seconds>', allowing as much time as possible for each resource.
Follow the decision tree below to determine the optimal caching policy for a particular resource, or a set of resources, that your application uses.