Stay organized with collections
Save and categorize content based on your preferences.
This rule triggers when PageSpeed Insights detects that the response from your server does not
include caching headers or if the resources are specified to be cached for only a short time.
Overview
Fetching resources over the network is both slow and expensive: the download may require multiple
roundtrips between the client and server, which delays processing and may block rendering of page
content, and also incurs data costs for the visitor. All server responses should specify a caching
policy to help the client determine if and when it can reuse a previously fetched response.
Recommendations
Each resource should specify an explicit caching policy that answers the following questions:
whether the resource can be cached and by whom, for how long, and if applicable, how it can be
efficiently revalidated when the caching policy expires. When the server returns a response it
must provide the Cache-Control and ETag headers:
Cache-Control defines how, and for how long the individual response can be
cached by the browser and other intermediate caches. To learn more, see
caching with Cache-Control.
ETag provides a revalidation token that is automatically sent by the browser
to check if the resource has changed since the last time it was requested. To learn more, see
validating cached responses with ETags.
To determine the optimal caching policy for your site, please use the following guides:
We recommend a minimum cache time of one week and preferably up to one year for static assets, or
assets that change infrequently. If you need precise control over when resources are invalidated
we recommend using a URL fingerprinting or versioning technique - see invalidating and updating cached
responses link above.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-09-03 UTC."],[[["\u003cp\u003eThis information is outdated as it pertains to a deprecated version of PageSpeed Insights API (version 4) which is no longer supported.\u003c/p\u003e\n"],["\u003cp\u003eSlow server response times and inefficient caching negatively impact web page performance.\u003c/p\u003e\n"],["\u003cp\u003eServers should utilize \u003ccode\u003eCache-Control\u003c/code\u003e and \u003ccode\u003eETag\u003c/code\u003e headers to establish an effective caching policy for resources.\u003c/p\u003e\n"],["\u003cp\u003eA minimum cache time of one week, extending up to a year, is recommended for static or infrequently changing assets.\u003c/p\u003e\n"],["\u003cp\u003eFor resources requiring more precise invalidation, URL fingerprinting or versioning techniques are suggested.\u003c/p\u003e\n"]]],["Server responses should include caching headers to enable efficient resource reuse. Resources should have an explicit caching policy specifying if, by whom, and for how long they can be cached, along with efficient revalidation when the policy expires. Use `Cache-Control` to define caching behavior and `ETag` for revalidation. A minimum cache time of one week is recommended, with up to one year for static assets. Use URL fingerprinting for precise control over resource invalidation.\n"],null,["| **Deprecated** . This page was written for version 4 of the PageSpeed Insights API, which is deprecated and will be shut down in May 2019. [Version 5](/speed/docs/insights/v5/get-started) is the latest and provides both real-world data from the Chrome User Experience Report and lab data from Lighthouse.\n\n\nThis rule triggers when PageSpeed Insights detects that the response from your server does not\ninclude caching headers or if the resources are specified to be cached for only a short time.\n\nOverview\n\n\nFetching resources over the network is both slow and expensive: the download may require multiple\nroundtrips between the client and server, which delays processing and may block rendering of page\ncontent, and also incurs data costs for the visitor. All server responses should specify a caching\npolicy to help the client determine if and when it can reuse a previously fetched response.\n\nRecommendations\n\n\nEach resource should specify an explicit caching policy that answers the following questions:\nwhether the resource can be cached and by whom, for how long, and if applicable, how it can be\nefficiently revalidated when the caching policy expires. When the server returns a response it\nmust provide the `Cache-Control` and `ETag` headers:\n\n- `Cache-Control` defines how, and for how long the individual response can be cached by the browser and other intermediate caches. To learn more, see [caching with Cache-Control](/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control).\n- `ETag` provides a revalidation token that is automatically sent by the browser to check if the resource has changed since the last time it was requested. To learn more, see [validating cached responses with ETags](/web/fundamentals/performance/optimizing-content-efficiency/http-caching#validating-cached-responses-with-etags).\n\n\nTo determine the optimal caching policy for your site, please use the following guides:\n\n- [Defining optimal Cache-Control policy](/web/fundamentals/performance/optimizing-content-efficiency/http-caching#defining-optimal-cache-control-policy)\n- [Invalidating and updating cached responses](/web/fundamentals/performance/optimizing-content-efficiency/http-caching#invalidating-and-updating-cached-responses)\n- [Caching checklist](/web/fundamentals/performance/optimizing-content-efficiency/http-caching#caching-checklist)\n\n\nWe recommend a minimum cache time of one week and preferably up to one year for static assets, or\nassets that change infrequently. If you need precise control over when resources are invalidated\nwe recommend using a URL fingerprinting or versioning technique - see invalidating and updating cached\nresponses link above.\n\nFeedback\n\nWas this page helpful? \nYes Great! Thank you for the feedback. If you have a specific, answerable question about using PageSpeed Insights, ask the question in English on [Stack\n| Overflow](https://stackoverflow.com/questions/tagged/pagespeed-insights). For general questions, feedback, and discussion, start a thread in the [mailing list](https://groups.google.com/forum/#!forum/pagespeed-insights-discuss).\nNo Sorry to hear that. If you have a specific, answerable question about using PageSpeed Insights, ask the question in English on [Stack\n| Overflow](https://stackoverflow.com/questions/tagged/pagespeed-insights). For general questions, feedback, and discussion, start a thread in the [mailing list](https://groups.google.com/forum/#!forum/pagespeed-insights-discuss)."]]
