웹사이트를 운영하다보면 웹사이트의 디자인이나 프론트엔드 동작을 바꾸기 위해서 CSS 또는 javascript 파일을 수정하는 일이 종종 생기게 된다. 이때 수정된 파일을 서버로 배포하더라도, 기존 웹사이트를 이용하던 유저의 브라우저 캐쉬때문에 수정된(fresh) 파일을 다운로드 하지 않고 캐쉬를 이용하게되어 웹사이트가 깨져보이게되는 경우가 있다.
사용중인 웹서버에서 특정 파일에대한 캐쉬설정을 적절히 바꿔서 Http Response Header에 캐쉬관련 지시자나 E-Tag 등이 잘 포함되게 설정해주면, 브라우저에서 expired 된 캐쉬가 사용되는 것을 적절히 막을 수 있지만, 직접 웹서버를 운영하지 않고 웹 호스팅서비스를 이용하는 경우 쉽지 않은 일이며, 정확하게 설정되지 않을경우 브라우저마다 미묘하게 동작이 달라서 원하는 결과를 완벽하게 얻지 못할때도 있다.
오래된 캐쉬(stale cache) 사용 막으려면?
이런 상황에서 캐쉬문제를 해결하기 위해서 가장 확실하고 간단한 방법은 캐쉬 자체의 기본 동작 방식을 역이용하는 것이다.
기본적으로 캐쉬의 동작은 URL을 기준으로 기존에 동일한URL에 요청한 적이 있었는지를 판단하게 된다. 쉽게 바꿔말하면, 해당 수정된 파일의 URL을 바꿔주면 기존의 캐쉬에 의해 영향을 받지 않을 수 있게 되는 것이다.
URL을 바꾸는 방법
무식한 방법: 수정이 그리 자주되지 않는 파일이라면, 해당 수정된 CSS/JS 파일명을 아예 바꿔버리고, 해당 파일을 로딩하는 HTML 코드쪽에서도 수정된 파일명을 넣어주면 된다.
좀더 스마트한 방법: 위 방법이 번거로울 경우 CSS/JS 파일명은 유지하는 대신 HTML 코드쪽에서 불러올때 버전 쿼리스트링을 붙여주는 방법이 매우 유용하다. 다음 예시를 살펴보자.
<link href="http://example.com/custom.css" rel="stylesheet" type="text/css" />
<link href="http://example.com/custom.css?ver=1.1" rel="stylesheet" type="text/css" />
위 코드의 경우 custom.css 파일이 수정되더라도, 적절한 캐쉬 지시자가 적용되지 않은경우 기존 웹사이트 이용하던 유저들이 수정된파일이 아닌 캐쉬된 파일을 보게될 확률이 크다. 이를 해결한 아래 코드를 보자.
위 코드의 경우 ?ver=1.1 이라고 파일명 뒤에 쿼리스트링을 붙여주었다. custom.css를 수정한 후, 번거롭게 파일명을 바꾸는 대신 ver 값만 다르게 주면 다른 URL로 인식되기 때문에 캐쉬된 파일이 사용되는것을 방지할 수 있다.
조금 더 응용한다면, server side 프로그램에서 해당 HTML 코드를 출력할때 ver 대신 해당 파일의 modified date가 자동으로 쿼리스트링으로 붙도록 개발해둘 경우, 수정되는 즉시 자동으로 반영되는 편리함을 누릴 수 있을것이다.