Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

서비스 워커 및 Cache Storage API

Jeff Posnick

네트워크 안정성을 확보하기 위해 고군분투하고 있습니다. 브라우저의 HTTP 캐시는 첫 번째 방어선이지만, 이미 알고 있듯이 이전에 방문한 버전이 지정된 URL을 로드할 때만 효과적입니다. HTTP 캐시만으로는 충분하지 않습니다.

다행히도 상황을 유리하게 바꿀 수 있는 두 가지 최신 도구인 서비스 워커와 Cache Storage API를 사용할 수 있습니다. 이 두 가지는 함께 사용되는 경우가 많으므로 동시에 학습하는 것이 좋습니다.

서비스 워커

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

서비스 워커에는 몇 가지 특별한 기능이 있습니다. 다른 작업 중에서도 웹 앱이 발신 요청을 할 때까지 기다렸다가 이를 가로채서 작업을 시작합니다. 서비스 워커가 이 가로챈 요청으로 무엇을 할지는 개발자에게 달려 있습니다.

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

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

Cache Storage API

Browser Support

Source

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을 추가하면 브라우저에서 추가 네트워크 요청을 피할 수 있습니다. 반대로, 버전이 지정되지 않은 URL에 긴 캐시 수명을 지정하는 등 잘못 구성된 Cache-Control 헤더를 사용하는 경우 오래된 콘텐츠를 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는 비동기 프로그래밍 개념을 사용합니다. 특히 비동기 작업의 향후 결과를 나타내기 위해 프로미스에 크게 의존합니다. 시작하기 전에 프로미스 및 관련 async/await 문법을 숙지해야 합니다.

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

서비스 워커와 Cache Storage API는 중요한 기반을 제공하고 있는 그대로 사용할 수 있지만, 여러 극단적인 사례와 '주의사항'이 있는 사실상 하위 수준의 구성요소입니다. 이러한 API의 어려운 부분을 원활하게 처리하고 프로덕션에 즉시 사용 가능한 서비스 워커를 빌드하는 데 필요한 모든 것을 제공하는 상위 수준 도구가 있습니다. 다음 가이드에서는 이러한 도구 중 하나인 Workbox를 다룹니다.