इस दस्तावेज़ में पहले से कैश मेमोरी में सेव किए गए डेटा को शामिल किया गया है, लेकिन इसे ठीक करने के बारे में ज़्यादा जानकारी नहीं है. यह अहम है, क्योंकि भले ही Workbox का इस्तेमाल किया जा रहा हो या नहीं, बहुत ज़्यादा डेटा पहले से कैश मेमोरी में सेव करना आसान होता है. इससे डेटा और बैंडविथ को भी नुकसान हो सकता है. आपको इस बारे में सावधान रहना चाहिए कि पहले से कैश मेमोरी में सेव किए गए पेलोड की वजह से, उपयोगकर्ता अनुभव पर क्या असर पड़ता है.
इस दस्तावेज़ को पढ़ते समय, यह समझ लें कि ये सामान्य दिशा-निर्देश हैं. आपके ऐप्लिकेशन के आर्किटेक्चर और ज़रूरी शर्तों के लिए, आपको यहां सुझाए गए काम करने के तरीके से कुछ अलग काम करना पड़ सकता है. हालांकि, ये दिशा-निर्देश, डिफ़ॉल्ट के तौर पर काम करते हैं.
ऐसा करें: क्रिटिकल स्टैटिक ऐसेट को पहले से कैश मेमोरी में सेव करें
प्री-कैशिंग के लिए सबसे अच्छे कैंडिडेट, क्रिटिकल स्टैटिक ऐसेट होती हैं, लेकिन इन्हें "क्रिटिकल" ऐसेट के तौर पर माना जाता है? डेवलपर के नज़रिए से, किसी पूरे ऐप्लिकेशन को "गंभीर" के रूप में देखना आकर्षक हो सकता है, लेकिन उपयोगकर्ता का नज़रिया सबसे ज़्यादा मायने रखता है. अहम ऐसेट को ऐसे ऐसेट के तौर पर देखें जो उपयोगकर्ता को बेहतर अनुभव देने के लिए बहुत ज़रूरी हैं:
- ग्लोबल स्टाइलशीट.
- ग्लोबल फ़ंक्शन देने वाली JavaScript फ़ाइलें.
- ऐप्लिकेशन शेल एचटीएमएल, अगर यह आपके आर्किटेक्चर पर लागू होता है.
ध्यान रखें: ये सामान्य दिशा-निर्देश हैं, न कि मुश्किल सुझाव. एसेट को प्री-कैश करते समय, ज़्यादा के बजाय पहले से कैश मेमोरी में सेव करने का इस्तेमाल करना सबसे अच्छा होता है.
ऐसा करें: कई पेज वाली वेबसाइटों के लिए, ऑफ़लाइन फ़ॉलबैक को प्री-कैश करें
आम तौर पर, कई पेज वाली वेबसाइटों के लिए, नेविगेशन के अनुरोधों से निपटने के लिए, नेटवर्क पहले या सिर्फ़ नेटवर्क को कैश मेमोरी में सेव करने की रणनीति का इस्तेमाल किया जा सकता है.
ऐसे मामलों में, आपको यह पक्का करना होगा कि जब उपयोगकर्ता ऑफ़लाइन होने पर नेविगेशन का अनुरोध करता है, तब आपका सर्विस वर्कर, प्री-कैश मेमोरी में सेव करता है और ऑफ़लाइन फ़ॉलबैक पेज के साथ जवाब देता है. वर्कबॉक्स में ऐसा करने का एक तरीका यह है कि आप ऑफ़लाइन फ़ॉलबैक के साथ सिर्फ़ नेटवर्क वाली रणनीति का इस्तेमाल करें. इसके अलावा, नेविगेशन प्रीलोड का भी इस्तेमाल करें:
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 में यूज़र फ़्लो पर नज़र रखें और देखें कि उपयोगकर्ता कहां जाते हैं. अगर आपको अनुमान के आधार पर एसेट के पहले से दावा करने के बारे में कोई शंका है, तो ऐसा करना नहीं माना जाएगा.
शायद न करें: स्टैटिक एचटीएमएल को प्रीकैश करें
यह दिशा-निर्देश उन स्टैटिक साइटों पर ज़्यादा लागू होता है जहां अलग-अलग एचटीएमएल फ़ाइलें डाइनैमिक रूप से जनरेट की जाने वाली या ऐप्लिकेशन बैक एंड से उपलब्ध कराने के बजाय, स्टैटिक साइट जनरेटर से जनरेट की जाती हैं या मैन्युअल तरीके से बनाई जाती हैं. अगर इससे आपके आर्किटेक्चर की जानकारी मिलती है, तो बेहतर होगा कि आप अपनी वेबसाइट की हर एचटीएमएल फ़ाइल को प्री-कैश न करें.
पूरी साइट की एचटीएमएल फ़ाइलों को पहले से कैश मेमोरी में सेव करने में एक समस्या यह है कि अब पहले से कैश मेमोरी में सेव किए गए मार्कअप को, सर्विस वर्कर के अपडेट होने तक हमेशा कैश मेमोरी से दिखाया जाएगा. यह परफ़ॉर्मेंस के लिए बहुत अच्छा है, लेकिन अगर आपकी वेबसाइट के एचटीएमएल बार-बार बदलते हैं, तो इससे कैश मेमोरी में ज़्यादा बदलाव हो सकते हैं.
हालांकि, इस नियम में कुछ अपवाद हैं. अगर आपको कुछ स्टैटिक एचटीएमएल फ़ाइलों वाली किसी छोटी वेबसाइट को डिप्लॉय करना है, तो उन सभी पेजों को प्री-कैश करना ठीक रहेगा, ताकि वे ऑफ़लाइन उपलब्ध हो सकें. अगर आपके पास खास तौर पर बड़ी वेबसाइट है, तो कुछ ज़्यादा अहम पेजों और ऑफ़लाइन फ़ॉलबैक का अनुमान लगाकर, पहले से कैश मेमोरी में सेव करने के बारे में सोचें. साथ ही, अपने लिए दूसरे पेजों को कैश मेमोरी में सेव करने के लिए, रनटाइम की कैश मेमोरी का इस्तेमाल करें.
ऐसा न करें: रिस्पॉन्सिव इमेज या फ़ेविकॉन को प्री-कैश करें
यह किसी सामान्य दिशा-निर्देश से कम और नियम की ज़्यादा जानकारी है. रिस्पॉन्सिव इमेज, किसी मुश्किल समस्या का एक जटिल समाधान है. आपके पास कई डिवाइसों को इस्तेमाल करने वाले कई उपयोगकर्ता होते हैं. हर डिवाइस के स्क्रीन साइज़, पिक्सल डेंसिटी, और अन्य फ़ॉर्मैट वाले डिवाइसों का इस्तेमाल अलग-अलग होता है. अगर आपने रिस्पॉन्सिव इमेज के पूरे सेट को पहले से कैश मेमोरी में सेव किया है, तो हो सकता है कि आपने कई इमेज को पहले से कैश मेमोरी में सेव किया हो. ऐसा तब होता है, जब उपयोगकर्ता उनमें से किसी एक इमेज को ही डाउनलोड करता है.
फ़ेविकॉन भी इसी तरह की स्थिति रखते हैं. इसमें वेबसाइटें अक्सर अलग-अलग स्थितियों के लिए फ़ेविकॉन का एक पूरा सेट डिप्लॉय करती हैं. अक्सर, सिर्फ़ एक फ़ेविकॉन का अनुरोध किया जाता है. इससे, पूरे फ़ेविकॉन सेट को पहले से ही बेकार में माना जाता है.
अपने उपयोगकर्ताओं की मदद करें और रिस्पॉन्सिव इमेज और फ़ेविकॉन सेट को पहले से कैश मेमोरी में न सेव करें. इसके बजाय, रनटाइम कैशिंग पर भरोसा करें. अगर आपको इमेज को प्री-कैश करना ज़रूरी है, तो बड़े पैमाने पर इस्तेमाल की जाने वाली उन इमेज को पहले से कैश मेमोरी में सेव करें जो रिस्पॉन्सिव इमेज या फ़ेविकॉन के सेट का हिस्सा नहीं हैं. डेटा खर्च के मामले में, SVG कम जोखिम वाले होते हैं. किसी भी स्क्रीन की पिक्सल डेंसिटी पर ध्यान दिए बिना, एक ही SVG फ़ाइल बेहतर तरीके से रेंडर होती है.
ऐसा न करें: प्री-कैश पॉलीफ़िल
एपीआई के लिए अलग-अलग ब्राउज़र सपोर्ट होना, वेब डेवलपर के लिए एक बड़ी चुनौती है. पॉलीफ़िलिंग उन तरीकों में से एक है जिनसे इस चुनौती को पूरा किया जा सकता है. पॉलीफ़िल की परफ़ॉर्मेंस पर होने वाले खर्च को कम करने का एक तरीका यह है कि आप सुविधाओं की जांच करें और सिर्फ़ उन ब्राउज़र के लिए पॉलीफ़िल लोड करें जिन्हें इसकी ज़रूरत है.
मौजूदा एनवायरमेंट के हिसाब से, रनटाइम के दौरान पॉलीफ़िल को शर्तों के साथ लोड करना एक जोखिम भरा काम होता है. कुछ लोगों को इससे फ़ायदा होगा, जबकि कुछ लोगों को बेवजह पॉलीफ़िल की वजह से बैंडविड्थ बर्बाद हो जाएगी.
पॉलीफ़िल को प्री-कैश न करें. यह पक्का करने के लिए रनटाइम कैशिंग पर भरोसा करें कि वे सिर्फ़ उन ब्राउज़र में कैश मेमोरी में सेव हों जिनमें डेटा को बर्बाद होने से बचाना ज़रूरी होता है.
नतीजा
पहले से कैश मेमोरी में सेव करने के लिए, इस बात का पता लगाना ज़रूरी होता है कि आपके उपयोगकर्ताओं को किन ऐसेट की असल में ज़रूरत है. हालांकि, आपको इन्हें हासिल करने का मौका मिलता है, ताकि आने वाले समय में परफ़ॉर्मेंस और विश्वसनीयता को प्राथमिकता दी जा सके.
अगर आपको यह पक्के तौर पर नहीं पता कि कुछ ऐसेट को पहले से कैश मेमोरी में सेव किया जाना चाहिए या नहीं, तो सबसे अच्छा तरीका यह होगा कि Workbox को उन ऐसेट को बाहर रखने के लिए कहा जाए और उन्हें मैनेज करने के लिए रनटाइम को कैश मेमोरी में सेव किया जाए. दोनों में से किसी भी स्थिति में, प्री-कैशिंग के बारे में इस दस्तावेज़ में आगे विस्तार से बताया गया है, ताकि आप आने वाले समय में इन सिद्धांतों को अपने प्री-कैशिंग लॉजिक पर लागू कर सकें.