Caching - Page Speed Best Practices (2024)

Want to know when we write new articles? 😄 Get news and updates about web best practices from us via

Twitter,Facebook orour newsletter.

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-cache and 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.

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 max-age and Expires are both used, max-age takes priority. We recommend setting the cache time of page resources to at least 24 hours.

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): https ://example.com/jq.js, http:// www. example.com/jq.js, http://example.com/ jquery .js, http://example.com/ libs/ jq.js, http://example.com/jq.js ?v=3.2&a=1, 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.