रनटाइम के दौरान संसाधनों को कैश मेमोरी में सेव करना

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

वर्कबॉक्स में रूट को मैच करने के लिए, workbox-routing मॉड्यूल का इस्तेमाल करके ऐसेट के लिए रनटाइम की कैश मेमोरी मैनेज की जा सकती है. साथ ही, workbox-strategies मॉड्यूल की मदद से इनके लिए कैश मेमोरी में डेटा सेव करने की रणनीतियों को मैनेज किया जा सकता है.

कैश मेमोरी में सेव करने की रणनीतियां

पहले से मौजूद कैश मेमोरी में सेव की गई रणनीतियों की मदद से, ऐसेट के ज़्यादातर रूट मैनेज किए जा सकते हैं. इन विषयों के बारे में इस दस्तावेज़ में पहले विस्तार में बताया गया है, लेकिन यहां कुछ बातें याद रखी गई हैं:

  • फिर से पुष्टि करते समय पुरानी जानकारी, किसी अनुरोध के उपलब्ध होने पर कैश मेमोरी में सेव किए गए रिस्पॉन्स का इस्तेमाल करती है. साथ ही, यह नेटवर्क से मिलने वाले रिस्पॉन्स के साथ बैकग्राउंड में कैश मेमोरी को अपडेट करती है. इसलिए, अगर ऐसेट को कैश मेमोरी में सेव नहीं किया जाता है, तो यह नेटवर्क से जवाब मिलने का इंतज़ार करेगी और उसी का इस्तेमाल करेगी. यह काफ़ी सुरक्षित रणनीति है, क्योंकि यह नियमित रूप से कैश एंट्री को अपडेट करती है, जो इस पर निर्भर करती हैं. इसकी समस्या यह है कि यह हमेशा बैकग्राउंड में मौजूद नेटवर्क से ऐसेट का अनुरोध करती है.
  • Network First नेटवर्क से सबसे पहले जवाब पाने की कोशिश करता है. अगर कोई जवाब मिलता है, तो यह उस जवाब को ब्राउज़र को पास करता है और उसे कैश मेमोरी में सेव कर देता है. अगर नेटवर्क अनुरोध पूरा नहीं होता है, तो आखिरी बार कैश मेमोरी में सेव किए गए रिस्पॉन्स का इस्तेमाल किया जाएगा. इससे ऐसेट को ऑफ़लाइन ऐक्सेस करने की सुविधा चालू हो जाएगी.
  • कैश पहले कैश मेमोरी में सेव करें, सबसे पहले रिस्पॉन्स के लिए कैश मेमोरी की जांच करता है और उपलब्ध होने पर इसका इस्तेमाल करता है. अगर अनुरोध कैश मेमोरी में सेव नहीं किया गया है, तो नेटवर्क का इस्तेमाल किया जाता है और कोई भी मान्य रिस्पॉन्स, ब्राउज़र में भेजे जाने से पहले कैश मेमोरी में जोड़ दिया जाता है.
  • सिर्फ़ नेटवर्क, नेटवर्क से रिस्पॉन्स भेजने को मजबूर करता है.
  • सिर्फ़ कैश, रिस्पॉन्स को कैश मेमोरी से ज़बरदस्ती दिखाता है.

workbox-routing के तरीकों का इस्तेमाल करके, अनुरोधों को चुनने के लिए ये रणनीतियां लागू की जा सकती हैं.

रूट मैचिंग की सुविधा के साथ कैश मेमोरी में डेटा सेव करने की रणनीतियां लागू करना

रूट का मिलान करने और उन्हें कैश मेमोरी में सेव करने की रणनीति की मदद से मैनेज करने के लिए, workbox-routing एक registerRoute तरीका दिखाता है. registerRoute एक Route ऑब्जेक्ट स्वीकार करता है, जो बदले में दो तर्क स्वीकार करता है:

  1. रूट मैच करने की शर्तें तय करने के लिए स्ट्रिंग, रेगुलर एक्सप्रेशन या मैच कॉलबैक.
  2. रूट के लिए हैंडलर—आम तौर पर, workbox-strategies से मिली रणनीति.

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

इसके बाद, हैंडलर मेल खाने वाले रास्ते को हैंडल करता है. यहां दिए गए उदाहरण में, एक नया रूट बनाया गया है जो कि एक ही ऑरिजिन की इमेज के अनुरोधों से मेल खाता है. यह रूट, पहले कैश मेमोरी को लागू करके, नेटवर्क स्ट्रेटजी पर वापस जाता है.

// sw.js
import { registerRoute, Route } from 'workbox-routing';
import { CacheFirst } from 'workbox-strategies';

// A new route that matches same-origin image requests and handles
// them with the cache-first, falling back to network strategy:
const imageRoute = new Route(({ request, sameOrigin }) => {
  return sameOrigin && request.destination === 'image'
}, new CacheFirst());

// Register the new route
registerRoute(imageRoute);

एक से ज़्यादा कैश मेमोरी का इस्तेमाल करना

वर्कबॉक्स की मदद से, कैश मेमोरी में सेव किए गए जवाबों को Cache के अलग-अलग इंस्टेंस में बकेट किया जा सकता है. ऐसा करने के लिए, बंडल की गई रणनीतियों में उपलब्ध cacheName विकल्प का इस्तेमाल करें.

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

// sw.js
import { registerRoute, Route } from 'workbox-routing';
import { CacheFirst, StaleWhileRevalidate } from 'workbox-strategies';

// Handle images:
const imageRoute = new Route(({ request }) => {
  return request.destination === 'image'
}, new StaleWhileRevalidate({
  cacheName: 'images'
}));

// Handle scripts:
const scriptsRoute = new Route(({ request }) => {
  return request.destination === 'script';
}, new CacheFirst({
  cacheName: 'scripts'
}));

// Handle styles:
const stylesRoute = new Route(({ request }) => {
  return request.destination === 'style';
}, new CacheFirst({
  cacheName: 'styles'
}));

// Register routes
registerRoute(imageRoute);
registerRoute(scriptsRoute);
registerRoute(stylesRoute);
Chrome के DevTools के ऐप्लिकेशन टैब में, कैश मेमोरी के इंस्टेंस की सूची का स्क्रीनशॉट. इसमें तीन अलग-अलग कैश मेमोरी दिख रही हैं: एक का नाम 'स्क्रिप्ट' है, दूसरी का नाम 'स्टाइल' और आखिरी कैश मेमोरी का नाम 'इमेज' है.
Chrome DevTools के ऐप्लिकेशन पैनल में कैश स्टोरेज व्यूअर. अलग-अलग तरह की ऐसेट से जुड़े जवाबों को अलग-अलग कैश मेमोरी में सेव किया जाता है.

कैश एंट्री के लिए समयसीमा सेट करना

सर्विस वर्कर कैश मेमोरी को मैनेज करते समय, स्टोरेज कोटा का ध्यान रखें. ExpirationPlugin, कैश मेमोरी के रखरखाव को आसान बनाता है और workbox-expiration तक यह सार्वजनिक हो जाता है. इसका इस्तेमाल करने के लिए, इसे कैश मेमोरी की रणनीति के कॉन्फ़िगरेशन में तय करें:

// sw.js
import { registerRoute, Route } from 'workbox-routing';
import { CacheFirst } from 'workbox-strategies';
import { ExpirationPlugin } from 'workbox-expiration';

// Evict image cache entries older thirty days:
const imageRoute = new Route(({ request }) => {
  return request.destination === 'image';
}, new CacheFirst({
  cacheName: 'images',
  plugins: [
    new ExpirationPlugin({
      maxAgeSeconds: 60 * 60 * 24 * 30,
    })
  ]
}));

// Evict the least-used script cache entries when
// the cache has more than 50 entries:
const scriptsRoute = new Route(({ request }) => {
  return request.destination === 'script';
}, new CacheFirst({
  cacheName: 'scripts',
  plugins: [
    new ExpirationPlugin({
      maxEntries: 50,
    })
  ]
}));

// Register routes
registerRoute(imageRoute);
registerRoute(scriptsRoute);
कॉन्फ़िगर की गई हो

स्टोरेज कोटा का पालन करना मुश्किल हो सकता है. जिन उपयोगकर्ताओं को स्टोरेज की समस्या का सामना करना पड़ रहा है या जो अपने स्टोरेज का बेहतर तरीके से इस्तेमाल करना चाहते हैं उनके लिए यह एक अच्छा तरीका है. Workbox के ExpirationPlugin पेयर से, उस लक्ष्य को हासिल करने में मदद मिल सकती है.

क्रॉस-ऑरिजिन विचार

आपके सर्विस वर्कर और क्रॉस-ऑरिजिन ऐसेट के बीच का इंटरैक्शन, सेम ऑरिजिन ऐसेट के इंटरैक्शन से काफ़ी अलग होता है. क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) काफ़ी जटिल है. साथ ही, किसी सर्विस वर्कर में क्रॉस-ऑरिजिन रिसॉर्स को मैनेज करने के तरीके पर भी यह जटिलता लागू होती है.

ओपेक जवाब

no-cors मोड में क्रॉस-ऑरिजिन अनुरोध करने पर, रिस्पॉन्स को सर्विस वर्कर कैश में सेव किया जा सकता है. यहां तक कि ब्राउज़र भी इसका इस्तेमाल सीधे तौर पर कर सकता है. हालांकि, प्रतिक्रिया के मुख्य भाग को को JavaScript के ज़रिए नहीं पढ़ा जा सकता. इसे ओपेक रिस्पॉन्स के नाम से जाना जाता है.

ओपेक रिस्पॉन्स, सुरक्षा के उपाय हैं. इनका मकसद क्रॉस-ऑरिजिन ऐसेट की जांच को रोकना है. आपके पास अब भी क्रॉस-ऑरिजिन ऐसेट के लिए अनुरोध करने के साथ-साथ उन्हें कैश मेमोरी में सेव करने का विकल्प भी है. ऐसा तब होता है, जब जवाब का मुख्य हिस्सा पढ़ें या उसका स्टेटस कोड भी न पढ़ें!

सीओआरएस मोड में ऑप्ट इन करना न भूलें

अगर आपने ऐसे क्रॉस-ऑरिजिन ऐसेट लोड किए हैं जिनमें अनुमति वाले सीओआरएस हेडर सेट किए गए हैं, तो हो सकता है कि क्रॉस-ऑरिजिन रिस्पॉन्स का मुख्य हिस्सा साफ़ तौर पर न दिखे. उदाहरण के लिए, नीचे दिया गया एचटीएमएल, no-cors अनुरोधों को ट्रिगर करेगा. इन अनुरोधों से आपको कोई जानकारी नहीं मिलेगी. इस बात से कोई फ़र्क़ नहीं पड़ता कि कौनसे सीओआरएस हेडर सेट किए गए हैं:

<link rel="stylesheet" href="https://example.com/path/to/style.css">
<img src="https://example.com/path/to/image.png">

अगर आपको साफ़ तौर पर कोई cors अनुरोध ट्रिगर करना है, तो आपको अपने एचटीएमएल में crossorigin एट्रिब्यूट जोड़कर, सीओआरएस मोड में साफ़ तौर पर ऑप्ट-इन करना होगा:

<link crossorigin="anonymous" rel="stylesheet" href="https://example.com/path/to/style.css">
<img crossorigin="anonymous" src="https://example.com/path/to/image.png">

यह याद रखना ज़रूरी है कि आपके सर्विस वर्कर में सेव किए गए कैश सबरिसॉर्स को रनटाइम के दौरान लोड किया जाता है.

हो सकता है कि वर्कबॉक्स ओपेक जवाबों को कैश मेमोरी में न रखें

डिफ़ॉल्ट रूप से, Workbox अनदेखी जवाबों को कैश मेमोरी में सेव करने के लिए सावधानी बरतता है. यह मुमकिन है कि साफ़ तौर पर न दिखने वाले जवाबों के लिए रिस्पॉन्स कोड की जांच की जा सके. हालांकि, अगर कैश-फ़र्स्ट या सिर्फ़-कैश मेमोरी वाली रणनीति का इस्तेमाल किया जाता है, तो गड़बड़ी के रिस्पॉन्स को कैश मेमोरी में सेव करने का काम लगातार ठीक से काम नहीं कर सकता.

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

अगर किसी दूसरी कैशिंग रणनीति का इस्तेमाल किया जाता है और कोई ओपेक रिस्पॉन्स मिलता है, तो Workbox आपको चेतावनी देगा कि डेवलपमेंट मोड में जवाब को कैश मेमोरी में सेव नहीं किया गया है.

ओपेक जवाबों को ज़बरदस्ती कैश मेमोरी में सेव करने की सुविधा

अगर आपको पूरी तरह भरोसा है कि आपको कैश-फ़र्स्ट या सिर्फ़ कैश मेमोरी की रणनीति का इस्तेमाल करके, ओपेक रिस्पॉन्स को कैश मेमोरी में सेव करना है, तो workbox-cacheable-response मॉड्यूल की मदद से Workbox को ज़बरदस्ती भेजा जा सकता है:

import {Route, registerRoute} from 'workbox-routing';
import {NetworkFirst, StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

const cdnRoute = new Route(({url}) => {
  return url === 'https://cdn.google.com/example-script.min.js';
}, new CacheFirst({
  plugins: [
    new CacheableResponsePlugin({
      statuses: [0, 200]
    })
  ]
}))

registerRoute(cdnRoute);

ओपेक रिस्पॉन्स और navigator.storage एपीआई

क्रॉस-डोमेन जानकारी को लीक होने से बचाने के लिए, स्टोरेज कोटा की सीमाओं का हिसाब लगाने के लिए इस्तेमाल किए जाने वाले ओपेक रिस्पॉन्स के साइज़ में काफ़ी पैडिंग जोड़ दी जाती है. इससे, navigator.storage API स्टोरेज कोटा रिपोर्ट करने के तरीके पर असर पड़ता है.

यह पैडिंग ब्राउज़र के हिसाब से अलग-अलग होती है. हालांकि, Chrome के लिए, कैश मेमोरी में सेव किए गए किसी भी ओपेक रिस्पॉन्स की वजह से स्टोरेज में कम से कम 7 मेगाबाइट का अंतर हो सकता है. आपको कितने अपारदर्शी रिस्पॉन्स को कैश मेमोरी में सेव करना है, यह तय करते समय इस बात को ध्यान में रखना चाहिए. इसकी वजह यह है कि स्टोरेज कोटा को पार करने का विकल्प, उम्मीद से पहले ही मिल जाता है.