सर्विस वर्कर का इस्तेमाल करके, नेटवर्क पर इंतज़ार किए बिना नेविगेशन के अनुरोधों का जवाब दें.
नेविगेशन के अनुरोध, एचटीएमएल दस्तावेज़ों के लिए बनाए गए वे अनुरोध होते हैं जिन्हें आपका ब्राउज़र बनाता है. ऐसा तब होता है, जब नेविगेशन बार में कोई नया यूआरएल डाला जाता है या किसी पेज पर मौजूद लिंक पर क्लिक करके, आपको नए यूआरएल पर ले जाया जाता है. यहां सर्विस वर्कर, परफ़ॉर्मेंस पर सबसे ज़्यादा असर डालते हैं. अगर आपने नेटवर्क का इंतज़ार किए बिना नेविगेशन के अनुरोधों का जवाब देने के लिए किसी सर्विस वर्कर का इस्तेमाल किया है, तो नेटवर्क उपलब्ध न होने पर नेविगेशन की सुविधा की मदद ली जा सकती है. साथ ही, नेविगेशन को बेहतर बनाया जा सकता है. यह सर्विस वर्कर की वजह से हुई अब तक की सबसे बड़ी परफ़ॉर्मेंस है, जबकि एचटीटीपी कैशिंग से मिलने वाले फ़ायदों की तुलना में यह सबसे बड़ी है.
जैसा कि नेटवर्क से लोड किए गए रिसॉर्स की पहचान करना गाइड में बताया गया है, नेटवर्क ट्रैफ़िक के "वॉटरफ़ॉल" में किए जाने वाले कई संभावित अनुरोधों में से पहला अनुरोध नेविगेशन अनुरोध होता है. नेविगेशन अनुरोध के ज़रिए लोड किया जाने वाला एचटीएमएल, इमेज, स्क्रिप्ट, और स्टाइल जैसे सबरिसॉर्स के लिए अन्य सभी अनुरोधों का फ़्लो शुरू करता है.
सर्विस वर्कर के fetch इवेंट हैंडलर के अंदर, FetchEvent पर request.mode प्रॉपर्टी की जांच करके पता लगाया जा सकता है कि कोई अनुरोध, नेविगेशन है या नहीं. अगर इसे 'navigate' पर सेट किया गया है,
तो इसका मतलब है कि नेविगेशन का अनुरोध है.
सामान्य नियम के तौर पर, नेविगेशन अनुरोध के एचटीएमएल रिस्पॉन्स को कैश मेमोरी में सेव करने के लिए, लंबे समय तक चलने वाले Cache-Control headers का इस्तेमाल न करें. आम तौर पर, उन्हें नेटवर्क के ज़रिए Cache-Control: no-cache से संतुष्ट होना चाहिए, ताकि यह पक्का किया जा सके कि बाद में आने वाले नेटवर्क अनुरोधों की चेन के साथ-साथ एचटीएमएल (ज़रूरी) नया हो. जब भी उपयोगकर्ता किसी नए पेज पर जाता है, तो हर बार नेटवर्क पर जाने का मतलब है कि हर नेविगेशन धीमा हो सकता है. कम से कम इसका मतलब है कि यह
तेज़ भरोसेमंद तरीके से काम नहीं करेगा.
आर्किटेक्चर के लिए अलग-अलग तरीके
नेटवर्क से बचते हुए, नेविगेशन अनुरोधों का जवाब देने का तरीका पता करना मुश्किल हो सकता है. सही तरीका, आपकी वेबसाइट के डिज़ाइन और उपयोगकर्ताओं के लिए इस्तेमाल किए जाने वाले यूनीक यूआरएल की संख्या पर निर्भर करता है.
सभी तरह के समाधान एक जैसे नहीं होते, लेकिन यहां दिए गए सामान्य दिशा-निर्देशों से आपको यह तय करने में मदद मिलेगी कि कौनसा तरीका सबसे सही है.
छोटी स्टैटिक साइटें
अगर आपके वेब ऐप्लिकेशन में बाकी यूआरएल की संख्या (कुछ दर्जन) यूनीक यूआरएल हैं और उनमें से हर यूआरएल एक अलग स्टैटिक एचटीएमएल फ़ाइल से जुड़ा है, तो इसका एक कारगर तरीका यह है कि आप उन सभी एचटीएमएल फ़ाइलों को कैश मेमोरी में सेव कर लें और कैश मेमोरी में सेव किए गए सही एचटीएमएल का इस्तेमाल करके नेविगेशन के अनुरोधों का जवाब दें.
प्रीकैशिंग का इस्तेमाल करके, सर्विस वर्कर के इंस्टॉल होते ही, एचटीएमएल को पहले से कैश किया जा सकता है. साथ ही, हर बार साइट बनाने और सर्विस वर्कर को फिर से डिप्लॉय करने पर, कैश मेमोरी में सेव किए गए एचटीएमएल को अपडेट किया जा सकता है.
इसके अलावा, अगर आपको अपने पूरे एचटीएमएल को पहले से कैश मेमोरी में सेव करने से बचना है, तो इसकी वजह यह है कि उपयोगकर्ता अक्सर आपकी साइट के यूआरएल के किसी सबसेट पर ही जाते हैं. इसके अलावा, रनटाइम के दौरान फिर से पुष्टि करने के दौरान, कैश मेमोरी में सेव करने की पुरानी रणनीति का इस्तेमाल किया जा सकता है. हालांकि, इस तरीके को लेकर सावधान रहें, क्योंकि हर एचटीएमएल दस्तावेज़ को कैश मेमोरी में सेव करके, अलग-अलग अपडेट किया जाता है. एचटीएमएल के लिए रनटाइम कैश मेमोरी का इस्तेमाल करना तब सबसे सही होता है, जब आपके पास बहुत कम ऐसे यूआरएल हों जिन पर उपयोगकर्ता का एक ही सेट अक्सर विज़िट किया जाता हो. साथ ही, अगर आपको लगता है कि उन यूआरएल को एक-दूसरे से अलग, दोबारा पुष्टि किया जा रहा है.
एक पेज वाले ऐप्लिकेशन
मॉडर्न वेब ऐप्लिकेशन अक्सर एक पेज वाले आर्किटेक्चर का इस्तेमाल करते हैं. इसमें क्लाइंट-साइड JavaScript, उपयोगकर्ता की कार्रवाइयों के जवाब में एचटीएमएल में बदलाव करता है. यह मॉडल, मौजूदा यूआरएल में बदलाव करने के लिए इतिहास एपीआई का इस्तेमाल करता है. ऐसा तब होता है, जब उपयोगकर्ता वेब ऐप्लिकेशन के साथ इंटरैक्ट करता है. इस तरह, यह "सिम्युलेटेड" नेविगेशन पर ले जाता है. हालांकि, आगे के नेविगेशन "नकली" हो सकते हैं, लेकिन शुरुआती नेविगेशन असली होता है. साथ ही, यह पक्का करना ज़रूरी है कि यह नेटवर्क पर ब्लॉक न हो.
अच्छी बात यह है कि एक पेज के आर्किटेक्चर का इस्तेमाल करने पर, कैश मेमोरी से शुरुआती नेविगेशन दिखाने के लिए एक आसान पैटर्न का इस्तेमाल किया जा सकता है: ऐप्लिकेशन शेल. इस मॉडल में, आपका सर्विस वर्कर, नेविगेशन के अनुरोधों का जवाब देने के लिए, पहले से कैश मेमोरी में सेव की गई एक ही एचटीएमएल फ़ाइल को लौटाता है. भले ही, किसी भी यूआरएल का अनुरोध किया गया हो. यह एचटीएमएल बहुत ज़्यादा ज़रूरी नहीं होना चाहिए. इसमें एक सामान्य लोडिंग इंडिकेटर या कंकाल का कॉन्टेंट हो सकता है. जब ब्राउज़र इस एचटीएमएल को कैश मेमोरी से लोड कर लेता है, तब मौजूदा क्लाइंट-साइड JavaScript इसे अधिग्रहण कर लेता है. साथ ही, मूल नेविगेशन अनुरोध के यूआरएल के लिए सही एचटीएमएल कॉन्टेंट रेंडर करता है.
Workbox ऐसे टूल उपलब्ध कराता है जिनकी मदद से इस तरीके को लागू किया जा सकता है; navigateFallback
option
की मदद से यह तय किया जा सकता है कि ऐप्लिकेशन शेल के तौर पर किस एचटीएमएल दस्तावेज़ का इस्तेमाल किया जाए. साथ ही, इसमें यूआरएल के किसी सबसेट के लिए अनुमति और
अस्वीकार की जाने वाली सूची का इस्तेमाल भी किया जा सकता है.
कई पेजों वाले ऐप्लिकेशन
अगर वेब सर्वर आपकी साइट का एचटीएमएल डाइनैमिक तौर पर जनरेट करता है या आपके पास कुछ दर्जन से ज़्यादा यूनीक पेज हैं, तो नेविगेशन के अनुरोधों को मैनेज करते समय नेटवर्क से बचना ज़्यादा मुश्किल है. बाकी सब कुछ में दी गई सलाह आप पर लागू होगी.
हालांकि, कई पेज वाले ऐप्लिकेशन के कुछ सबसेट के लिए, आपको सर्विस वर्कर लागू करने की सुविधा मिल सकती है. यह, एचटीएमएल जनरेट करने के लिए आपके वेब सर्वर में इस्तेमाल किए गए लॉजिक को पूरी तरह से कॉपी करता है. यह सबसे अच्छी तरह तब काम करता है, जब आप सर्वर और सर्विस वर्कर एनवायरमेंट के बीच रूटिंग और टेंप्लेट की जानकारी शेयर कर सकें. खास तौर पर तब, जब आपका वेब सर्वर JavaScript (Node.js की खास सुविधाओं, जैसे कि फ़ाइल सिस्टम के ऐक्सेस पर भरोसा किए बिना) का इस्तेमाल करता है.
अगर आपका वेब सर्वर उस कैटगरी में आता है और आपको नेटवर्क से एचटीएमएल जनरेट करने और सर्विस वर्कर पर जाने का एक तरीका जानना है, तो एसपीए से बाहर: आपके पीडब्ल्यूए के लिए वैकल्पिक आर्किटेक्चर में दिए गए निर्देश आपको शुरुआत करने में मदद कर सकते हैं.
शेष सब कुछ
अगर आप कैश मेमोरी में सेव किए गए एचटीएमएल से नेविगेशन के अनुरोधों का जवाब नहीं दे पा रहे हैं, तो आपको यह पक्का करने के लिए कदम उठाने होंगे कि आपकी साइट में सर्विस वर्कर जोड़ने से (अन्य, बिना एचटीएमएल वाले अनुरोधों को मैनेज करने के लिए) आपके नेविगेशन की रफ़्तार धीमी न हो. नेविगेशन अनुरोध का जवाब देने के लिए सर्विस वर्कर का इस्तेमाल किए बिना शुरू करने पर, इंतज़ार का समय कम हो सकता है. (जैसा कि सर्विस वर्कर वाले ऐप्लिकेशन तेज़ी से और बेहतर तरीके से बनाना में बताया गया है). नेविगेशन प्रीलोड नाम की सुविधा को चालू करके और फिर नेटवर्क रिस्पॉन्स
का इस्तेमाल करके, जो आपके fetch इवेंट हैंडलर में पहले से लोड है, इस ओवरहेड को कम किया जा सकता है.
Workbox एक हेल्पर लाइब्रेरी उपलब्ध कराता है, जो यह बताती है कि नेविगेशन पहले से लोड करने की सुविधा काम करती है या नहीं. अगर ऐसा है, तो यह अपने सर्विस वर्कर को नेटवर्क रिस्पॉन्स इस्तेमाल करने के बारे में बताने की प्रोसेस को आसान बनाता है.