이 규칙은 PageSpeed Insights에서 서버의 응답에 캐싱 헤더가 포함되어 있지 않음을
감지하거나 리소스가 잠깐 동안만 캐시되도록 지정된 경우 트리거됩니다.
개요
네트워크를 통해 리소스를 가져오면 속도도 느리고 비용도 많이 듭니다. 즉, 다운로드하는 데 클라이언트와
서버 간에 왕복이 여러 번 발생할 수 있으며 이로 인해 처리가 지연되고 페이지 렌더링이 차단되며
방문자에게 데이터 비용이 부과될 수도 있습니다. 모든 서버 응답은 캐싱 정책을 지정해야 클라이언트에서
이전에 가져온 응답을 재사용할 수 있는지 여부와 시기를 판단하는 데 도움이 됩니다.
권장사항
각 리소스는 이 리소스가 캐시될 수 있는지, 리소스를 누가 얼마 동안
캐시할 수 있는지, 가능한 경우 캐싱 정책이 만료되면 어떻게 효율적으로 재확인될 수 있는지와 같은 질문에
부합하는 명시적인 캐싱 정책을 지정해야 합니다. 서버가 응답을 반환할 때 Cache-Control 및 ETag 헤더를 제공해야 합니다.
Cache-Control은 브라우저 및 기타 중간 캐시에서 개별 응답을 캐시할 수 있는 방법과 기간을 정의합니다. 자세한 내용은
Cache-Control로 캐싱을 참고하세요.
ETag는 리소스가 마지막으로 요청된 후 변경되었는지 확인하기 위해 브라우저에서 자동으로 전송하는 재검증 토큰을 제공합니다. 자세한 내용은
ETag로 캐시된 응답의 유효성 검사를 참조하세요.
[null,null,["최종 업데이트: 2025-07-25(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,["# Leverage Browser Caching\n\n| **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\n### Overview\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\n### Recommendations\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--------\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)."]]
