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

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

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

ما مدة الانتظار؟

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

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

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