HTTP 캐싱을 사용하면 재방문 시 페이지 로드 시간이 빨라질 수 있습니다.
브라우저에서 리소스를 요청할 때 리소스를 제공하는 서버는 리소스를 일시적으로 저장하거나 캐시해야 하는 기간을 브라우저에 알려줄 수 있습니다. 이후 해당 리소스에 대한 모든 후속 요청의 경우 브라우저는 네트워크에서 리소스를 가져오는 대신 로컬 사본을 사용합니다.
Lighthouse 캐시 정책 감사 실패 방법
Lighthouse는 캐시되지 않은 모든 정적 리소스를 표시합니다.
Lighthouse는 다음 조건이 모두 충족되면 리소스를 캐시 가능한 것으로 간주합니다.
- 리소스는 글꼴, 이미지, 미디어 파일, 스크립트 또는 스타일시트입니다.
- 리소스에
200,203또는206HTTP 상태 코드가 있습니다. - 리소스에 명시적 캐시 없음 정책이 없습니다.
페이지가 감사에 실패하면 Lighthouse는 다음 3개 열이 포함된 표에 결과를 나열합니다.
| URL | 캐시 가능한 리소스의 위치 |
| 캐시 TTL | 리소스의 현재 캐시 기간 |
| 전송 크기 | 신고된 리소스가 캐시된 경우 사용자가 저장할 데이터의 추정치 |
HTTP 캐싱을 사용하여 정적 리소스를 캐시하는 방법
Cache-Control HTTP 응답 헤더를 반환하도록 서버를 구성합니다.
Cache-Control: max-age=31536000
max-age 지시어는 리소스를 캐시해야 하는 시간을 초 단위로 브라우저에 알려줍니다.
다음 예에서는 기간을 31536000로 설정하며, 이는 1년에 해당합니다. 60초 × 60분 × 24시간 × 365일 = 31,536,000초입니다.
변경할 수 없는 정적 애셋을 장기간(예: 1년 이상) 캐시해야 합니다.
리소스 변경과 최신 상태가 중요하지만 여전히 캐싱의 속도 이점을 누리고 싶다면 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을 클릭합니다.
- 헤더 탭을 클릭합니다.
Cache-Control 헤더를 검사합니다.
스택별 안내
Drupal
관리 > 구성 > 개발 페이지에서 브라우저 및 프록시 캐시 최대 기간을 설정합니다. Drupal 성능 리소스를 참고하세요.
Joomla
캐시를 참조하세요.
WordPress
브라우저 캐싱을 참고하세요.