서비스 워커 및 Cache Storage API

Jeff Posnick

네트워크 안정성을 유지하기 위해 애쓰고 있습니다. 브라우저의 HTTP 캐시는 첫 번째 방어선이지만, 앞서 배운 것처럼 이전에 방문한 버전이 지정된 URL을 로드할 때만 효과적입니다. HTTP 캐시만으로는 충분하지 않습니다.

다행히 서비스 워커와 Cache Storage API라는 두 가지 최신 도구를 사용하여 이 문제를 해결할 수 있습니다. 두 가지를 함께 사용하는 경우가 많으므로 둘 다 한 번에 알아보는 것이 좋습니다.

서비스 워커

서비스 워커는 브라우저에 내장되며 개발자가 만들어야 하는 약간의 추가 JavaScript 코드로 제어됩니다. 실제 웹 애플리케이션을 구성하는 다른 파일과 함께 배포합니다.

서비스 워커에는 몇 가지 특별한 권한이 있습니다. 웹 앱이 외부로 요청을 보내기를 기다린 후 가로채서 작업을 시작합니다. 서비스 워커가 이 가로채기된 요청으로 무엇을 할지는 개발자가 결정합니다.

일부 요청의 경우 서비스 워커가 전혀 없는 경우와 마찬가지로 요청이 네트워크로 계속 전달되도록 허용하는 것이 가장 좋습니다.

하지만 다른 요청의 경우 브라우저의 HTTP 캐시보다 더 유연한 것을 활용하고 네트워크에 관해 걱정하지 않고도 안정적으로 빠른 응답을 반환할 수 있습니다. 이를 위해서는 다른 한 부분인 Cache Storage API를 사용해야 합니다.

Cache Storage API

Cache Storage API는 개발자가 캐시의 콘텐츠를 완전히 제어할 수 있도록 하여 완전히 새로운 가능성을 열어줍니다. Cache Storage API는 HTTP 헤더와 브라우저의 내장 휴리스틱 조합을 사용하는 대신 캐싱에 코드 기반 접근 방식을 노출합니다. Cache Storage API는 서비스 워커의 JavaScript에서 호출될 때 특히 유용합니다.

잠깐만요. 고려해야 할 다른 캐시가 있나요?

'HTTP 헤더를 계속 구성해야 하나요?', '이 새 캐시로 HTTP 캐시에서 할 수 없었던 작업을 할 수 있나요?'와 같은 질문을 던지셨을 겁니다. 이는 자연스러운 반응이니 걱정하지 마세요.

Cache Storage API를 사용하고 있는 것으로 확인되었더라도 웹 서버에서 Cache-Control 헤더를 구성하는 것이 좋습니다. 일반적으로 버전이 지정되지 않은 URL에는 Cache-Control: no-cache를, 해시와 같은 버전 관리 정보가 포함된 URL에는 Cache-Control: max-age=31536000를 설정하면 됩니다.

Cache Storage API 캐시를 채울 때 브라우저는 HTTP 캐시에서 기본적으로 기존 항목을 확인하고, 항목이 있는 경우 이를 사용합니다. Cache Storage API 캐시에 버전이 지정된 URL을 추가하면 브라우저에서 추가 네트워크 요청을 방지합니다. 반대로 구성이 잘못된 Cache-Control 헤더를 사용하면(예: 버전이 지정되지 않은 URL에 장기 캐시 수명을 지정) Cache Storage API에 오래된 콘텐츠를 추가하여 상황을 악화시킬 수 있습니다. HTTP 캐시 동작을 정렬하는 것은 Cache Storage API를 효과적으로 사용하기 위한 기본 요건입니다.

이 새로운 API로 이제 무엇이 가능한가요? 한마디로 대단히 많은 작업이 가능합니다. HTTP 캐시만으로는 어렵거나 불가능한 일반적인 용도에는 다음이 포함됩니다.

• 캐시된 콘텐츠에 '백그라운드에서 새로고침' 접근 방식(stale-while-revalidate라고 함)을 사용합니다.
• 캐시할 최대 애셋 수에 한도를 적용하고 한도에 도달하면 항목을 삭제하는 맞춤 만료 정책을 구현합니다.
• 이전에 캐시된 네트워크 응답과 최신 네트워크 응답을 비교하여 변경사항이 있는지 확인하고 데이터가 실제로 업데이트되면 사용자가 버튼을 사용하여 콘텐츠를 업데이트할 수 있도록 합니다.

자세한 내용은 Cache API: 빠른 가이드를 참고하세요.

API 기본사항

API 설계와 관련하여 유의해야 할 몇 가지 사항이 있습니다.

• Request 객체는 이러한 캐시를 읽고 쓸 때 고유 키로 사용됩니다. 편의를 위해 실제 Request 객체 대신 'https://example.com/index.html'와 같은 URL 문자열을 키로 전달할 수 있으며 API에서 자동으로 처리합니다.
• Response 객체는 이러한 캐시의 값으로 사용됩니다.
• 데이터를 캐시할 때 지정된 Response의 Cache-Control 헤더는 사실상 무시됩니다. 자동으로 내장된 만료 또는 최신성 검사는 없으며 항목을 캐시에 저장하면 코드에서 명시적으로 삭제할 때까지 유지됩니다. 캐시 유지관리를 간소화하는 라이브러리가 있습니다. 이 내용은 이 시리즈의 뒷부분에서 다룹니다.)
• LocalStorage와 같은 이전 동기식 API와 달리 모든 Cache Storage API 작업은 비동기식입니다.

빠른 우회: 약속 및 async/await

서비스 워커와 Cache Storage API는 비동기 프로그래밍 개념을 사용합니다. 특히 비동기 작업의 향후 결과를 나타내기 위해 약속에 크게 의존합니다. 시작하기 전에 promise 및 관련 async/await 문법을 숙지해야 합니다.

아직 코드를 배포하지 마세요.

서비스 작업자와 Cache Storage API는 중요한 기반을 제공하며 있는 그대로 사용할 수 있지만, 둘 다 여러 가지 특이 사례와 '함정'이 있는 효과적으로 하위 수준의 빌딩 블록입니다. 이러한 API의 어려운 부분을 원활하게 처리하고 프로덕션 준비가 완료된 서비스 워커를 빌드하는 데 필요한 모든 것을 제공하는 상위 수준의 도구가 있습니다. 다음 가이드에서는 이러한 도구 중 하나인 Workbox를 다룹니다.