Serve static assets with an efficient cache policy
Why is this important?
Fetching something over the network is both slow and expensive. Large responses require many roundtrips between the client and server, which delays when they are available and when the browser can process them, and also incurs data costs for the visitor.
Setting a cache header on your server response will tell the browser that it doesn't need to download assets again, which avoids unnecessary requests to the server. As such, HTTP caching can speed up your page load time on repeat visits.
What does the Hint check?
This Hint will trigger for any internal URL that contains resource URLs which are not cached, or have a cache policy that is less than 1 year (31536000 seconds).
Resource URLs considered 'cachable' have a 200 status code, don't have an explicit no-cache policy and are either a font, image, media file, script, or stylesheet.
How do you resolve this issue?
The Cache-Control header is the most important header to set as it effectively 'switches on' caching in the browser. With this header in place, and set with a value that enables caching, the browser will cache the file for as long as specified. Without this header the browser will re-request the file on each subsequent request.
Configure your server to return the Cache-Control HTTP response header:
The max-age directive tells the browser how long it should cache the resource in seconds. This example sets the duration to 31536000, which corresponds to 1 year: 60 seconds × 60 minutes × 24 hours × 365 days = 31536000 seconds.
Ideally, you should aim to cache as many responses as possible on the client for the longest possible period, and provide validation tokens for each response to enable efficient revalidation.
Follow the decision tree below to determine the optimal caching policy for a particular resource, or a set of resources, that your application uses.