Caching should be used to decrease server load and reduce the amount of data browsers need to download while browsing your site.
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. As a result, the ability to cache and reuse previously fetched resources is a critical aspect of optimizing for performance.
Enable caching of your page resources so browsers can reuse resources that have already been downloaded. The
Cache-Control response header is used to specify the caching policy of each URL: the
no-store setting prevents all browser caching and the
no-cache setting forces the browser to check with the server if a cached version is out-of-date before using the cached copy. For page resources, we recommend that
no-store are not set. This configuration means a browser will always cache resources and will immediately reuse them if needed without having to contact the server again. Warning: You must have a strategy for how updated versions of your page resources are going to replace the cached versions. Generally, each updated resource should use a new URL to force browsers to fetch the new version. This is referred to as “cache busting” and is built into many web frameworks.
Use long caching times
Configure page resources to have long caching times so browser caches will retain them for longer. The cache duration of each resource URL can be specified by either 1) setting an
Expires response header which specifies the point in time the response becomes stale such as
Expires: Fri, 10 Aug 2019 20:00:00 GMT or 2) adding a
max-age directive to the
Cache-Control response header that specifies the number of seconds the response is valid for such as
Cache-Control: max-age=3600 for 1 hour. If
Expires are both used,
max-age takes priority. We recommend setting the cache time of page resources to at least 24 hours.
Avoid duplicate resources
The same page resource should always be served from the same URL to improve caching efficiency. Browsers will only reuse a cached resource if the resource is requested from the exact same URL as before. If the same resource is available over multiple URLs, this can lead to extra browser requests. For example, say a browser cached a resource from
http://example.com/jq.js and later had to request identical content from these URLs while browsing (where the URL differences are highlighted):
http:// www. example.com/jq.js,
http://example.com/ jquery .js,
http://example.com/ libs/ jq.js,
http://example.com/jq.js ?a=1&v=3.2. As none of the URLs are exact matches, the same content would need to be downloaded when each URL was first seen as a cached response from a different URL cannot be used instead. For caching to happen, URLs must have matching protocols, filenames, folders, query parameters and even query parameter ordering. Avoid caching issues like this by making sure each unique page resource is referenced using a single consistent URL.
More articles in this series
➜ This article is from our comprehensive Page Speed Best Practices guide.
➜ Next article in this series: CSS
➜ Previous article in this series: Page size