“Cache-Control”, 웹사이트가 빠르게 뜨는 이유?

들어가며

웹사이트를 이용하다 보면 이상하게 두 번째 방문부터 페이지가 빨라지는 경우가 있습니다.

처음 접속했을 때는 조금 기다렸는데 다시 들어가 보니 금방 화면이 나타나는 식입니다.

물론 서버가 빨라졌을 수도 있지만, 여기에는 캐시(Cache)가 관련되어 있을 가능성이 있습니다.

웹페이지를 개발하거나 API 통신을 확인하다 보면 크롬 개발자 도구의 Network 탭에서 Cache-Control이라는 항목을 자주 볼 수 있습니다.

처음에는 그냥 여러 HTTP 헤더 중 하나라고 생각하기 쉽습니다.

그런데 조금 더 자세히 들여다보면 Cache-Control은 브라우저나 중간 캐시가 특정 리소스를 얼마나 오래 사용해도 되는지, 다시 서버에 요청해야 하는지 등을 제어하는 중요한 HTTP 헤더입니다.

오늘은 개발자 도구에서 보이는 Cache-Control을 기준으로 캐시가 어떤 방식으로 동작하는지 쉽게 정리해보겠습니다.

Cache-Control이란?

Cache-Control은 말 그대로 캐시를 제어하기 위한 HTTP 헤더입니다.

브라우저가 서버에 데이터를 요청하면 서버는 응답을 보내면서 여러 가지 HTTP 헤더를 함께 전달합니다.

그중 Cache-Control은 브라우저나 캐시 서버에게 해당 응답을 어떻게 캐싱할 것인지 알려주는 역할을 합니다.

예를 들어 서버 응답에서 다음과 같은 내용을 볼 수 있습니다.

Cache-Control: max-age=3600

이 값을 단순하게 해석하면 해당 응답을 일정 시간 동안 캐시에 저장해두고 사용할 수 있다는 의미입니다.

3600초는 1시간이므로, 캐시의 유효기간을 1시간으로 설정한 경우라고 볼 수 있습니다.

이렇게 캐시를 적절하게 사용하면 매번 서버에 동일한 데이터를 요청할 필요가 없어집니다.

결과적으로 서버 요청을 줄이고 웹페이지를 더 빠르게 표시하는 데 도움이 됩니다.

개발자 도구에서는 어디에서 확인할까?

크롬 브라우저를 사용한다면 먼저 개발자 도구를 열어봅니다.

F12를 누르거나 웹페이지에서 마우스 오른쪽 버튼을 클릭한 후 검사를 선택하면 됩니다.

그다음 상단의 Network 탭으로 이동합니다.

페이지를 새로고침하면 브라우저가 서버에 요청한 다양한 파일과 데이터가 목록에 표시됩니다.

HTML 파일부터 JavaScript, CSS, 이미지, 폰트, API 요청까지 여러 항목이 나타납니다.

여기서 원하는 요청을 클릭한 뒤 Headers 항목을 살펴보면 요청 헤더와 응답 헤더를 확인할 수 있습니다.

Cache-Control은 보통 Response Headers 영역에서 확인하게 됩니다.

예를 들어 다음과 같은 형태입니다.

cache-control: public, max-age=3600

또는

cache-control: no-cache

처럼 표시될 수 있습니다.

여기서 중요한 점은 Cache-Control의 값에 따라 캐시 동작 방식이 달라진다는 것입니다.

max-age는 무엇일까?

Cache-Control에서 가장 자주 보게 되는 값 중 하나가 max-age입니다.

예를 들어

Cache-Control: max-age=600

이라고 되어 있다면 600초 동안 해당 응답을 캐시에서 사용할 수 있다는 의미로 이해할 수 있습니다.

600초는 10분입니다.

따라서 같은 리소스를 다시 요청할 때 캐시가 유효한 상황이라면 브라우저가 저장된 데이터를 활용할 수 있습니다.

물론 실제 브라우저의 캐시 처리에는 다른 조건과 헤더 등이 함께 영향을 줄 수 있기 때문에 max-age 하나만 보고 모든 동작을 단정해서는 안 됩니다.

하지만 웹사이트의 캐시 정책을 파악할 때 가장 먼저 확인하기 좋은 값 중 하나인 것은 분명합니다.

no-cache라고 되어 있으면 캐시를 사용하지 않는 것일까?

이 부분에서 처음 개발자 도구를 보는 사람들이 많이 헷갈립니다.

no-cache라는 이름만 보면 “캐시를 사용하지 마세요”라는 의미처럼 보입니다.

하지만 HTTP의 의미는 조금 다릅니다.

no-cache는 저장 자체를 금지한다기보다는 캐시된 응답을 사용하기 전에 서버에 재검증하도록 요구하는 의미로 이해하는 것이 정확합니다.

즉, 캐시에 저장되어 있더라도 그것을 바로 사용하지 않고 서버에 현재 상태가 유효한지 확인하는 과정이 필요할 수 있습니다.

반면 no-store는 의미가 다릅니다.

no-store는 응답을 캐시에 저장하지 않도록 지시하는 데 사용됩니다.

따라서 개발자 도구에서 다음 두 값을 발견했다고 해서 같은 의미로 보면 안 됩니다.

Cache-Control: no-cache

Cache-Control: no-store

둘은 캐싱과 관련된 동작에서 차이가 있습니다.

public과 private도 자주 보인다

Cache-Control을 살펴보다 보면 public이나 private이라는 값도 볼 수 있습니다.

public은 해당 응답이 공유 캐시에 저장될 수 있음을 나타내는 지시어입니다.

반대로 private은 일반적으로 특정 사용자에게 맞춰진 응답처럼 공유 캐시에 저장하면 안 되는 콘텐츠에 사용됩니다.

예를 들어 로그인한 사용자의 개인정보가 포함된 페이지라면 모든 사용자가 공유하는 캐시에 저장되는 것은 적절하지 않을 수 있습니다.

이런 상황에서는 캐시 정책을 신중하게 설정해야 합니다.

왜 Cache-Control이 중요한가?

웹사이트 입장에서 캐시는 성능과 상당히 밀접한 관계가 있습니다.

모든 요청을 매번 원본 서버까지 보내야 한다면 서버에 상당한 요청이 발생할 수 있습니다.

특히 이미지, CSS, JavaScript처럼 여러 사용자가 반복해서 요청하는 정적 파일은 캐시를 적절하게 활용하면 서버의 부담을 줄이는 데 도움이 됩니다.

사용자 입장에서도 마찬가지입니다.

이미 다운로드한 리소스를 캐시에서 사용할 수 있다면 불필요한 네트워크 요청을 줄일 수 있기 때문에 페이지 로딩 속도 개선에 도움이 될 수 있습니다.

그래서 웹사이트 성능을 확인할 때 Network 탭에서 단순히 파일 크기나 응답 시간만 보는 것이 아니라 캐시 관련 헤더까지 확인해보는 경우가 많습니다.

직접 확인해보면 생각보다 재미있다

Cache-Control은 글로만 보면 조금 딱딱하게 느껴질 수 있습니다.

그래서 직접 확인해보는 것이 가장 좋습니다.

아무 웹사이트나 열고 F12를 눌러 개발자 도구를 실행한 다음 Network 탭으로 이동해보세요.

페이지를 새로고침하고 아무 요청이나 하나 선택합니다.

그리고 Headers → Response Headers를 살펴봅니다.

여기에서 cache-control을 찾아보면 해당 서버가 어떤 캐시 정책을 전달하고 있는지 확인할 수 있습니다.

같은 사이트에서도 HTML과 JavaScript, 이미지, API 응답의 Cache-Control 설정이 서로 다른 경우가 있습니다.

오히려 이 차이를 하나씩 비교해보는 것이 웹사이트가 어떻게 구성되어 있는지 이해하는 데 도움이 됩니다.

Cache-Control만 보고 모든 것을 판단하면 안 되는 이유

한 가지 주의할 점도 있습니다.

개발자 도구에서 Cache-Control을 발견했다고 해서 그것만으로 실제 캐시 동작을 전부 판단할 수 있는 것은 아닙니다.

브라우저 캐시뿐만 아니라 CDN이나 프록시 같은 중간 캐시가 사용될 수도 있고, ETag, Last-Modified, Expires 같은 다른 HTTP 헤더도 캐시 검증 과정에 영향을 줄 수 있습니다.

따라서 웹사이트의 캐시 문제를 확인할 때는 Cache-Control 하나만 보는 것보다 Network 탭의 전체 요청 흐름과 관련 헤더를 함께 살펴보는 것이 좋습니다.

마무리

처음 개발자 도구의 Network 탭을 열면 영어로 된 항목이 너무 많아서 무엇을 봐야 할지 막막할 수 있습니다.

하지만 하나씩 살펴보면 각각의 항목이 웹 브라우저와 서버 사이에서 어떤 역할을 하는지 알 수 있습니다.

Request Method가 서버에 어떤 방식으로 요청했는지를 보여주는 항목이라면, Cache-Control은 서버가 응답을 캐시와 관련해 어떻게 처리하도록 지시하는지를 보여주는 중요한 HTTP 헤더라고 생각하면 이해하기 쉽습니다.

특히 max-age, no-cache, no-store, public, private 정도만 먼저 익혀두어도 개발자 도구에서 Cache-Control을 발견했을 때 훨씬 수월하게 내용을 파악할 수 있습니다.

웹 개발이나 API 분석을 공부하고 있다면 앞으로 Network 탭을 볼 때 Request Method만 확인하지 말고 Cache-Control도 한 번씩 살펴보세요.

처음에는 단순한 영어 문구처럼 보였던 HTTP 헤더가 조금씩 웹사이트의 동작을 설명해주는 정보로 보이기 시작할 것입니다.