네트워크에 연결되어 있지만 연결이 너무 느리거나 연결이 현재 온라인 상태임을 거짓말하는 경우가 있습니다. 서비스 워커가 혼합되어 있는 이러한 상황에서는 네트워크 우선 캐싱 전략이 네트워크에서 응답을 받는 데 너무 오래 걸릴 수 있습니다. 또는 요청이 중단되고 오류 페이지가 표시될 때까지 로딩 스피너가 끝없이 회전합니다.
어떤 경우든 일정 기간이 지난 후 애셋 또는 페이지에 대해 마지막으로 캐시된 응답으로 대체하는 것이 바람직한 경우가 있지만 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번째 백분위수를 확인하여 탐색 요청의 대기 시간이 긴 사용자층을 파악할 수 있습니다. 이렇게 하면 어느 부분에 선을 그려야 하는지 알 수 있습니다.