네트워크 안정성 때문에 고군분투하고 있습니다. 브라우저의 HTTP 캐시는 첫 번째 방어선이지만, 앞서 살펴본 바와 같이 버전이 지정된 URL을 로드할 때만 효과가 있습니다. HTTP 캐시 자체로는 충분하지 않습니다.
다행히 상황을 전환하는 데 도움이 되는 두 가지 최신 도구인 서비스 워커와 Cache Storage API를 사용할 수 있습니다. 이 둘은 함께 사용되는 경우가 너무 많으므로 동시에 두 가지 개념을 배우는 것이 좋습니다.
서비스 워커
서비스 워커는 브라우저에 내장되어 있으며 개발자가 만들어야 하는 약간의 추가 자바스크립트 코드로 제어됩니다. 이를 실제 웹 애플리케이션을 구성하는 다른 파일과 함께 배포합니다.
서비스 워커에는 특별한 능력이 있습니다. 그 밖에도 웹 앱이 발신 요청을 할 때까지 끈기 있게 대기했다가 요청을 가로채서 작업을 시작합니다. 서비스 워커가 이 가로채기된 요청으로 무엇을 수행할지는 개발자가 결정합니다.
일부 요청의 경우 최상의 조치는 서비스 워커가 전혀 없을 때 발생하는 것과 마찬가지로 요청이 네트워크로 계속 진행되도록 허용하는 것일 수 있습니다.
하지만 다른 요청의 경우 브라우저의 HTTP 캐시보다 유연한 기능을 활용하고 네트워크에 대해 걱정할 필요 없이 안정적으로 빠른 응답을 반환할 수 있습니다. Cache Storage API도 필요합니다.
Cache Storage API
Cache Storage API는 개발자가 캐시의 콘텐츠를 완전히 제어할 수 있도록 하여 완전히 새로운 가능성을 열어줍니다. Cache Storage API는 HTTP 헤더와 브라우저에 내장된 heuristics의 조합을 사용하는 대신 코드 중심의 캐싱 접근 방식을 사용합니다. 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에 추가하여 상황이 더 악화될 수 있습니다. Cache Storage API를 효과적으로 사용하려면 HTTP 캐시 동작을 정렬해야 합니다.
이 새로운 API로 무엇을 할 수 있는지에 대한 답은 많습니다. HTTP 캐시만으로는 어렵거나 불가능한 일반적인 용도는 다음과 같습니다.
- 캐시된 콘텐츠에 '백그라운드에서 새로고침' 접근 방식(비활성 상태 재검증이라고 함)을 사용합니다.
- 캐시할 최대 애셋 수에 한도를 적용하고 한도에 도달하면 항목을 삭제하는 커스텀 만료 정책을 구현합니다.
- 이전에 캐시된 최신 네트워크 응답을 비교하여 변경된 사항이 있는지 확인하고 데이터가 실제로 업데이트되었을 때 사용자가 버튼 등을 사용하여 콘텐츠를 업데이트할 수 있도록 합니다.
자세한 내용은 Cache API: 빠른 가이드를 참고하세요.
API 너트 및 볼트
API의 설계와 관련하여 유의해야 할 몇 가지 사항이 있습니다.
Request객체는 이러한 캐시를 읽고 쓸 때 고유 키로 사용됩니다. 편의상 실제Request객체 대신'https://example.com/index.html'와 같은 URL 문자열을 키로 전달할 수 있습니다. 그러면 API가 자동으로 이를 처리합니다.Response객체는 이러한 캐시의 값으로 사용됩니다.- 지정된
Response의Cache-Control헤더는 데이터를 캐싱할 때 사실상 무시됩니다. 기본 제공되는 자동 만료 또는 최신성 검사는 없으며 캐시에 항목을 저장하면 코드에서 명시적으로 삭제할 때까지 항목이 유지됩니다. (캐시 유지관리를 간소화하는 라이브러리가 있습니다. 이에 대해서는 이 시리즈의 후반부에서 다룹니다.) LocalStorage와 같은 이전 동기 API와 달리 모든 Cache Storage API 작업은 비동기식입니다.
빠른 우회: promise 및 async/await
서비스 워커와 Cache Storage API는 비동기 프로그래밍 개념을 사용합니다.
특히 비동기 작업의 향후 결과를 나타내는 프로미스에 크게 의존합니다. 본격적으로 시작하기 전에 프로미스 및 관련 async/await 구문을 숙지해야 합니다.
아직 코드를 배포하지 마세요.
서비스 워커와 Cache Storage API 모두 중요한 기반을 제공하고 있는 그대로 사용할 수 있지만, 여러 특이 사례와 '문제'가 있는 사실상 하위 수준의 구성요소입니다. 이러한 API의 어려운 부분을 원활하게 처리하고 프로덕션에 즉시 사용 가능한 서비스 워커를 빌드하는 데 필요한 모든 기능을 제공하는 상위 수준 도구가 있습니다. 다음 가이드에서는 이러한 도구 중 하나인 Workbox를 다룹니다.