การบังคับใช้ระยะหมดเวลาของเครือข่าย

บางครั้งคุณเชื่อมต่อเครือข่ายได้ แต่การเชื่อมต่อนั้นช้าเกินไป หรือการเชื่อมต่อของคุณโกหกว่าคุณออนไลน์อยู่ ในสถานการณ์ที่มีโปรแกรมทำงานของบริการหลายอย่างผสมกัน กลยุทธ์การแคชที่เน้นเครือข่ายเป็นหลักอาจใช้เวลานานเกินไปในการรับการตอบสนองจากเครือข่าย หรือคำขอจะค้าง และไอคอนหมุนของการโหลดจะหมุนไปเรื่อยๆ จนกว่าคุณจะเห็นหน้าแสดงข้อผิดพลาด

ไม่ว่าสถานการณ์จะเป็นอย่างไร อาจมีบางกรณีที่การเปลี่ยนกลับไปใช้การตอบกลับที่แคชไว้ล่าสุดสำหรับเนื้อหาหรือหน้าเว็บหลังจากช่วงเวลาหนึ่งๆ คงจะดีกว่า แต่ก็มีอีกปัญหาหนึ่งที่ 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 ของคุณออกคำขอการนำทางที่เน้นเครือข่ายเป็นหลักและใช้แคชเวอร์ชันล่าสุดหลังผ่านไป 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));

ซึ่งได้ผลเนื่องจากเมื่อคุณใช้ networkTimeoutSeconds ในกลยุทธ์ NetworkFirst เครื่องจัดการของคุณจะแสดงผลการตอบสนองข้อผิดพลาดหากการหมดเวลาเกิดขึ้นและไม่มีแคชที่ตรงกันสำหรับ URL หากเป็นเช่นนั้น ปลั๊กอิน handlerDidError Workbox จะให้คำตอบทั่วไปเป็นรายการสำรองได้

ใช้เวลานานเกินไปที่จะรอหรือไม่

เมื่อบังคับให้หมดเวลาสำหรับคำขอ โดยเฉพาะคำขอการนำทาง คุณควรสร้างสมดุลที่เหมาะสมระหว่างการไม่อนุญาตให้ผู้ใช้รอนานเกินไปและไม่หมดเวลาเร็วเกินไป โปรดรอนานเกินไป และคุณอาจเสี่ยงให้ผู้ใช้ที่การเชื่อมต่อช้าจะตีกลับก่อนที่จะถึงระยะหมดเวลา หมดเวลาเร็วเกินไป และคุณอาจแสดงเนื้อหาที่ไม่มีอัปเดตจากแคชโดยไม่จำเป็น

คำตอบที่ถูกต้องคือ "ขึ้นอยู่กับ" หากคุณใช้งานเว็บไซต์ เช่น บล็อก และไม่ได้อัปเดตเนื้อหาบ่อยเกินไป คำตอบที่ถูกต้องก็อาจจะต้องผิดเพี้ยนไปจากการทำเว็บไซต์ให้เกินไป เนื่องจากสิ่งที่อยู่ในแคชอาจเป็น "ใหม่" ให้เพียงพอ อย่างไรก็ตาม สำหรับเว็บไซต์และเว็บแอปที่มีการโต้ตอบมากขึ้น อาจดีที่สุดที่จะรออีกสักระยะและหลีกเลี่ยงการแสดงข้อมูลที่ไม่อัปเดตจากแคชของ Service Worker มากเกินไป

ในกรณีที่คุณบันทึกเมตริกในช่องดังกล่าว ให้ดูที่เปอร์เซ็นไทล์ที่ 75 ของคะแนนเวลาถึง First Byte (TTFB) และ First Contentful Paint (FCP) เพื่อให้ได้ทราบว่าฐานผู้ใช้ต้องรอคำขอการนำทางนานในกรณีใด ซึ่งจะช่วยให้คุณได้ข้อมูลเชิงลึกว่าควรวาดเส้นตรงที่ใด