HTTP Caching에 대해서 정리해 봅니다. #Cache

오늘은 HTTP Caching에 대해서 정리해 보도록 하겠습니다.

 

1. HTTP Caching?

매번 Server에 같은 파일에 대해서 요청하는 것은,

Server에 부담이 될 뿐만이 아니라,

다운로드 되는 속도때문에 매번 로딩하는 시간이 걸리게 됩니다.

 

그래서, 리소스의 복사본을저장해 놓고,

같은 파일에 대해 Request를 할 때,

다시 똑같은 요청을 하지 않고 기존의 저장된 파일을 이용하도록 하는 기술이,

Caching인데요.

 

2. HTTP Caching 설정하는 방법

Http Caching를 설정하기 위해서는,

아래와 같이 Cache-Control 헤더를 사용해 주면 되는데요.

설정할 수 있는 값들에 대해서 알아보도록 하겠습니다.

Cache-Control: no-store

 

2-1. Cache사용여부에 관한 설정

A. no-store

no-store로 설정하면, Cache를 사용하지 않는다는 의미입니다.

 

B. no-cache
no-cache로 설정하면, 이름이 no-cache라서 Cache를 사용하지 않는다는 의미라고 오해할 수 있는데요.
Cache를 허용하되, 매번 리소스의 유효성을 판단해서 유효하다고 할 때만 Cache를 이용한다는 것 입니다.

Cache-Control: no-cache

 

 

C. public

End-User인 브라우저뿐만이 아니라,

중간에 경유하는 Proxy서버들에서도 Cache를 할 수 있도록 허용하는 것 입니다.

proxy서버에서도 Caching을 허용한다는 것 입니다.

Google의 페이지를 보면, public으로 되어있는 것을 볼 수 있습니다.

Cache-Control: public

 

D. private

public과는 반대되는 의미로,

proxy에서 Caching을 허용하지 않는다는 의미입니다.

중간의 서버에도 저장되서는 않되는 중요한 정보들을 이렇게 설정하겠지요.

Cache-Control: private

 

2-2. 유효기간과 관련한 설정 값들

Cache를 사용할 때 해당 Cache의 기한을 설정해 줄 수 있는데요.

아래와 같은 지시어들로 설정할 수 있습니다.

 

A. max-age=초

max-age에 초 단위의 형식으로 유효기간을 지정할 수 있는데요.

아래는 1년동안 유효하도록 캐쉬가 유효하도록 설정해 주는 것 입니다.

만약, 하루동안만 유효하도록 하려면, 86400(60 초 x 60 분 x 24 시간)으로 하면 되겠지요.

참고로, Cache-Control헤더 값을 no-store로 해주면, "max-age=0"을 의미합니다.

Cache-Control: max-age=31536000

 

 

다만, 위와 같이 유효기간을 1년과 같이 길게 설정하게 되면, 유효기간동안에는 업데이트하더라도,

유저는 업데이트 내용을 받지 않고, 저장된 Cache를 사용하게되는 문제가 발생하게 될 수 있으므로,

주의를 요해서 사용해야 겠지요.

 

B. Last-Modifed

Origin 서버의 리소스가 마지막으로 언제 수정되었는지의 정보를 헤더로 알려주는 것 인데요.

이 값을 참고해서 Cache를 사용하지 않고 서버에 Request할 것인지를 정할 수 있습니다.

Last-Modified: May, 5 Nov 2020 12:45:26 GMT

 

C. Expires

Response가 오래되서 유효하지 않다고 판단할 수 있는 기준일을 표시하는 것 인데요.

이 시간을 기준으로 이미 Cache가 있다면, 그것을 사용할지 아니면,

서버에게 Request를 할지 정하게 됩니다.

참고로, 만약 Cache-Control헤더에 max-age값이 있다면 Expires값은 무시되게 됩니다.

Expires: Sat, 01, Jan 1970 22:00:00 GMT

 

그리고 Expires에서 1년 이상을 사용하는 것은 표준규약에 어긋나는 일이므로,

특별한 경우를 제외하고는 사용하지 않는것이 좋습니다.

 

D. Etag

시간이 아닌, 일정한 token값을 서버로부터 발급받아서,

해당 리소스가 유효한지를 확인하는 방법도 있는데요.

아래와 같이 etag값을 사용하는 것 입니다.

ETag에는 서버가 주는 랜덤한 문자로 구성된 아래와 같은 토큰값이 들어가 있는데요.

이를 통해 전에 Caching된 리소스와 같은 리소스인지 확인할 수 있는 것 이지요.

etag:W/"5eb371f3-378f5"

 

 

ETag가 일치하지 않아서,

유효한 정보가 아니라면, 오래된 Resource로 보고 서버에게 Request를 날리고,

반대로 아직 유효한 정보라면, Cache를 이용하는 것 이지요.

 

2-3. 유효성에 체크에 대한 설정

A. must-revalidate

리소스가 오래되었다고 판단되면,

Origin서버에서 유효하다고 하는지 체크해서 Cache를 사용할 지 결정합니다.

 

2-4. Static 애셋들에 대해 긴 Cache 설정

만약 특별히 변할 것이 없는 Image나 CSS, JS파일이라면,

아래와 같이 1년정도를 맥시멈으로 하는 public 으로 설정해 줄 수 있습니다.

Cache-Control:public; max-age=31536000
Expires: Mon, 25 May 2021 21:31:12 GMT

3. Google의 개발자가 에서 제시한 최적의 Cache 사용

아래는 Google의 개발자가 글에서 제시한 최적의 Cache-Control 정책인데요.

이미지가 조금 복잡해 보이지만, 3가지 정도 사항을 점검해서 사용하면 됩니다.

 

Cache에 저장해놓고 사용할 리소스인지,

저장해 놓고 사용할 리소스라면, 매번 유효성을 확인할 필요가 있는지를 검토한 후에,

Proxy에서의 Cache사용선택 후에,

max-age와 ETag를 붙여서 사용하라는 것 인데요.

 

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching

 

4. Cache-Control과 브라우저 호환성 문제

위에서 Cache-Control에 대한 설정값들을 보았는데요.

모든 브라우저에서 호환되는 Cache-Contrl설정값은 어떻게 지정해 주어야 할까요?

가볍게만 알아보고 가겠습니다.

왜냐하면, 국내 포털사이트 같은 곳에서 Cache-Control값을 보면,

위에서 정리한 것과는 조금 다르게 설정되어 있기 때문인데요.

 

이것은 IE6같은 브라우저 같은 하위 호화성을 위한 것인데요.,

즉 과거의 HTTP규약을 따르거나 혹은 독자적으로 동작하는 브라우저에서도 Cache를 사용하지 않도록 하기 위해서는,

아래와 같이 설정해서 사용하는 경우가 많습니다.

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

 

사실 HTTP 1.1스펙에 따라서,

호환성 때문에 이리저리 뒤섞인 기존의 포털사의 Header를 보면서,

연구하는 것이 도움이 될지 머리만 아프게 할지는 잘 모르겠습니다만,

역시나 IE6부터 시작된 호환성 문제는 아직도 포털사 Header에 남아 있다는 것을 알 수 있습니다.

 

5. 리소스 업데이트와 Caching에 관한 팁

5-1. 리소스 네임을 버전별로 다르게 할 것

Caching정책을 어떻게 정하더라도 예상과 다르게 교체해야할 경우가 생기게 됩니다.

이때 파일이름을 버전별로 다르게 해 주면, 이러한 일을 쉽게 처리할 수 있습니다.

예를 들면, 아래와 같이 파일명을 저장해 주면 되겠지요.

 

후에, img_logo_200530_v2파일을 급하게 올려서,

유저가 Caching된 파일을 사용되지 않도록 할 수 있겠습니다.

그럼 파일이 변경되어서, Caching된 리소스는 사용되지 않으므로 업데이트 문제를 쉽게 해결할 수 있습니다.

굳이 "_"를 사용하지 않고 "."으로 구분해서 문제는 없습니다.

img_logo_200530_v1.png

 

물론, "www.test.com"과 같이 메인 도메인에 대한 Cache-Control은 no-cache, no-store, must-revalidate로 해서,

Caching을 하지 않도록 해주어야 위와 같은 방법이 효율적일 수 있는 것 이겠지요.

 

5-2. 자주 바뀌는 부분은 파일로 분리 할 것

자주 바뀌는 부분에 대해서는 다른 파일로 분리하여서 업데이트 하도록 하는 것이 좋습니다.

자주 바뀌는 부분과 그렇지 않은 부분이 뒤섞여 있다면,

Caching에 있어서 비효율이 발생하게 되겠지요.

 

이상으로 HTTP Caching에 대한 정리를 해 보았구요.

더 좋은 내용이 있으면 이 글을 통해서 업데이트 하도록 하겠습니다.