नेटवर्क से टाइम आउट लेना

कई बार आपके पास इंटरनेट कनेक्शन होता है, लेकिन वह कनेक्शन या तो बहुत धीमा होता है या फिर आपके कनेक्शन की वजह से आपको पता चलता है कि आप ऑनलाइन हैं. ऐसी स्थितियों में, जहां सर्विस वर्कर दोनों में हो, नेटवर्क-फ़र्स्ट कैशिंग स्ट्रेटजी को नेटवर्क से रिस्पॉन्स मिलने में बहुत ज़्यादा समय लग सकता है या अनुरोध रुक जाएगा—और लोडिंग स्पिनर लगातार घूमती रहेगी—जब तक आपको गड़बड़ी वाला पेज नहीं मिलता.

भले ही स्थिति चाहे जो भी हो, कुछ मामलों में ऐसे मामले होते हैं जिनमें एक तय समय के बाद, किसी एसेट या पेज के आखिरी कैश रिस्पॉन्स पर वापस जाना बेहतर होता है—हालांकि, यह एक ऐसी समस्या है जिसमें 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);

ऊपर दिया गया कोड आपके सर्विस वर्कर को किसी भी नेटवर्क-फ़र्स्ट नेविगेशन अनुरोध से बचने और तीन सेकंड के बाद आखिरी बार कैश मेमोरी में सेव किए गए वर्शन का इस्तेमाल करने का निर्देश देता है. नेविगेशन के अनुरोधों के साथ इस्तेमाल किए जाने पर, यह पिछले देखे गए किसी भी पेज के आखिरी कैश मेमोरी में सेव किए गए रिस्पॉन्स को ऐक्सेस करने की गारंटी देता है.

हालांकि, आप जिस पेज को ऐक्सेस कर रहे हैं अगर उसकी कैश मेमोरी में कोई पुराना रिस्पॉन्स नहीं है, तो क्या होगा? ऐसे मामलों में, आप किसी सामान्य ऑफ़लाइन एचटीएमएल पेज पर फ़ॉलबैक रिस्पॉन्स बना सकते हैं:

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));

यह इसलिए काम करता है, क्योंकि जब आप NetworkFirst रणनीति में networkTimeoutSeconds का इस्तेमाल करते हैं, तो अगर टाइम आउट हो जाता है और यूआरएल के लिए कैश मेमोरी का मिलान नहीं होता है, तो आपका हैंडलर, गड़बड़ी का जवाब देगा. अगर ऐसा होता है, तो handlerDidError Workbox प्लगिन की मदद से, फ़ॉलबैक के तौर पर सामान्य रिस्पॉन्स दिया जा सकता है.

कितनी देर इंतज़ार करना पड़ सकता है?

अनुरोधों के लिए टाइम आउट को मज़बूर करते समय—खास तौर पर नेविगेशन के अनुरोध—आप उपयोगकर्ताओं को बहुत लंबे समय तक इंतज़ार न करने और बहुत जल्दी समय न खत्म करने के बीच सही संतुलन बनाना चाहें. बहुत देर तक इंतज़ार करें. इससे टाइम आउट होने से पहले ही, धीमे कनेक्शन वाले उपयोगकर्ताओं के बाउंस होने का जोखिम हो सकता है. समय बहुत तेज़ी से खत्म हो गया है. इस वजह से, हो सकता है कि कैश मेमोरी से बेवजह पुराना कॉन्टेंट दिखाया जाए.

सही जवाब है "यह निर्भर करता है". अगर ब्लॉग जैसी साइट का इस्तेमाल किया जा रहा है और अपने कॉन्टेंट को बार-बार अपडेट नहीं किया जाता है, तो बहुत ज़्यादा इंतज़ार न करना सही जवाब हो सकता है, क्योंकि कैश मेमोरी में मौजूद कॉन्टेंट "नया" है. हालांकि, ज़्यादा इंटरैक्टिव वेबसाइटों और वेब ऐप्लिकेशन के लिए, थोड़ा ज़्यादा इंतज़ार करना बेहतर होगा. साथ ही, सर्विस वर्कर कैश से पुराना डेटा भेजने से बचना बेहतर होगा.

अगर फ़ील्ड में मेट्रिक रिकॉर्ड की जा रही हैं, तो टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी) और फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) स्कोर का 75वां पर्सेंटाइल देखें. इससे आपको पता चलेगा कि आपके उपयोगकर्ताओं को नेविगेशन के अनुरोधों के लिए ज़्यादा इंतज़ार करना पड़ सकता है. इससे आपको यह जानकारी मिल सकती है कि लाइन कहां बनानी है.