런타임 캐싱은 '사용하는 동안' 캐시에 응답을 점진적으로 추가하는 것을 의미합니다. 런타임 캐싱은 현재 요청의 안정성에는 도움이 되지 않지만 동일한 URL에 대한 향후 요청의 안정성을 높이는 데 도움이 될 수 있습니다.
브라우저의 HTTP 캐시는 런타임 캐싱의 한 예로, 지정된 URL을 요청한 후에만 채워집니다. 하지만 서비스 워커를 사용하면 HTTP 캐시만으로 제공할 수 있는 것 이상의 런타임 캐싱을 구현할 수 있습니다.
전략적으로 접근하기
항상 캐시에서 사전 정의된 파일 집합을 제공하려고 시도하는 사전 캐싱과 달리 런타임 캐싱은 네트워크 및 캐시 액세스를 여러 방식으로 결합할 수 있습니다. 각 조합을 일반적으로 캐싱 전략이라고 합니다. 키 캐싱 전략에는 다음이 포함됩니다.
- 네트워크 중심
- 캐시 우선
- 재확인 중 비활성 상태
네트워크 중심
이 접근 방식에서 서비스 워커는 먼저 네트워크에서 응답을 검색하려고 시도합니다. 네트워크 요청이 성공하면 다행입니다. 응답이 웹 앱으로 반환되고 Cache Storage API를 사용하여 응답 사본이 저장됩니다. 즉, 새 항목을 만들거나 동일한 URL의 이전 항목을 업데이트합니다.
네트워크 요청이 완전히 실패하거나 응답을 반환하는 데 너무 오래 걸리는 경우 캐시의 가장 최근 응답이 대신 반환됩니다.
캐시 우선
캐시 우선 전략은 사실상 네트워크 우선과 반대입니다. 이 접근 방식에서는 서비스 워커가 요청을 가로챌 때 먼저 Cache Storage API를 사용하여 캐시된 응답이 있는지 확인합니다. 일치하는 항목이 있으면 응답이 웹 앱으로 반환됩니다.
하지만 캐시 부적중이 있으면 서비스 워커가 네트워크로 이동하여 응답을 검색하려고 시도합니다. 네트워크 요청이 성공하면 웹 앱으로 반환되고 캐시에 사본이 저장됩니다. 이 캐시된 사본은 다음에 동일한 URL을 요청할 때 네트워크를 우회하는 데 사용됩니다.
재확인 중 비활성 상태
비활성이지만 재검증은 하이브리드입니다. 이를 사용하면 서비스 워커가 캐시된 응답을 즉시 확인하고, 응답이 있으면 웹 앱에 다시 전달합니다.
그동안 캐시 일치 여부와 관계없이 서비스 워커는 네트워크 요청을 실행하여 '새로운' 응답을 가져옵니다. 이 응답은 이전에 캐시된 응답을 업데이트하는 데 사용됩니다. 초기 캐시 검사가 부적중인 경우 네트워크 응답 사본도 웹 앱으로 다시 전달됩니다.
Workbox를 사용해야 하는 이유는 무엇인가요?
이러한 캐싱 전략은 일반적으로 자체 서비스 워커에서 반복해서 다시 작성해야 하는 레시피에 해당합니다. 이에 의존하지 않고 Workbox는 전략 라이브러리의 일부로 패키징되어 있으므로 서비스 워커에 바로 사용할 수 있습니다.
또한 Workbox는 버전 관리도 지원하므로 캐시된 항목을 자동으로 만료하거나 이전에 캐시된 항목의 업데이트가 발생할 때 웹 앱에 알릴 수 있습니다.
어떤 애셋을 캐시해야 하며, 어떤 전략으로 캐시해야 할까요?
런타임 캐싱은 사전 캐싱을 보완하는 것으로 볼 수 있습니다. 모든 애셋이 이미 사전 캐시되었다면 완료된 것입니다. 런타임 시 캐시할 사항이 전혀 없습니다. 상대적으로 복잡한 웹 앱의 경우 모든 항목을 사전 캐싱하지는 않을 가능성이 높습니다.
대용량 미디어 파일, CDN과 같은 서드 파티 호스트에서 제공되는 애셋 또는 API 응답은 효과적으로 사전 캐시할 수 없는 애셋 유형의 몇 가지 예일 뿐입니다. DevTools의 Network 패널을 사용하여 이 카테고리에 속하는 요청을 식별하고, 각 요청에 대해 최신성과 신뢰성 중 어느 쪽이 적절한지 생각해 보세요.
재검증하는 동안 비활성을 사용하여 최신 상태보다 안정성에 우선시
오래된 재검증 전략은 거의 즉시(첫 번째 요청을 통해 캐시가 채워진 후) 캐시된 응답을 반환하므로 이 전략을 사용하면 안정적으로 빠른 성능을 얻을 수 있습니다. 이 경우 네트워크에서 가져온 응답 데이터에 비해 오래되었을 수 있는 응답 데이터를 다시 가져올 수 있다는 단점이 있습니다. 이 전략은 이전 값이더라도 즉시 어떤 것을 표시하는 것이 중요하다는 것을 알고 있을 때 사용자 프로필 이미지 또는 뷰를 채우는 데 사용되는 초기 API 응답과 같은 애셋에 가장 적합합니다.
안정성보다 최신성을 우선시하도록 네트워크 우선 사용
어떤 의미에서 네트워크 우선 전략을 사용하는 것은 네트워크와의 전투에서 패배를 인정하는 것입니다. 우선순위가 부여되기는 하지만 안정성에 대한 불확실성이 수반됩니다. 특정 유형의 애셋의 경우 최신 응답을 확인하는 것이 오래된 정보를 가져오는 것보다 낫습니다. 예를 들어 자주 업데이트되는 기사의 텍스트에 대한 API 요청을 할 때는 최신 상태를 선호할 수 있습니다.
서비스 워커 내에서 네트워크 우선 전략을 사용하면 네트워크에 직접 연결하는 대신 잠재적으로 비활성 응답일지라도 무언가로 대체할 수 있다는 이점을 얻을 수 있습니다. 속도가 느리지 않지만 오프라인 상태에서는 안정적입니다.
버전이 지정된 URL에 캐시 우선 사용
캐시 우선 전략에서는 항목이 캐시되면 절대 업데이트되지 않습니다. 따라서 변경 가능성이 작다고 판단되는 애셋에만 사용해야 합니다. 특히 버전 관리 정보가 포함된 URL, 즉 Cache-Control: max-age=31536000 응답 헤더와 함께 제공되어야 하는 동일한 종류의 URL에 가장 적합합니다.