HTTP 캐싱을 사용하면 재방문 시 페이지 로드 시간을 단축할 수 있습니다.
브라우저가 리소스를 요청할 때 리소스를 제공하는 서버는 리소스를 임시 저장 또는 캐시해야 하는 기간. 해당 리소스에 대한 후속 요청의 경우 브라우저는 네트워크에서 가져오는 대신 로컬 사본을 사용합니다.
Lighthouse 캐시 정책 감사가 실패하는 경우
등대 캐시되지 않은 모든 정적 리소스에 플래그를 지정합니다.
Lighthouse는 리소스가 캐시 가능한 것으로 간주함 다음과 같은 조건이 모두 충족되는 경우입니다.
- 리소스가 글꼴, 이미지, 미디어 파일, 스크립트 또는 스타일시트입니다.
- 리소스에
200,203또는206HTTP 상태 코드가 있습니다. - 리소스에 명시적인 캐시 없음 정책이 없습니다.
페이지가 감사에 실패하면 Lighthouse는 3개의 열이 있는 테이블에 결과를 나열합니다.
| URL | 캐시 가능한 리소스의 위치 |
| 캐시 TTL | 리소스의 현재 캐시 기간 |
| 전송 크기 | 플래그가 지정된 리소스가 캐시된 경우 사용자가 저장할 데이터에 대한 추정치 |
HTTP 캐싱을 사용하여 정적 리소스를 캐시하는 방법
Cache-Control HTTP 응답 헤더를 반환하도록 서버를 구성합니다.
Cache-Control: max-age=31536000
max-age 지시문은 리소스를 얼마 동안 캐시해야 하는지 초 단위로 브라우저에 알려줍니다.
다음 예시에서는 기간을 1년에 해당하는 31536000로 설정합니다.
60초 × 60분 × 24시간 × 365일 = 3,153,6000초
변경할 수 없는 정적 자산을 오랫동안 캐시해야 합니다. 지정할 수 있습니다
리소스 변경 및 최신성이 중요한 경우 no-cache 사용
그러나 여전히 캐싱의 속도 이점을 몇 가지 얻고 싶을 수 있습니다.
브라우저는 여전히 no-cache로 설정된 리소스를 캐시합니다.
하지만 먼저 서버에 확인하여 리소스가 여전히 최신 상태인지 확인합니다.
캐시 기간이 긴 것이 항상 더 좋은 것은 아닙니다. 결국 리소스에 가장 적합한 캐시 기간을 결정하는 것은 사용자의 몫입니다.
브라우저가 여러 리소스를 캐시하는 방식을 맞춤설정하기 위한 많은 지시문이 있습니다. 리소스 캐싱에 대한 자세한 내용은 다음을 참고하세요. HTTP 캐시: 첫 번째 방어 가이드 및 HTTP 캐싱 동작 구성 Codelab을 참조하세요.
Chrome DevTools에서 캐시된 응답을 확인하는 방법
브라우저가 캐시로부터 어떤 리소스를 가져오는지 확인하려면 Chrome DevTools에서 네트워크 탭을 엽니다.
[댓글]: <> (다음 목록은 web.dev에서 가져온 쇼트코드이지만 영어에서 어떤 언어로도 번역되지 않았습니다.)
1. Control+Shift+J (Mac의 경우 Command+Option+J)를 눌러 DevTools를 엽니다.
2. Network 탭을 클릭합니다.
Chrome DevTools의 크기 열을 사용하면 리소스가 캐시되었는지 확인할 수 있습니다.
Chrome은 메모리 캐시에서 가장 많이 요청되는 리소스를 브라우저가 닫히면 지워집니다.
리소스의 Cache-Control 헤더가 예상대로 설정되었는지 확인하려면 다음 안내를 따르세요.
HTTP 헤더 데이터를 확인합니다.
- 요청 표의 이름 열에서 요청의 URL을 클릭합니다.
- Headers(헤더) 탭을 클릭합니다.
</ph>
<ph type="x-smartling-placeholder">Cache-Control 헤더를 검사합니다.
스택별 안내
Drupal
관리 > 브라우저 및 프록시 캐시 최대 기간을 설정합니다. 구성 > 개발 페이지 Drupal 성능 리소스를 참고하세요.
Joomla
캐시를 참조하세요.
WordPress
브라우저 캐싱을 참고하세요.