브라우저 캐싱 활용

이 규칙은 PageSpeed Insights에서 서버의 응답에 캐싱 헤더가 포함되어 있지 않음을 감지하거나 리소스가 잠깐 동안만 캐시되도록 지정된 경우 트리거됩니다.

개요

네트워크를 통해 리소스를 가져오면 속도도 느리고 비용도 많이 듭니다. 즉, 다운로드하는 데 클라이언트와 서버 간에 왕복이 여러 번 발생할 수 있으며 이로 인해 처리가 지연되고 페이지 렌더링이 차단되며 방문자에게 데이터 비용이 부과될 수도 있습니다. 모든 서버 응답은 캐싱 정책을 지정해야 클라이언트에서 이전에 가져온 응답을 재사용할 수 있는지 여부와 시기를 판단하는 데 도움이 됩니다.

권장사항

각 리소스는 이 리소스가 캐시될 수 있는지, 리소스를 누가 얼마 동안 캐시할 수 있는지, 가능한 경우 캐싱 정책이 만료되면 어떻게 효율적으로 재확인될 수 있는지와 같은 질문에 부합하는 명시적인 캐싱 정책을 지정해야 합니다. 서버에서 응답을 반환할 때 Cache-ControlETag 헤더를 제공해야 합니다.

  • Cache-Control 헤더는 브라우저 및 기타 중간 캐시에서 개별 응답을 캐시할 수 있는 방법과 기간을 정의합니다. 자세히 알아보려면 Cache-Control로 캐싱을 참조하세요.
  • ETag 헤더에서는 리소스가 마지막으로 요청된 후 변경되었는지 확인하기 위해 브라우저에서 자동으로 보내는 재확인 토큰을 제공합니다. 자세히 알아보려면 ETag로 캐시된 응답의 유효성 검사를 참조하세요.

사이트에 가장 적합한 캐싱 정책을 확인하려면 다음 가이드를 참조하세요.

최소 캐시 시간은 1주일이 좋으며 정적 애셋 또는 드물게 변경되는 애셋의 경우 최대 1년이 좋습니다. 리소스가 무효화되는 시기를 정확히 관리해야 하는 경우 URL 지문이나 버전 기술을 사용하는 것이 좋습니다. 위의 캐시된 응답 무효화 및 업데이트 링크를 참조하세요.