“Cache Storage”, 인터넷이 느린데 사이트는 왜 이렇게 빨리 뜰까?

들어가며

웹사이트를 처음 방문했을 때는 이미지도 많고 파일도 많아서 로딩이 조금 느린데, 같은 페이지를 다시 열어보면 갑자기 빨라지는 경우가 있습니다.

특히 이미지가 많은 사이트나 웹 애플리케이션을 사용하다 보면 “방금 전에 봤던 파일을 어디에 저장해둔 건가?”라는 생각이 들기도 합니다.

이때 웹 브라우저에서 활용하는 기능 중 하나가 바로 Cache Storage입니다.

개발자 도구를 사용하다 보면 Application 탭 안에서 Cookies, Local Storage, Session Storage와 함께 Cache Storage라는 항목을 볼 수 있습니다.

그런데 막상 Cache Storage를 클릭해보면 이름부터 생소하고, 안에 Cache Storage라는 저장공간과 여러 파일이 표시되면서 정확히 무엇을 의미하는지 헷갈릴 수 있습니다.

오늘은 개발자 도구에서 Cache Storage가 무엇인지, 어디에서 확인할 수 있는지, 그리고 웹 개발에서 어떤 역할을 하는지 하나씩 알아보겠습니다.

Cache Storage란 무엇일까?

Cache Storage는 웹 브라우저에서 Cache 객체를 저장하고 관리하기 위한 저장 공간입니다.

특히 Service Worker와 함께 사용되는 경우가 많습니다.

일반적인 브라우저 캐시와 비슷하게 들리지만, 개발자가 JavaScript와 Service Worker를 통해 보다 직접적으로 관리할 수 있다는 점에서 차이가 있습니다.

예를 들어 웹사이트에서 자주 사용하는 이미지나 HTML, CSS, JavaScript 등의 리소스를 Cache Storage에 저장해두고 다음에 필요할 때 다시 사용할 수 있습니다.

간단하게 생각하면 이런 구조입니다.

웹페이지 요청
   ↓
Service Worker
   ↓
Cache Storage 확인
   ↓
저장된 리소스가 있다면
   ↓
캐시에서 응답

물론 실제 서비스에서는 캐시 전략에 따라 동작 방식이 달라질 수 있습니다.

하지만 핵심은 네트워크에서 매번 같은 데이터를 가져오지 않고 미리 저장해둔 리소스를 활용할 수 있다는 것입니다.

개발자 도구에서 Cache Storage 찾기

크롬 브라우저에서 웹사이트를 열고 F12를 누르면 개발자 도구가 나타납니다.

상단에서 Application 탭을 선택합니다.

왼쪽 메뉴를 살펴보면 Storage 영역이 있습니다.

여기에서 다음과 같은 항목들을 확인할 수 있습니다.

Storage
 ├─ Local Storage
 ├─ Session Storage
 ├─ IndexedDB
 ├─ Cookies
 └─ Cache Storage

여기에서 Cache Storage를 펼쳐보면 현재 웹사이트에서 생성한 Cache가 표시될 수 있습니다.

사이트에 따라 아무것도 표시되지 않을 수도 있습니다.

이 부분이 중요합니다.

Cache Storage가 모든 웹사이트에 항상 존재하는 것은 아닙니다.

Service Worker를 이용하거나 Cache Storage API를 사용하는 웹사이트에서 주로 확인할 수 있습니다.

따라서 본인이 개발 중인 웹사이트에서 Cache Storage가 비어 있다고 해서 반드시 문제가 있는 것은 아닙니다.

Cache Storage 안에는 무엇이 들어 있을까?

Cache Storage를 열어보면 사이트에 따라 Cache 이름이 표시됩니다.

예를 들어 다음처럼 보일 수 있습니다.

Cache Storage
 └─ my-cache
     ├─ /
     ├─ /index.html
     ├─ /style.css
     ├─ /app.js
     └─ /images/logo.png

여기서 Cache 이름은 개발자가 Service Worker 코드에서 지정한 이름일 수 있습니다.

그리고 해당 Cache를 선택하면 저장된 요청과 응답 정보를 확인할 수 있습니다.

웹사이트가 어떤 리소스를 캐시에 저장했는지 확인할 수 있기 때문에 개발할 때 상당히 유용합니다.

특히 “Service Worker가 제대로 캐시를 저장하고 있는지” 확인할 때 자주 사용하게 됩니다.

Service Worker와 Cache Storage의 관계

Cache Storage를 이야기하면서 Service Worker를 빼놓기 어렵습니다.

Service Worker는 웹페이지와 별도로 백그라운드에서 동작할 수 있는 웹 브라우저의 기능입니다.

네트워크 요청을 가로채거나 캐시를 관리하는 등의 작업에 활용할 수 있습니다.

예를 들어 Service Worker에서 다음과 같이 Cache를 열 수 있습니다.

const cache = await caches.open("my-cache");

그리고 특정 요청을 캐시에 저장할 수 있습니다.

await cache.add("/index.html");

이렇게 저장된 데이터는 개발자 도구의 Cache Storage에서 확인할 수 있습니다.

즉,

Service Worker가 캐시를 관리하고 Cache Storage가 그 데이터를 저장하는 공간

이라고 생각하면 이해하기 쉽습니다.

Cache Storage와 일반 브라우저 캐시는 같은 것일까?

여기서 처음 공부할 때 가장 많이 헷갈리는 부분이 있습니다.

Cache Storage와 우리가 흔히 이야기하는 “브라우저 캐시”는 완전히 같은 개념으로 생각하면 안 됩니다.

브라우저는 웹페이지의 성능을 높이기 위해 HTTP 캐시 등 다양한 형태의 캐싱을 사용합니다.

반면 Cache Storage API는 웹 애플리케이션이 Cache 객체를 이용해 요청과 응답을 저장하고 관리할 수 있도록 제공되는 저장 공간입니다.

그래서 개발자 도구에서도 별도로 Cache Storage라는 항목으로 확인할 수 있습니다.

개발자가 직접 캐시 전략을 구현하는 PWA(Progressive Web App) 같은 서비스에서는 특히 중요한 기능입니다.

Cache Storage가 필요한 이유

그렇다면 굳이 데이터를 캐시에 저장하는 이유는 무엇일까요?

가장 큰 이유는 웹 애플리케이션의 성능과 오프라인 대응입니다.

예를 들어 앱에서 항상 같은 CSS와 JavaScript 파일을 서버에서 다시 받아야 한다면 불필요한 네트워크 요청이 계속 발생할 수 있습니다.

자주 변경되지 않는 리소스를 캐시에 저장해두면 네트워크 요청을 줄이고 더 빠르게 화면을 구성할 수 있습니다.

또한 적절한 캐싱 전략을 사용하면 인터넷 연결이 불안정하거나 일시적으로 끊긴 상황에서도 일부 기능을 사용할 수 있도록 만들 수 있습니다.

이런 특성 때문에 PWA와 같은 웹 애플리케이션에서 Cache Storage가 많이 활용됩니다.

캐시 전략도 중요하다

Cache Storage를 사용한다고 해서 무조건 모든 데이터를 저장하면 좋은 것은 아닙니다.

오히려 잘못된 캐시 전략 때문에 오래된 파일이 계속 표시되는 문제가 발생할 수도 있습니다.

예를 들어 개발 중 JavaScript 파일을 수정했는데 브라우저에서는 이전 버전의 파일이 계속 실행되는 상황이 생길 수 있습니다.

이럴 때 개발자 입장에서는 “분명 코드를 수정했는데 왜 반영이 안 되지?”라는 생각이 들 수 있습니다.

Service Worker가 이전 파일을 캐시하고 있다면 Cache Storage를 확인해볼 필요가 있습니다.

특히 캐시 이름에 버전을 붙이는 방법도 많이 사용합니다.

caches.open("my-cache-v2");

새로운 버전의 캐시를 만들고 이전 캐시를 정리하는 방식으로 리소스 버전을 관리할 수 있습니다.

개발자 도구에서 Cache Storage 삭제하기

개발 중 캐시 때문에 문제가 발생했다면 개발자 도구에서 저장된 Cache를 확인하고 삭제할 수도 있습니다.

Application 탭의 Cache Storage에서 특정 Cache를 선택한 후 삭제 기능을 이용할 수 있습니다.

이렇게 하면 개발 환경에서 오래된 캐시가 문제를 일으키는지 확인하는 데 도움이 됩니다.

Service Worker를 함께 사용하는 프로젝트라면 Application 탭의 Service Workers 영역도 같이 확인하는 것이 좋습니다.

캐시만 삭제했는데도 이전 코드가 계속 실행된다면 Service Worker의 등록 상태나 업데이트 과정까지 확인해야 할 수 있습니다.

Cache Storage와 다른 저장소의 차이

지금까지 살펴본 저장소들과 비교하면 각각의 목적이 조금씩 다릅니다.

Cookies
→ 서버와의 통신 및 상태 유지 등에 활용

Local Storage
→ 브라우저에 비교적 지속적으로 데이터 저장

Session Storage
→ 현재 세션 동안 데이터 저장

IndexedDB
→ 구조화된 대량의 데이터 저장

Cache Storage
→ 요청과 응답 등의 리소스를 캐싱

이렇게 보면 각각의 역할이 조금 더 명확해집니다.

특히 Cache Storage는 단순히 문자열 값을 저장하는 Local Storage와는 목적 자체가 다릅니다.

웹 리소스와 요청, 응답을 캐시하는 데 특화되어 있다는 점을 기억하면 됩니다.

Cache Storage를 확인해야 하는 상황

실제 개발을 하다 보면 Cache Storage를 직접 확인해야 하는 상황이 생각보다 자주 생깁니다.

대표적인 것이 수정한 코드가 브라우저에 반영되지 않을 때입니다.

CSS를 수정했는데 예전 스타일이 계속 적용되거나 JavaScript를 수정했는데 이전 코드가 실행되는 경우가 있습니다.

물론 이런 문제의 원인이 항상 Cache Storage인 것은 아닙니다.

HTTP 캐시나 Service Worker, 빌드 시스템 등 다른 원인도 있을 수 있습니다.

하지만 Service Worker를 사용하는 웹사이트라면 Application 탭에서 Cache Storage를 확인하는 것은 좋은 출발점이 될 수 있습니다.

특히 개발자 도구의 Application 탭을 열어놓고 Storage와 Service Workers를 함께 살펴보면 캐시 관련 문제를 찾기가 훨씬 쉬워집니다.

마무리

Cache Storage는 처음 보면 이름만으로는 정확히 어떤 역할을 하는지 이해하기 어렵습니다.

하지만 개발자 도구에서 직접 열어보면 생각보다 단순한 구조라는 것을 알 수 있습니다.

Application → Storage → Cache Storage

이 경로로 들어가면 현재 웹사이트가 사용하고 있는 Cache를 확인할 수 있습니다.

그리고 Service Worker를 사용하는 프로젝트라면 Cache Storage에 어떤 리소스가 저장되어 있는지 직접 살펴보는 습관을 들이는 것이 좋습니다.

특히 “코드는 분명 수정했는데 화면에서는 예전 파일이 실행된다”거나 “오프라인에서도 일부 페이지가 동작한다” 같은 상황을 이해하려면 Cache Storage와 Service Worker의 관계를 알아두는 것이 도움이 됩니다.

웹 브라우저의 저장 공간은 Cookies, Local Storage, Session Storage, IndexedDB, Cache Storage처럼 각각 목적이 다릅니다.

처음에는 이름만 봐서는 비슷해 보이지만 개발을 하면서 하나씩 직접 확인해보면 어떤 데이터를 어디에 저장해야 하는지 감이 잡히기 시작합니다.

개발자 도구의 Application 탭은 단순히 저장된 데이터를 보는 곳이 아닙니다.

웹 애플리케이션이 브라우저를 어떻게 활용하고 있는지 확인할 수 있는 중요한 개발 도구이기도 합니다.

Cache Storage까지 익혀두면 Service Worker와 PWA를 공부할 때도 훨씬 수월하게 이해할 수 있습니다.