ในบางครั้งที่คุณเชื่อมต่อเครือข่ายได้ แต่การเชื่อมต่อนั้นช้าเกิ��ไป หรือการเชื่อมต่อทำให้คุณออนไลน์อยู่ ในกรณีที่ Service Worker ทำงานแบบผสมผสาน กลยุทธ์การแคชที่เน้นเครือข่ายเป็นหลักอาจใช้เวลานานเกินไปในการรับการตอบสนองจากเครือข่าย หรือคำขอค้าง และไอคอนหมุนของการโหลดจะหมุนไปเรื่อยๆ จนกว่าคุณจะเห็นหน้าข้อผิดพลาด
แต่ไม่ว่าสถานการณ์ใด อาจมีบางกรณีที่การกลับไปใช้การตอบสนองที่แคชไว้ครั้งล่าสุดสำหรับเนื้อหาหรือหน้าเว็บหลังจากผ่านไประยะเวลาหนึ่งก็อาจเหมาะสมกว่า แต่ก็ยังมีปัญหาอื่นที่ 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 สามารถให้การตอบสนองทั่วไปเป็นรายการสำรอง
ใช้เวลารอนานเกินไปไหม
เมื่อบังคับให้คำขอหมดเวลา โดยเฉพาะคำขอการนำทาง คุณต้องหาจุดสมดุลที่เหมาะสมระหว่างการไม่ให้ผู้ใช้รอนานเกินไปและไม่ให้หมดเวลาเร็วเกินไป เนื่องจากรอนานเกินไป คุณอาจเสี่ยงที่จะทำให้ผู้ใช้ที่การเชื่อมต่อช้าตีกลับก่อนที่จะหมดเวลา หมดเวลาเร็วเกินไป และคุณอาจพบการแสดงเนื้อหาที่ไม่มีการอัปเดตจากแคชโดยไม่จำเป็น
คำตอบที่ถูกต้องคือ "ขึ้นอยู่กับ" หากคุณใช้เว็บไซต์ เช่น บล็อก และไม่ได้อัปเดตเนื้อหาบ่อยเกินไป คำตอบที่ถูกต้องคือไม่ควรรอมากเกินไป เพราะทุกอย่างที่อยู่ในแคชน่าจะ "ใหม่" พอ อย่างไรก็ตาม สำหรับเว็บไซต์และเว็บแอปที่มีการโต้ตอบมาก��ว่า ควรรอนานขึ้นเล็กน้อยและหลีกเลี่ยงการแสดงข้อมูลเก่าจากแคชของโปรแกรมทำงานของบริการมากเกินไป
หากคุณบันทึกเมตริกในช่อง ให้ดูคะแนนเปอร์เซ็นไทล์ที่ 75 ของTime to First Byte (TTFB) และ First Contentful Paint (FCP) เพื่อดูว่าฐานผู้ใช้ของคุณต้องรอนานแค่ไหนสำหรับคำขอการนำทาง ซึ่งอาจให้ข้อมูลเชิงลึกแก่คุณเกี่ยวกับที่ที่ต้องวาดเส้น