فرض مهلة الشبكة

في بعض الأحيان، يكون لديك اتصال بالشبكة، ولكن هذا الاتصال إما بطيء جدًا أو أن الاتصال يكذب بك أنك متصل بالإنترنت. في مثل هذه الحالات التي يكون فيها مشغّل الخدمات في هذا المزيج، قد تستغرق استراتيجية التخزين المؤقت التي تعتمد على الشبكة أولاً وقتًا طويلاً جدًا لتلقّي استجابة من الشبكة، أو سيتوقف الطلب، وستدور أشرطة التحميل الدوّارة إلى ما لا نهاية، إلى أن تظهر لك صفحة خطأ.

مهما كان الوضع، هناك حالات يكون فيها من الأفضل الرجوع إلى آخر استجابة مخبأة لمادة عرض أو صفحة بعد فترة معينة من الوقت، ولكن هناك مشكلة أخرى يمكن أن يساعد 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);

يوجِّه الرمز أعلاه مشغّل الخدمات إلى تخطّي أي طلب تنقّل للشبكة أولاً واستخدام آخر نسخة مخزَّنة مؤقتًا بعد ثلاث ثوانٍ. وعند استخدام ذلك مع طلبات التنقّل، يضمن ذلك إمكانية الوصول إلى آخر استجابة مخزَّنة مؤقتًا لأي صفحة تمت زيارتها سابقًا.

ومع ذلك، ماذا لو لم يكن للصفحة التي يتم الوصول إليها استجابة قديمة في ذاكرة التخزين المؤقت؟ في مثل هذه الحالات، يمكنك إنشاء استجابة احتياطية لصفحة 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 ردًّا عامًا كإجراء احتياطي.

ما هي مدة الانتظار الطويلة جدًا؟

عند فرض مهلة للطلبات - خاصة طلبات التنقل - فأنت تريد تحقيق التوازن الصحيح بين عدم السماح للمستخدم بالانتظار لفترة طويلة وعدم انتهاء المهلة بسرعة كبيرة. الانتظار لفترة طويلة جدًا، وقد يخاطر المستخدمون بارتداد الاتصالات البطيئة قبل انتهاء المهلة. المهلة سريعة جدًا، وقد ينتهي بك الأمر بعرض محتوى قديم بدون داعٍ من ذاكرة التخزين المؤقت.

الإجابة الصحيحة هي "على حسب". إذا كنت تدير موقعًا إلكترونيًا مثل مدونة ولا تعدّل المحتوى كثيرًا، فالإجابة الصحيحة هي على الأرجح عدم الانتظار كثيرًا، إذ إن أي ما في ذاكرة التخزين المؤقت يكون "حديثًا" بما يكفي. ومع ذلك، بالنسبة إلى المواقع الإلكترونية وتطبيقات الويب الأكثر تفاعلاً، قد يكون من الأفضل الانتظار لفترة أطول قليلاً وتجنُّب عرض البيانات القديمة من ذاكرة التخزين المؤقت لمشغِّل الخدمات بكثرة.

إذا كنت تسجِّل المقاييس في الحقل، اطّلِع على الشريحة المئوية الخامسة والسبعين من نتائج الوقت المستغرق حتى أول بايت (TTFB) وسرعة عرض أول محتوى مرئي (FCP) لمعرفة الأوقات التي قد تكون فيها أوقات الانتظار الطويلة لطلبات التنقّل في قاعدة مستخدميك ظاهرة. قد يمنحك ذلك نظرة ثاقبة حول مكان رسم الخط.