서비스 워커 캐싱과 응답 전략

두 단계: 저장하고, 응답한다

저장

flowchart LR
  a["install 또는 런타임"] --> b["caches.open(name)"] --> c["cache.add/addAll/put"]

응답

flowchart LR
  a["fetch 이벤트"] --> b["event.respondWith()"]
  b --> c1["캐시"]
  b --> c2["네트워크"]
  b --> c3["만든 응답"]

서비스 워커 자체의 등록·생명주기는 서비스 워커 등록·스코프·생명주기와 업데이트에, 미디어를 중요도별로 나눠 캐시하고 캐시 크기를 제한하는 방법은 PWA와 서비스 워커 캐시 전략에 있다. HTTP 캐시와의 관계는 HTTP 캐시를 본다.

Cache Storage API

Cache Storage는 요청과 응답 쌍을, 서버가 보낸 헤더와 본문 그대로 저장한다. 요청 URL이나 Request 객체가 키다. 창(메인 스레드), 서비스 워커, 다른 워커 모두에서 caches로 접근하고, 대부분 HTTPS가 필요하다. 모든 주요 브라우저가 지원한다.

Cache Storage는 서버 쪽 변경을 알아채지도, 오래된 항목을 지우지도 않는다. 둘 다 코드가 책임진다. URL도 하나하나 명시해야 한다. API가 필요한 파일을 추측해 주지 않는다.

무엇을 언제 캐시하나

다른 시점도 된다. 첫 페이지 로드 직후, 사용자가 특정 섹션에 들어갈 때, 네트워크가 한가할 때다. 오프라인에 쓸 자산은 미리 캐시해 둬야 한다. 오프라인이 된 뒤에는 받을 수 없다.

• 설치 때 전부 캐시하지 않는다. 대역폭과 저장 공간을 낭비하고 낡은 파일을 내보내게 된다.
• 항상 최신이어야 하는 리소스는 캐시하지 않는 편이 낫다.
• 모든 PWA가 완전한 오프라인을 지원할 필요는 없다(클라우드 게임, 실시간 시세 등). 대신 브라우저 기본 오류 페이지는 절대 보이지 않게 오프라인 안내 화면을 준다. Google Play에 올린 PWA가 HTTP 오류 페이지를 보이면 불이익을 받을 수 있다.

// install 단계 프리캐시
const PRECACHE = 'app-v3';
const urls = ['/', '/app.js', '/styles.css', '/logo.svg', '/offline.html'];
 
self.addEventListener('install', (event) => {
  event.waitUntil(caches.open(PRECACHE).then((cache) => cache.addAll(urls)));
});
 
// activate 단계에서 현재 버전이 아닌 캐시를 지운다
self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then((names) =>
      Promise.all(names.filter((n) => n !== PRECACHE).map((n) => caches.delete(n)))
    )
  );
});

새 서비스 워커를 설치해도 옛 캐시는 저절로 지워지지 않는다. 캐시 이름에 버전을 붙이고 activate에서 정리한다.

캐시에 넣는 시점: 세분한 패턴

Cache Storage도 출처의 공용 할당량을 나눠 쓰고, 저장 공간이 부족하면 지워질 수 있다. 지켜야 할 데이터는 navigator.storage.persist()로 영속 저장을 요청한다(PWA 오프라인 데이터와 저장소 관리).

다른 출처의 응답: 불투명 응답

CDN처럼 다른 출처에서 CORS 없이 받은 응답은 불투명 응답(opaque response) 으로 저장된다.

• 본문과 헤더를 읽을 수 없고, 상태 코드도 알 수 없어 실패 응답이 캐시될 수 있다.
• 실제 크기를 드러내지 않으려고 브라우저가 항목마다 큰 고정 크기로 할당량을 계산한다. 작은 파일 몇 개로 할당량이 빠르게 찬다.
• addAll()에 서드 파티 URL을 섞으면, 그 CDN 하나가 2xx를 못 줄 때 같은 호출의 성공한 다운로드까지 전부 버려진다.

CORS를 지원하는 CDN이면 crossorigin 요청으로 받아 일반 응답으로 저장한다(CORS).

응답하기: fetch 이벤트

self.addEventListener('fetch', (event) => {
  // event.request.url, method, mode, destination, headers를 보고 판단
  event.respondWith(responseOrPromise);
});

잘못된 응답 하나가 앱의 HTML 문서 로드를 막을 수 있다. 내비게이션 요청 처리는 특히 조심하고, 막히면 Shift + 새로고침으로 서비스 워커를 우회해 고친다.

다섯 가지 캐시 전략

// 캐시 우선
event.respondWith(
  caches.match(event.request).then((cached) => cached || fetch(event.request))
);
 
// 네트워크 우선
event.respondWith(
  fetch(event.request).catch(() => caches.match(event.request))
);
 
// stale-while-revalidate
event.respondWith(
  caches.open('runtime').then(async (cache) => {
    const cached = await cache.match(event.request);
    const network = fetch(event.request).then((res) => {
      if (res.ok) cache.put(event.request, res.clone()); // 본문은 한 번만 읽히므로 clone
      return res;
    });
    return cached || network;
  })
);

• Stale-while-revalidate는 캐시가 맞아도 항상 네트워크 요청을 보낸다. 갱신된 내용은 다음 요청에서야 보인다.
• 전략은 URL 패턴별로 다르게 고른다. event.request.url을 정규식으로 보거나 URLPattern을 쓴다. URLPattern은 2025년 9월부터 Baseline이다.
• 직접 만든 전략도 된다. 예: 네트워크 우선이되 3초가 지나면 캐시로 응답하기, 캐시와 네트워크 응답을 합치기.
• 업데이트 확인 때문에 렌더링을 막지 않는다. Core Web Vitals를 해친다(웹 성능 지표와 Lighthouse).

다섯 가지 밖의 패턴

Promise.race()는 먼저 거부된 Promise에도 끝나 버리므로 경주에는 Promise.any()(ES2021)를 쓴다.

오프라인 대체 페이지

self.addEventListener('fetch', (event) => {
  if (event.request.mode !== 'navigate') return;
  event.respondWith(
    fetch(event.request).catch(() => caches.match('/offline.html'))
  );
});

문서 요청(mode: 'navigate' 또는 destination: 'document')이 실패하면 프리캐시한 /offline.html을, 이미지가 실패하면 대체 이미지를 준다. 나머지는 Response.error()로 둔다.

Workbox

Workbox는 서비스 워커의 라우팅·캐시 전략·프리캐시·만료를 감싼 Google의 라이브러리 묶음이다. 여러 프레임워크의 PWA 플러그인이 내부에서 쓴다.

import { registerRoute } from 'workbox-routing';
import { NetworkFirst, CacheFirst } from 'workbox-strategies';
import { CacheableResponsePlugin } from 'workbox-cacheable-response';
import { ExpirationPlugin } from 'workbox-expiration';
 
registerRoute(({ request }) => request.mode === 'navigate',
  new NetworkFirst({ cacheName: 'pages' }));
 
registerRoute(({ request }) => request.destination === 'image',
  new CacheFirst({
    cacheName: 'images',
    plugins: [
      new CacheableResponsePlugin({ statuses: [0, 200] }),
      new ExpirationPlugin({ maxEntries: 60, maxAgeSeconds: 30 * 24 * 60 * 60 }),
    ],
  }));

npm 모듈을 import로 쓰면 배포 전에 번들링한다. 모듈 서비스 워커를 지원하지 않는 브라우저도 있어서다.

자산 업데이트 방식

새 자산은 보통 다음 실행 때 쓴다. 지금 세션에서 바로 바꾸는 라이브 업데이트는 복잡하다.

페이지를 조각으로 캐시하기

서비스 워커 인클루드

페이지를 바뀌는 주기가 다른 조각으로 나누고, 조각마다 다른 전략으로 캐시한 뒤 서비스 워커에서 다시 조립한다. 캐시가 작아지고 머리글·바닥글이 페이지마다 같은 버전으로 보인다.

앱 셸과 스트리밍

SPA의 앱 셸(app shell) 모델은 껍데기 HTML을 캐시해 즉시 보여 주고 내용은 클라이언트가 채운다. 앱 셸은 UI를 띄우는 최소한의 HTML·CSS·JS로, 네이티브 앱이라면 스토어에 올릴 번들에 해당한다. 툴바·카드 틀 같은 의미 있는 화면을 네트워크 없이 그리고 내용은 점진적으로 채운다.

• 첫 방문은 서버가 내용까지 렌더링해 보내고, 그 페이지가 서비스 워커를 등록해 셸과 의존 자산을 캐시한다. 다음 방문부터는 셸을 캐시에서 띄우고 데이터만 요청한다.
• 셸의 핵심 CSS는 <head>에 인라인하고, 뷰별 JS는 비동기로 받는다. 파일 이름에 해시를 넣어 긴 HTTP 캐시와 버전 관리를 함께 한다.
• 서비스 워커를 쓰지 못하는 환경에는 서버 렌더링 페이지를 그대로 준다(점진적 향상).
• 동적인 앱일수록 이득이 크다. 작고 정적인 사이트는 셸 없이 install에서 사이트 전체를 캐시하면 된다.
• 과거에는 sw-precache·sw-toolbox로 셸을 캐시했고, 지금은 그 후속인 Workbox를 쓴다. 서비스 워커에서 Streams API로 캐시한 셸 + 네트워크 본문을 하나의 응답 스트림으로 이어 보내면, 브라우저가 첫 조각부터 점진적으로 그려 MPA처럼 빠르게 뜬다. Streams API는 저수준이라 workbox-streams를 쓰는 편이 쉽다. 서버 쪽 스트리밍은 스트리밍 SSR을 본다.

SPA와 MPA

둘 다 PWA가 될 수 있고 섞어도 된다(상품 목록은 MPA, 결제 흐름은 SPA). 서비스 워커가 CSS·JS를 캐시하면 MPA의 약점인 페이지마다 다시 받는 비용이 줄어든다. 렌더링 방식 비교는 SPA와 CSR·SSR에 있다.

정리

• Cache Storage는 요청·응답 쌍 저장소다. 갱신과 삭제는 전부 코드가 한다.
• 프리캐시는 UI를 그리는 최소한과 오프라인 대체 페이지만. 나머지는 런타임 캐시로.
• respondWith()는 동기적으로 부르고, 응답을 저장하면서 돌려줄 때는 clone()한다.
• URL 종류마다 전략을 고른다: 문서는 네트워크 우선, 해시 붙은 정적 자산은 캐시 우선, 부수 콘텐츠는 stale-while-revalidate.
• 서드 파티 불투명 응답과 addAll()의 원자성을 조심한다. 코드가 길어지면 Workbox로 옮긴다.

관련 노트: 서비스 워커 등록·스코프·생명주기와 업데이트, PWA와 서비스 워커 캐시 전략, PWA 오프라인 데이터와 저장소 관리, HTTP 캐시, 리소스 힌트와 미리 불러오기, 스트리밍 SSR