אילוץ של זמן קצוב לתפוגה של רשת

לפעמים יש לכם חיבור לרשת, אבל החיבור איטי מדי או שהחיבור משבש לכם שאתם מחוברים. במצבים כאלה שבהם קובץ שירות (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 לצאת מכל בקשת ניווט ראשונה ברשת ולהשתמש בגרסה האחרונה שנשמרה במטמון אחרי שלוש שניות. כשמשתמשים בו עם בקשות ניווט, מובטחת גישה לתגובה האחרונה שנשמרה במטמון של דף כלשהו שביקרתם בו בעבר.

עם זאת, מה אם לדף שאליו נכנסים אין תגובה ישנה יותר במטמון? במקרים כאלה, תוכלו ליצור תגובה חלופית לדף 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, ה-handler יחזיר תגובת שגיאה אם הזמן הקצוב לתפוגה יסתיים ואין התאמה במטמון לכתובת ה-URL. במקרה כזה, הפלאגין handlerDidError Workbox יכול לספק תשובה גנרית כחלופה.

כמה זמן נמשך יותר מדי זמן?

כאשר מאלצים זמן קצוב לתפוגה עבור בקשות - במיוחד בקשות ניווט - אתם רוצים למצוא את האיזון הנכון בין לא לאפשר למשתמש להמתין זמן רב מדי לבין הזמן הקצוב לתפוגה שלו. יש להמתין יותר מדי זמן, ועלולים להיות מקרים שבהם משתמשים יפתחו חיבורים איטיים לפני שהזמן הקצוב לתפוגה יסתיים. הזמן הקצוב פג מהר מדי, וייתכן שבסופו של דבר תקבלו תוכן לא פעיל מהמטמון, שלא לצורך.

התשובה הנכונה היא "זה תלוי". אם אתם מפעילים אתר כמו בלוג ולא מעדכנים את התוכן לעיתים קרובות מדי, סביר להניח שהתשובה הנכונה היא לא לחכות יותר מדי, כי סביר להניח שהתוכן במטמון "עדכני" מספיק. עם זאת, לאתרים ולאפליקציות אינטרנט אינטראקטיביים יותר, ייתכן שעדיף להמתין מעט יותר ולהימנע מהצגת נתונים לא עדכניים מהמטמון של ה-Service Worker.

אם אתם מתעדים מדדים בשדה, כדאי לבדוק את האחוזון ה-75 של הציונים Time to First Byte (TTFB) ו-First Contentful Paint (FCP) כדי להבין איפה עשויים להיות זמני המתנה ארוכים יותר לבקשות ניווט בבסיס המשתמשים שלכם. כך תוכל להבין היכן צריך למתוח את הקו.