इस दस्तावेज़ में पहले से कैश मेमोरी में सेव होने की प्रोसेस के बारे में बताया गया है. हालांकि, यह जानकारी इस बारे में ज़्यादा नहीं है कि इसे कैसे सही किया जाए. यह ज़रूरी है, क्योंकि इस बात से कोई फ़र्क़ नहीं पड़ता कि आपने Workbox का इस्तेमाल किया है या नहीं, लेकिन बहुत ज़्यादा डेटा और बैंडविथ को पहले ही कैश मेमोरी में सेव करना आसान हो जाता है. आपको इस बात का ध्यान रखना चाहिए कि पहले से कैश मेमोरी में सेव होने वाला पेलोड, उपयोगकर्ता अनुभव पर किस तरह असर डालता है.
इस दस्तावेज़ को पढ़ते समय, यह समझ लें कि ये सामान्य दिशा-निर्देश हैं. आपके ऐप्लिकेशन के आर्किटेक्चर और ज़रूरी शर्तों के लिए, आपको यहां सुझाए गए तरीके से अलग काम करने की ज़रूरत पड़ सकती है. हालांकि, ये दिशा-निर्देश अच्छे डिफ़ॉल्ट के तौर पर काम करते हैं.
ऐसा करें: ज़रूरी स्टैटिक ऐसेट को पहले से कैश मेमोरी में सेव करें
प्रीकैशिंग के लिए सबसे अच्छे कैंडिडेट ही अहम स्टैटिक ऐसेट होते हैं, लेकिन इन्हें "क्रिटिकल" के तौर पर गिना जाता है ऐसेट? डेवलपर के नज़रिए से देखें, तो आपको पूरा ऐप्लिकेशन "ज़रूरी" लग सकता है, लेकिन ऐप्लिकेशन को इस्तेमाल करने वाले लोगों का नज़रिया सबसे अहम है. ज़रूरी ऐसेट को ऐसी ऐसेट समझें जो उपयोगकर्ता अनुभव देने के लिए बेहद ज़रूरी हैं:
- ग्लोबल स्टाइलशीट.
- ग्लोबल फ़ंक्शन उपलब्ध कराने वाली JavaScript फ़ाइलें.
- ऐप्लिकेशन शेल एचटीएमएल, अगर वह आपके आर्किटेक्चर पर लागू होता है.
ध्यान रखें: ये सामान्य दिशा-निर्देश हैं, न कि मुश्किल सुझाव. ऐसेट को पहले से कैश मेमोरी में सेव करते समय, बेहतर तरीके से पहले ही कैश मेमोरी में सेव करने का विकल्प चुनें, न कि ज़्यादा.
ऐसा करें: कई पेजों वाली वेबसाइटों के लिए ऑफ़लाइन फ़ॉलबैक को प्रीकैश करें
आम तौर पर, कई पेज वाली वेबसाइटों के लिए, नेविगेशन के अनुरोधों के लिए नेटवर्क-फ़र्स्ट या सिर्फ़ नेटवर्क कैश मेमोरी की रणनीति का इस्तेमाल किया जा सकता है.
ऐसे मामलों में, आपको यह पक्का करना होगा कि जब उपयोगकर्ता ऑफ़लाइन होने पर नेविगेशन का अनुरोध करे, तब आपका सर्विस वर्कर पहले से कैश मेमोरी में सेव करे और ऑफ़लाइन फ़ॉलबैक पेज से जवाब दे. Workbox में ऐसा करने का एक तरीका यह है कि ऑफ़लाइन फ़ॉलबैक के साथ सिर्फ़ नेटवर्क वाली रणनीति का इस्तेमाल किया जा सकता है. साथ ही, नेविगेशन प्रीलोड का इस्तेमाल किया जा सकता है:
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
इससे यह पक्का होता है कि अगर उपयोगकर्ता ऑफ़लाइन हो जाता है और किसी ऐसे पेज पर जाता है जो उसकी कैश मेमोरी में नहीं है, तो उसे कम से कम कुछ ऑफ़लाइन कॉन्टेंट मिल सकता है.
शायद ऐसा करें: अनुमान के हिसाब से पहले से कैश मेमोरी में सेव करने की सुविधा इस्तेमाल करें
यह बहुत बड़ी बात है "शायद" लेकिन उन ऐसेट को पहले से कैश मेमोरी में सेव करने से संभावित फ़ायदा मिलता है जिनका इस्तेमाल सिर्फ़ खास मामलों में किया जाता है. इसके बारे में इस तरह सोचें: उपयोगकर्ताओं को शुरुआत में ही कुछ अतिरिक्त डेटा डाउनलोड करना होगा. इससे, उन ऐसेट के लिए अनुरोध करने की प्रोसेस में तेज़ी से बढ़ोतरी होने का अनुमान है.
अब बड़ी चेतावनी के लिए: अगर आप ऐसा करने का फ़ैसला लेते हैं, तो बहुत सावधान रहें. ऐसा करते समय आसानी से डेटा बर्बाद हो सकता है और यह फ़ैसला डेटा के आधार पर लिया जाना चाहिए. इसके अलावा, अनुमान के हिसाब से पहले से कैश मेमोरी में सेव होने वाली ऐसेट को बार-बार बदलने से बचें. इसकी वजह यह है कि जब भी प्रीकैशिंग कोड को किसी नए बदलाव का पता चलेगा, तब उपयोगकर्ता को डेटा का ज़्यादा इस्तेमाल करना होगा. अपने Analytics में यूज़र फ़्लो पर नज़र रखें और देखें कि उपयोगकर्ता किस ओर जाते हैं. अगर आपको अनुमान के हिसाब से ऐसेट को पहले से कैश मेमोरी में सेव करने के बारे में कोई सवाल है, तो ऐसा न करें.
शायद ऐसा न करें: स्थैतिक HTML को प्रीकैश करें
यह दिशा-निर्देश, स्टैटिक साइट पर ज़्यादा लागू होता है, जहां अलग-अलग एचटीएमएल फ़ाइलें, डाइनैमिक रूप से जनरेट होने या किसी ऐप्लिकेशन के बैक एंड से उपलब्ध कराने के बजाय, स्टैटिक साइट जनरेटर से जनरेट की जाती हैं या मैन्युअल तरीके से बनाई जाती हैं. अगर यह आपके आर्किटेक्चर के बारे में बताती है, तो बेहतर होगा कि आप अपनी वेबसाइट के लिए हर एचटीएमएल फ़ाइल को पहले से कैश मेमोरी में न बदलें.
पूरी साइट की एचटीएमएल फ़ाइलों को पहले से कैश मेमोरी में सेव करने में एक समस्या होती है. यह समस्या यह है कि पहले से कैश मेमोरी में सेव होने वाला मार्कअप, हमेशा कैश मेमोरी से तब तक दिखाया जाता है, जब तक सर्विस वर्कर को अपडेट नहीं किया जाता. परफ़ॉर्मेंस के लिए यह बहुत बढ़िया है, लेकिन अगर आपकी वेबसाइट का एचटीएमएल बार-बार बदलता है, तो कैश मेमोरी में तेज़ी से बदलाव हो सकता है.
हालांकि, इस नियम के कुछ अपवाद भी हैं. अगर कुछ स्टैटिक एचटीएमएल फ़ाइलों वाली छोटी वेबसाइट डिप्लॉय की जा रही है, तो सभी पेजों को पहले से कैश मेमोरी में सेव करना सही रहेगा. इससे, वे ऑफ़लाइन उपलब्ध रहेंगे. अगर आपकी वेबसाइट बहुत बड़ी है, तो ज़्यादा वैल्यू वाले कुछ पेजों को अनुमान के तौर पर पहले से कैश मेमोरी में सेव करें. साथ ही, ऑफ़लाइन फ़ॉलबैक भी लें. साथ ही, दूसरे पेजों को कैश मेमोरी में सेव करने के लिए रनटाइम कैश मेमोरी का इस्तेमाल करें.
ऐसा न करें: रिस्पॉन्सिव इमेज या फ़ेविकॉन को प्रीकैश करें
यह किसी सामान्य दिशा-निर्देश के बारे में नहीं है, बल्कि नियम के बारे में है. रिस्पॉन्सिव इमेज, किसी जटिल समस्या का जटिल समाधान होती हैं: आपके पास कई डिवाइस पर कई उपयोगकर्ता हैं. हर डिवाइस की स्क्रीन का साइज़, पिक्सल डेंसिटी, और अन्य फ़ॉर्मैट काम करते हैं. अगर आप रिस्पॉन्सिव इमेज के पूरे सेट को पहले से कैश मेमोरी में सेव करते हैं, तो हो सकता है कि आप कई इमेज को पहले ही कैश मेमोरी में डाल रहे हों. ऐसा तब होता है, जब उपयोगकर्ता उनमें से किसी एक को ही डाउनलोड करे.
फ़ेविकोन एक ऐसी ही स्थिति दिखाते हैं, जिसमें वेबसाइटें अक्सर अलग-अलग स्थितियों के लिए फ़ेविकॉन का पूरा सेट डिप्लॉय करती हैं. अक्सर, सिर्फ़ एक फ़ेविकॉन का अनुरोध किया जाता है. इस वजह से, पूरे फ़ेविकॉन सेट को पहले से कैश मेमोरी में सेव करना भी बर्बाद हो जाता है.
अपने उपयोगकर्ताओं की मदद करें. साथ ही, रिस्पॉन्सिव इमेज और फ़ेविकॉन सेट को प्रीकैश न करें. इसके बजाय, रनटाइम के दौरान कैश मेमोरी में सेव होने पर भरोसा करें. अगर आपको इमेज को पहले से कैश मेमोरी में सेव करना ज़रूरी है, तो उन इमेज को पहले से कैश मेमोरी में सेव करें जिनका इस्तेमाल बहुत ज़्यादा किया जाता है. ये ऐसी इमेज होती हैं जो रिस्पॉन्सिव इमेज या फ़ेविकॉन के सेट का हिस्सा नहीं हैं. डेटा खर्च के मामले में SVGs कम जोखिम भरा होता है. किसी स्क्रीन के पिक्सल डेंसिटी पर ध्यान दिए बिना, एक SVG सबसे अच्छी तरह रेंडर होता है.
ऐसा न करें: पॉलीफ़िल को प्रीकैश करें
वेब डेवलपर के लिए, एपीआई के लिए अलग-अलग ब्राउज़र पर काम करना एक चुनौती है. साथ ही, इस चुनौती को पूरा करने के कई तरीकों में से एक है पॉलीफ़िलिंग भी. पॉलीफ़िल की परफ़ॉर्मेंस पर आने वाले खर्च को कम करने का एक तरीका यह है कि आप सुविधा की जांच करें और सिर्फ़ उन ब्राउज़र के लिए पॉलीफ़िल लोड करें जिन्हें इनकी ज़रूरत है.
हालांकि, कंडिशनल तौर पर लोड होने वाले पॉलीफ़िल, रनटाइम के दौरान मौजूदा एनवायरमेंट के हिसाब से लोड होते हैं, इसलिए पॉलीफ़िल को पहले से कैश मेमोरी में सेव करना एक जुआ होता है. कुछ उपयोगकर्ताओं को इसका फ़ायदा मिलेगा, जबकि कुछ लोग ग़ैर-ज़रूरी पॉलीफ़िल के लिए बैंडविथ को बर्बाद कर देंगे.
पॉलीफ़िल को प्रीकैश न करें. रनटाइम कैश मेमोरी पर भरोसा करें, ताकि यह पक्का किया जा सके कि डेटा को सिर्फ़ ऐसे ब्राउज़र में कैश मेमोरी में सेव किया जाए जहां इन्हें सेव रखने की ज़रूरत होती है.
नतीजा
पहले से रिकॉर्ड करने की प्रोसेस में, आपको पहले से ही यह तय करने की ज़रूरत होती है कि आपके उपयोगकर्ताओं को कौनसी ऐसेट की ज़रूरत है. हालांकि, इस तरीके को सटीक तरीके से लागू किया जा सकता है, जिससे आने वाले समय में परफ़ॉर्मेंस और विश्वसनीयता को प्राथमिकता दी जा सकती है.
अगर आपको पक्के तौर पर यह नहीं पता है कि कुछ ऐसेट को पहले से कैश मेमोरी में सेव किया जाना चाहिए या नहीं, तो सबसे अच्छा तरीका यह है कि आप Workbox को बताएं कि इन ऐसेट को शामिल न किया जाए. साथ ही, रनटाइम के दौरान कैश मेमोरी में सेव करने के लिए रूट बनाएं. दोनों ही मामलों में, इस दस्तावेज़ में आगे की जानकारी के बारे में विस्तार से बताया गया है, ताकि आने वाले समय में आप इन सिद्धांतों को अपने तर्क पर लागू कर सकें.