브라우저는 어떻게 캐시 만료시간을 정하나요?

기본적으로 서버쪽에서는 response header에 “expires", "cache-control”, “max-age”, 클라이언트 쪽에서는 fetch시에 header의 cache 값을 통해 캐시의 만료, 정책 설정이 가능하다.

 

네트워크 요청시에 요청의 response header에 cache-control, expires, max-age 등을 포함해서 캐시의 만료 정책을 명확하게 나타내는 헤더 설정이 없고 last-modified 설정만 존재한다면 대부분의 브라우저는 heuristic freshness 라는 정책을 사용하여 캐시 기간을 설정한다.

 

계산식은 아래와 같다. which is the one suggested by RFC 7234

(date time - last modified time) / 10

즉 Devtool의 네트워크 탭의 response header부분에서 Date - LastModified 이후 10으로 나눈 값이 캐시의 만료 시간이다.

• 여기서 Date는 캐싱되지 않았을때의 요청 시간이며 캐싱된 요청에 대해서는 이전의 Date 요청을 그대로 반환함

이를통해 브라우저는 최근에 수정된 파일일수록 바뀔 가능성이 높으니 더욱 자주 캐시가 만료되도록 하여 최신 버전을 유지할 수 있도록 하며 오래된 파일은 바뀔 가능성이 더욱 적으니 캐시 만료 시간을 길게 계산해주어 이름그대로  heuristic 하게 캐싱 시간을 관리하는것을 알 수 있다.

 

[코드]

 

[예시]

 

예를들어위 이미지의 경우

58:41(Date) - 38:10(Last Modified) = 20:31이며 이는 1231초이고 캐시의 지속시간은 이를 10으로 나눈 123.1초이다.

실제로 테스트를 해본 결과 120초가 지나기 이전 네트워크 요청 결과는 캐싱되어 있었으며 123초 이후는 캐싱이 되지 않고 새 데이터를 받아오는것을 확인할 수 있었다.

 

계산 방식은 브라우저별로 조금씩 다를 수 있으며 아래는 각 브라우저의 계산방식이다.

• Chrome still uses the old "10% of time since last_modified", matching the RFC's suggestion
• Same goes for Safari
• Firefox nowadays uses min(one week, (current time - last modified time) / 10). So freshness is never more than one week