強制網路逾時

有時網路連線可能會變慢，或是連線斷斷續續。在兩個服務工作處理程序中，網路優先的快取策略可能需要很長的時間才能從網路取得回應，或者要求會停止運作，同時載入旋轉圖示會持續旋轉，直到系統顯示錯誤頁面為止。

無論情況為何，在某些情況下，建議選擇在一段時間後改回使用某資產或網頁的最近一次快取回應，但 Workbox 可以解決另一個問題。

使用networkTimeoutSeconds

使用 NetworkFirst 或 NetworkOnly 策略時，可以強制規定網路要求逾時。這些策略提供 networkTimeoutSeconds 選項，指定 Service Worker 要等待網路回應完成多久，才會終止並傳回該項目的最後一個快取版本：

// 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);

上述程式碼會指示 Service Worker 執行任何網路優先的導覽要求，並在三秒後使用最後一個快取版本。搭配瀏覽要求使用時，可保證存取任何先前造訪頁面的最後快取回應。

不過，如果您存取的網頁在快取中沒有較舊的回應，在這種情況下，您可以為一般離線 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 時，如果逾時發生，且網址沒有快取相符，處理常式就會傳回錯誤回應。如果發生這種情況，handlerDidError Workbox 外掛程式可提供一般回應做為備用選項。

等待時間太長？

強制要求逾時 (尤其是導航要求) 時，建議您避免讓使用者等待太久或逾時，兩者之間取得適當平衡。等候時間過長，可能導致使用者在速度緩慢前遇到連線退信的情況。逾時速度太快，可能會使得快取中不必要的內容供應。

正確答案是「視情況而定」。如果您經營網站 (例如網誌) 且內容更新頻率不高，那麼正確答案可能是盡可能擺脫「太」了，因為快取中的內容可能為「新鮮」就這樣。不過，如果是互動性更高的網站和網頁應用程式，建議您等待較長的時間，以免太快從 Service Worker 快取提供過時的資料。

如果您要在實地記錄指標，請查看首次位元組時間 (TTFB) 和首次顯示內容所需時間 (FCP) 的第 75 個百分位數，藉此瞭解在哪個使用者群中，瀏覽要求的等待時間可能較長。以便深入分析線條的方向。