Workbox로 런타임 캐싱

런타임 캐싱은 '사용하는 동안' 캐시에 응답을 점진적으로 추가하는 것을 의미합니다. 런타임 캐싱은 현재 같은 URL에 대한 이후 요청의 신뢰성을 높이는 데 도움이 될 수 있습니다.

브라우저의 HTTP 캐시는 런타임 캐싱의 예입니다. 그냥 채워져 있습니다 가 표시됩니다. 그러나 서비스 워커를 사용하면 HTTP 캐시만 제공할 수 있는 것 이상의 런타임 캐싱을 할 수 있습니다

프리캐싱과는 대조적으로 캐시에서 사전 정의된 파일 집합을 제공하기 위해) 런타임 캐싱은 네트워크 및 캐시 액세스를 다양한 방식으로 지원합니다. 각 조합은 일반적으로 캐싱 전략이라고 합니다. 주요 캐싱 전략에는 다음이 포함됩니다.

  • 네트워크 중심
  • 캐시 우선
  • 재검증 중 비활성

네트워크 중심

이 접근 방식에서는 서비스 워커가 먼저 않습니다. 네트워크 요청이 성공하면 좋습니다. 응답은 요청하며, 응답의 사본은 Cache Storage를 사용하여 저장됩니다. API—새 항목을 만들거나 동일한 항목의 이전 항목을 업데이트합니다. URL입니다.

페이지에서 서비스 워커로, 서비스 워커에서 네트워크로 이동하는 요청을 보여주는 다이어그램 네트워크 요청이 실패하므로 요청이 캐시로 이동합니다.

네트워크 요청이 완전히 실패하거나 시간이 너무 오래 걸림 캐시의 가장 최근 응답이 반환되면 하세요.

캐시 우선

캐시 우선 전략은 사실상 네트워크 우선과 반대입니다. 이 서비스 워커가 요청을 가로챌 때 먼저 Storage API를 사용하여 캐시된 응답을 사용할 수 있는지 확인할 수 있습니다. 있는 경우 해당 응답이 웹 앱에 반환됩니다.

하지만 캐시 부적중이 있는 경우 서비스 워커는 네트워크로 가서 응답을 검색할 수 있습니다 네트워크 요청이 웹 앱으로 반환되고 사본이 캐시에 저장됩니다. 이 캐시된 사본은 다음에 요청을 수행할 때 네트워크를 우회하는 데 동일한 URL이 만들어집니다.

페이지에서 서비스 워커로, 서비스 워커에서 캐시로 이동하는 요청을 보여주는 다이어그램 캐시 요청이 실패하므로 요청이 네트워크로 이동합니다.

재검증 중 비활성

비활성 재검증은 하이브리드와 같습니다. 이를 사용할 때 서비스는 작업자는 캐시된 응답을 즉시 확인하고, 응답이 있으면 웹 앱에 반환할 수 있습니다.

그 동안 캐시 일치 여부에 상관없이 서비스는 작업자가 네트워크 요청을 실행하여 '최신' 상태를 있습니다. 이 이전에 캐시된 응답을 업데이트하는 데 사용됩니다. 초기 캐시가 네트워크 응답의 사본이 웹으로 다시 전달됩니다 있습니다.

페이지에서 서비스 워커로, 서비스 워커에서 캐시로 이동하는 요청을 보여주는 다이어그램 캐시는 이후 요청을 위해 네트워크에서 업데이트를 가져오는 동시에 즉시 응답을 반환합니다.

Workbox를 사용해야 하는 이유는 무엇인가요?

이러한 캐싱 전략은 일반적으로 다시 쓸 수 있는 방법이 있습니다 Kubernetes에 의지하는 대신 Workbox는 이러한 도구를 자체 개발 과정의 일부로 전략 라이브러리를 사용하면 서비스 워커에 들어갈 준비가 되었습니다.

Workbox는 버전 관리 지원도 제공하므로, 만료 웹 앱에 알리는 것이 가능할 때 업데이트 발생할 수 있습니다

어떤 애셋을 어떤 전략으로 캐시해야 하나요?

런타임 캐싱은 사전 캐싱을 보완하는 것으로 볼 수 있습니다. 모든 애셋이 이미 사전 캐시되고 있으면 완료됩니다. 필요한 작업이 없습니다. 캐시될 수 있습니다 상대적으로 복잡한 웹 앱의 경우 모든 것을 미리 캐시하지는 않을 것입니다.

더 큰 미디어 파일, CDN과 같은 타사 호스트에서 제공되는 애셋, API 응답에 대한 자세한 내용은 효과적으로 사전 캐시됩니다. DevTools의 Network 패널을 사용하여 요청 식별 분류하고 각 항목에 대해 최신성과 신뢰성을 비교하는 것이 적절합니다

재검증 중 비활성을 사용하여 최신 상태보다 안정성 우선시하기

비활성 상태 재검증 전략은 거의 캐시된 응답을 반환하기 때문에 즉시(첫 번째 요청을 통해 캐시가 채워진 후) 안정적으로 빠른 성능을 확인할 수 있습니다. 이 기능은 다른 데이터 센터에 비해 오래 걸릴 수 있는 응답 데이터를 다시 얻는 것에 대한 가져올 수 있습니다. 이 전략을 사용하는 것이 가장 좋습니다. 사용자 프로필 이미지 또는 초기 API 응답과 같은 자산의 무언가를 즉시 표시하는 것이 중요하다는 것을 알고 있는 경우 표시됩니다.

네트워크 우선 방식을 사용하여 안정성보다 최신성 우선

네트워크 중심 전략을 사용하는 것은 어떤 의미로는 전투에서 패배를 인정하는 것과 같습니다. 우선순위가 지정되어 있지만 그로 인해 불확실성이 발생합니다. 살펴봤습니다 특정 유형의 저작물에 대해 오래된 정보를 되찾는 것을 선호하지 않습니다. 다음과 같은 경우에 최신 상태를 선호할 수 있습니다. 자주 업데이트되는 기사의 텍스트에 대해 인스턴스를 만들 수 있습니다

네트워크 우선 전략을 사용하여 서비스 워커 내에서 네트워크에 직접 거슬러 올라가면 내용으로 돌아갈 수 있습니다. 할 일은 없습니다. 적어도 오프라인 상태에서도 안정성은 유지됩니다.

버전이 지정된 URL에 캐시 우선 사용

캐시 우선 전략에서는 항목이 캐시되면 업데이트되지 않습니다. 그러려면 가능성이 낮은 확장 소재에만 사용하세요 있습니다. 특히 버전 관리가 포함된 URL에 대해 가장 잘 작동합니다. 같은 종류의 URL입니다. Cache-Control: max-age=31536000 응답 헤더