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

네트워크에 연결되어 있지만 연결이 너무 느리거나 온라인 상태라고 거짓말하는 경우가 있습니다. 서비스 워커가 함께 사용되는 이러한 상황에서는 네트워크 우선 캐싱 전략이 네트워크로부터 응답을 얻는 데 시간이 너무 오래 걸리거나, 오류 페이지가 표시될 때까지 요청이 멈추고 로딩 스피너가 계속 회전합니다.

어떤 상황이든, 일정 기간이 지난 후에 자산이나 페이지에 대해 마지막으로 캐시된 응답으로 돌아가는 것이 바람직한 경우가 있지만 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 Workbox 플러그인이 일반적인 응답을 대체 응답으로 제공할 수 있습니다.

대기 시간이 너무 오래 걸리나요?

요청(특히 탐색 요청)에 시간 제한을 강제로 설정할 때는 사용자가 너무 오래 기다리지 않게 하는 것과 너무 빨리 타임아웃되지 않도록 하는 것 사이에서 적절한 균형을 찾는 것이 좋습니다. 너무 오래 기다리면 시간 초과가 발생하기 전에 사용자의 느린 연결 반송 문제가 발생할 수 있습니다. 제한 시간이 너무 빨라 캐시에서 불필요하게 오래된 콘텐츠를 제공할 수 있습니다.

정답은 '상황에 따라 다름'입니다. 블로그와 같은 사이트를 실행 중이고 콘텐츠를 너무 자주 업데이트하지 않는 경우 정답은 캐시에 있는 내용이 '최신'일 수 있으므로 너무 기다리지 않는 것입니다. 충분히 이해가 되셨을 것입니다. 그러나 상호작용이 많은 웹사이트와 웹 앱의 경우 조금 더 오래 기다리면서 서비스 워커 캐시에서 오래된 데이터를 너무 빨리 제공하지 않는 것이 가장 좋을 수 있습니다.

입력란에 측정항목을 기록하는 경우 첫 바이트까지의 시간 (TTFB) 및 콘텐츠가 포함된 첫 페인트 (FCP) 점수의 75번째 백분위수를 확인하여 탐색 요청의 대기 시간이 더 긴 사용자층을 파악할 수 있습니다. 이를 통해 선을 그리는 위치를 파악할 수 있습니다.