웹 Cache Control 헤더 공부
09/14
캐시
웹 성능을 최대한 끌어올리기 위해선 HTTP 캐시를 적극적으로 사용해야 한다
HTTP 캐시를 효율적으로 관리하려면 Cache-control 헤더를 섬세하게 다뤄야 한다
완전히 첫 요청인 경우 서버와 브라우저는 완전한 요청/응답을 전달한다
이후 요청부터는 cache-control 헤더에 따라 리소스의 생명주기가 결정된다
- max-age : max-age= 를 지정하면 초 동안 서버에 요청하지 않고 디스크 또는 메모리에서만 캐시를 가져와 사용한다. 서버에 요청하지 않기 때문에 한번 캐시되면 지우기 힘들기 때문에 매우 신중해야하는 헤더이다 유효기간이 지나면 캐시를 지우는것이 아니라,
if-modified-since와If-none-match헤더를 담아서 재검증을 요청한다. 재검증을 통해 유효한 경우 서버로부터 304 응답을 받고 브라우저는 캐시된 리소스를 다시 사용하고, 그렇지 않은 경우 서버는 200과 함께 리소스를 다시 내려준다 두 값은 이전 응답의 응답헤더에서 가져온다-
if-modified-since : 캐시된 리소스가 마지막으로 수정된 시간 이후로 수정되었는지 체크
-
if-none-match: 캐시된 리소스의 Etag 가 서버 리소스의 Etag 와 같은지 체크
- Etag 는 누가 만드는거임? → 서버가
- Etag는 어떻게 만드는거임? → 리소스 자체를 활용해서 만듬. Strong Etag (해시값으로 생성) 과 Weak ETag(마지막 수정시간 활용)이 있다.
- Etag는 언제 주는거임? → 아무조건 없이 항상 서버에서 만들어서 응답헤더에 포함해서 보내준다.max-age=0 으로 하면 매번 재검증을 기대하지만 일부 모바일 브라우저의 경우 네트워크 요청을 아끼기 위해 브라우저를 종료하기 전까지 리소스를 만료시키지 않는 경우도 있어 이 경우에는 no-cache 를 사용하는것이 좋다
-
- no-cache: 캐시를 사용안한다는게 아니다. 캐시는 저장하지만 요청시마다 마찬가지로 재검증을 한다
- no-store: 캐시를 절대 사용해서 안되는 리소스일때 사용한다. 어떤 경우에도 캐시를 저장하지 않는다
근데 캐시는 어디에 저장됨? → 내 컴퓨터 하드디스크 또는 메모리. JS나 CSS 처럼 비교적 큰 파일은 디스크에, 이미지나 폰트는 메모리에 저장해서 빠르게 불러올수 있게 한다
CDN invalidation
CDN 과 같은 중간 서버를 사용할 때, CDN 에서 리소스를 캐시할 수 있다. CDN invalidation 은 CDN 의 캐시를 삭제한다는 뜻이다.
CDN invalidation 은 누가 하는거임? → Cloudflare, AWS CloudFront, Google Cloud CDN 등 CDN 서비스 사업자가 콘솔, CLI 로 기능 제공함
- public : 모든 사람과 중간 서버가 캐시를 저장할 수 있음
- private: 맨 끝에 있는 브라우저만 캐시를 저장할 수 있음
- s-maxage: 중간 서버의 캐시 유효기간
토스는 Cache-Control을 어떻게 사용하나?
HTML 파일
배포시마다 내용이 바뀔수 있다
max-age=0, s-maxage=31536000
브라우저는 항상 재검증 요청, CDN 은 1년 캐시. 대신 배포가 이루어질 때마다 CDN invalidation 실행
JS,CSS 파일
빌드 결과물마다 달라지도록 URL 중간에 빌드별로 임의의 버전번호를 붙임
max-age=31536000 사용.
어차피 빌드하면 URL 이 달라지기 때문에, URL 에 대해 1년의 캐시를 걸어도 무방함
