네트워크 시간 초과 강제 적용

네트워크에 연결되어 있지만 연결이 너무 느리거나 연결이 현재 온라인 상태임을 거짓말하는 경우가 있습니다. 서비스 워커가 혼합되어 있는 이러한 상황에서는 네트워크 우선 캐싱 전략이 네트워크에서 응답을 받는 데 너무 오래 걸릴 수 있습니다. 또는 요청이 중단되고 오류 페이지가 표시될 때까지 로딩 스피너가 끝없이 회전합니다.

어떤 경우든 일정 기간이 지난 후 애셋 또는 페이지에 대해 마지막으로 캐시된 응답으로 대체하는 것이 바람직한 경우가 있지만 Workbox가 도울 수 있는 또 다른 문제입니다.

networkTimeoutSeconds 사용

NetworkFirst 또는 NetworkOnly 전략을 사용하는 경우 네트워크 요청에 강제로 시간 제한을 설정할 수 있습니다. 이러한 전략은 networkTimeoutSeconds 옵션을 제공합니다. 이 옵션은 네트워크 응답이 해제되어 마지막으로 캐시된 버전을 반환하기 전에 네트워크 응답이 도착할 때까지 서비스 워커가 대기해야 하는 시간을 지정합니다.

// sw.js
import { NetworkFirst } from 'workbox-strategies';
import { registerRoute, NavigationRoute } from 'workbox-routing';

// Only wait for three seconds before returning the last
// cached version of the requested page.
const navigationRoute = new NavigationRoute(new NetworkFirst({
  networkTimeoutSeconds: 3,
  cacheName: 'navigations'
}));

registerRoute(navigationRoute);

위의 코드는 서비스 워커가 모든 네트워크 우선 탐색 요청에서 벗어나 3초 후에 마지막으로 캐시된 버전을 사용하도록 지시합니다. 탐색 요청과 함께 사용하면 이전에 방문한 페이지의 마지막으로 캐시된 응답에 액세스할 수 있습니다.

하지만 액세스하는 페이지의 캐시에 이전 응답이 없으면 어떻게 해야 할까요? 이 경우 일반 오프라인 HTML 페이지에 대한 대체 응답을 설정할 수 있습니다.

import {registerRoute, NavigationRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';

// Hardcode the fallback cache name and the offline
// HTML fallback's URL for failed responses
const FALLBACK_CACHE_NAME = 'offline-fallback';
const FALLBACK_HTML = '/offline.html';

// Cache the fallback HTML during installation.
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(FALLBACK_CACHE_NAME).then((cache) => cache.add(FALLBACK_HTML)),
  );
});

// Apply a network-only strategy to navigation requests.
// If offline, or if more than five seconds pass before there's a
// network response, fall back to the cached offline HTML.
const networkWithFallbackStrategy = new NetworkOnly({
  networkTimeoutSeconds: 5,
  plugins: [
    {
      handlerDidError: async () => {
        return await caches.match(FALLBACK_HTML, {
          cacheName: FALLBACK_CACHE_NAME,
        });
      },
    },
  ],
});

// Register the route to handle all navigations.
registerRoute(new NavigationRoute(networkWithFallbackStrategy));

이는 NetworkFirst 전략에서 networkTimeoutSeconds를 사용할 때 시간 초과가 발생하고 URL에 일치하는 캐시가 없으면 핸들러가 오류 응답을 반환하기 때문에 작동합니다. 이 경우 handlerDidError 작업 상자 플러그인은 대체로 일반 응답을 제공할 수 있습니다.

대기 시간이 얼마나 걸리나요?

요청(특히 내비게이션 요청)에 대해 시간 제한을 강제 설정할 때는 사용자가 너무 오래 기다리지 않도록 하고 너무 빨리 시간 제한을 초과하지 않는 것 사이에서 적절한 균형을 유지해야 합니다. 너무 오래 기다리면 시간 초과가 발생하기 전에 느린 연결을 사용하는 사용자가 이탈할 위험이 있습니다. 시간 제한이 너무 빨라져 캐시에서 불필요하게 오래된 콘텐츠를 제공할 수 있습니다.

정답은 '상황에 따라 다를 수 있습니다'입니다. 블로그와 같은 사이트를 운영 중이며 콘텐츠를 너무 자주 업데이트하지 않는다면 캐시에 있는 내용이 무엇이든 '최신'일 수 있으므로 너무 많이 기다리지 않는 것이 올바른 답일 수 있습니다. 그러나 대화형 웹사이트 및 웹 앱의 경우 조금 더 오래 기다렸다가 서비스 워커 캐시에서 오래된 데이터를 너무 빨리 제공하지 않는 것이 좋습니다.

필드에서 측정항목을 기록하는 경우 첫 바이트까지의 시간 (TTFB) 및 콘텐츠가 포함된 첫 페인트 (FCP) 점수의 75번째 백분위수를 확인하여 탐색 요청의 대기 시간이 긴 사용자층을 파악할 수 있습니다. 이렇게 하면 어느 부분에 선을 그려야 하는지 알 수 있습니다.