सर्विस वर्कर के रजिस्ट्रेशन का समय तय करने के सबसे सही तरीके.
सेवा कर्मचारी आपके वेब ऐप्लिकेशन पर बार-बार आने की रफ़्तार बढ़ा सकते हैं, लेकिन आपको यह पक्का करने के लिए कदम उठाने चाहिए कि सर्विस वर्कर पहली बार इंस्टॉल होने की वजह से, उपयोगकर्ता को पहली बार विज़िट करने का अनुभव खराब न हो.
आम तौर पर, शुरुआती पेज लोड होने तक सर्विस वर्कर रजिस्ट्रेशन को कुछ समय के लिए रोकने से उपयोगकर्ताओं को सबसे अच्छा अनुभव मिलेगा. खास तौर पर, धीमे इंटरनेट कनेक्शन वाले मोबाइल डिवाइस का इस्तेमाल करने वाले लोगों को बेहतर अनुभव मिलेगा.
रजिस्ट्रेशन के सामान्य बॉयलरप्लेट
अगर आपने कभी सर्विस वर्कर के बारे में पढ़ा है, तो आपको शायद नीचे दिए गए बॉयलरप्लेट से मिलता-जुलता कॉन्टेंट देखने को मिला होगा:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/service-worker.js');
}
इसके साथ कभी-कभी कुछ console.log()
स्टेटमेंट या कोड शामिल हो सकता है, जो उपयोगकर्ताओं को पेज रीफ़्रेश करने के बारे में बताता है. ऐसा करने से, पिछले सर्विस वर्कर के रजिस्ट्रेशन में हुए अपडेट का पता चलता है. हालांकि, वे कोड की स्टैंडर्ड कुछ लाइनों
की मामूली वैरिएशन हैं.
तो, क्या navigator.serviceWorker.register
की कोई बारीकता है? क्या कोई ऐसा
सबसे सही तरीका है जिसे फ़ॉलो किया जा सके? कोई हैरानी की बात नहीं कि यह लेख यहीं खत्म नहीं होता,
दोनों का जवाब है "हां!"
उपयोगकर्ता के पहली बार वेबसाइट पर आने का डेटा
मान लेते हैं कि उपयोगकर्ता किसी वेब ऐप्लिकेशन पर पहली बार आता है. यहां अभी तक कोई सर्विस वर्कर नहीं है और ब्राउज़र के पास पहले से यह जानने का कोई तरीका नहीं है कि आखिर में कोई सर्विस वर्कर इंस्टॉल होगा या नहीं.
डेवलपर के तौर पर, आपकी प्राथमिकता यह होनी चाहिए कि ब्राउज़र को इंटरैक्टिव पेज दिखाने के लिए ज़रूरी संसाधनों का कम से कम सेट तुरंत मिले. ऐसी कोई भी चीज़ जो उन जवाबों को पाने की रफ़्तार कम कर देती है, वह तेज़ रफ़्तार से चलाए जाने वाले टाइम-टू-इंटरैक्टिव एक्सपीरियंस का दुश्मन है.
अब कल्पना करें कि आपके पेज को रेंडर करने के लिए JavaScript या इमेज डाउनलोड करने की प्रोसेस में, आपका ब्राउज़र एक बैकग्राउंड थ्रेड या प्रोसेस (कम शब्दों में जानकारी देने के लिए, हम यह मान लेते हैं कि यह एक थ्रेड है) शुरू करने का फ़ैसला करता है. मान लीजिए कि आप किसी बीफ़ डेस्कटॉप मशीन का इस्तेमाल नहीं कर रहे हैं, बल्कि हम जान लें कि इस तरह का मोबाइल फ़ोन कम पावर वाला है जिसे ज़्यादातर लोग अपना मुख्य डिवाइस मानते हैं. इस अतिरिक्त थ्रेड को स्पिन करने से, सीपीयू के समय और मेमोरी पर असर पड़ सकता है. ऐसा न करने पर, आपका ब्राउज़र किसी इंटरैक्टिव वेब पेज को रेंडर करने में खर्च कर सकता है.
ऐसा हो सकता है कि कुछ समय से इस्तेमाल में न होने पर, बैकग्राउंड में चल रही थ्रेड के इस्तेमाल से ज़्यादा फ़र्क़ न पड़े. हालाँकि, क्या होगा सीपीयू या मेमोरी की समस्या से जुड़ी कोई भी चिंता, कई मोबाइल डिवाइसों के लिए उपलब्ध सीमित बैंडविड्थ के बारे में चिंताओं को दूर कर देनी चाहिए. बैंडविथ बहुत अहमियत रखता है. इसलिए, एक ही समय पर दूसरे संसाधनों को डाउनलोड करके, अहम संसाधनों को कम न करें.
इसका मतलब बस यह है कि बैकग्राउंड में संसाधनों को डाउनलोड और कैश मेमोरी में सेव करने के लिए, नए सर्विस वर्कर थ्रेड को स्पिनिंग करके आपकी साइट पर किसी उपयोगकर्ता को पहली बार आने पर सबसे कम समय से इंटरैक्टिव अनुभव देना आपके लक्ष्य को पूरा कर सकता है.
बॉयलरप्लेट को बेहतर बनाना
इस समस्या को हल करने के लिए, सर्विस वर्कर की शुरुआत को कंट्रोल करना है. ऐसा करने के लिए यह चुनें कि navigator.serviceWorker.register()
को कब कॉल करना है. सामान्य नियम यह है कि load
event
के window
पर फ़ायर होने के बाद ही रजिस्ट्रेशन को रोका जा सकता है. इसके कुछ उदाहरण यहां दिए गए हैं:
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('/service-worker.js');
});
}
हालांकि, सर्विस वर्कर रजिस्ट्रेशन शुरू करने का सही समय इस बात पर भी निर्भर कर सकता है कि आपका वेब ऐप्लिकेशन लोड होने के ठीक बाद क्या कर रहा है. उदाहरण के लिए, Google I/O 2016 वेब ऐप्लिकेशन में मुख्य स्क्रीन पर जाने से पहले एक छोटा ऐनिमेशन दिखता है. हमारी टीम ने पाया है कि ऐनिमेशन के दौरान सर्विस वर्कर का रजिस्ट्रेशन शुरू करने से, लो-एंड मोबाइल डिवाइस पर काम करने की संभावना बढ़ सकती है. उपयोगकर्ताओं को खराब अनुभव देने के बजाय, हमने ऐनिमेशन पूरा होने तक सर्विस वर्कर का रजिस्ट्रेशन देर से किया. ऐसा तब हुआ, जब ब्राउज़र के कुछ समय तक इस्तेमाल में न रहने की संभावना ज़्यादा थी.
इसी तरह, अगर आपका वेब ऐप्लिकेशन ऐसे फ़्रेमवर्क का इस्तेमाल करता है जो पेज लोड होने के बाद अतिरिक्त सेटअप करता है, तो फ़्रेमवर्क के हिसाब से बनाया गया ऐसा इवेंट खोजें जिससे काम पूरा होने के बारे में पता चल सके.
बाद में होने वाली विज़िट
हम अब तक पहली विज़िट अनुभव पर ध्यान दे रहे हैं, लेकिन सर्विस वर्कर के रजिस्ट्रेशन में देरी होने से, आपकी साइट पर बार-बार होने वाली विज़िट पर क्या असर पड़ता है? हालांकि, कुछ लोगों को यह बात चौंका सकती है, लेकिन इसका कोई असर नहीं पड़ेगा.
जब किसी सर्विस वर्कर को रजिस्टर किया जाता है, तो यह install
और
activate
लाइफ़साइकल इवेंट से होकर गुज़रता है.
सर्विस वर्कर चालू हो जाने के बाद, यह आपके वेब ऐप्लिकेशन पर बाद में होने वाली किसी भी विज़िट के लिए fetch
इवेंट को मैनेज कर सकता है. सर्विस वर्कर अपने दायरे में आने वाले किसी भी पेज के लिए अनुरोध किए जाने से पहले शुरू होता है, जो आपके सोचने पर सही लगता है. अगर किसी पेज पर जाने से पहले मौजूदा सर्विस वर्कर, पहले से चालू नहीं हो रहा था, तो उसे नेविगेशन अनुरोधों के लिए fetch
इवेंट पूरा करने का मौका नहीं मिलता.
इसलिए, किसी सर्विस वर्कर के चालू होने के बाद, इस बात से कोई फ़र्क़ नहीं पड़ता कि आप
navigator.serviceWorker.register()
को कब कॉल करते हैं. इसके अलावा, इस बात से फ़र्क़ नहीं पड़ता कि
आप उसे कॉल करते हैं या नहीं.
जब तक सर्विस वर्कर स्क्रिप्ट का यूआरएल नहीं बदला जाता, तब तक
अगली विज़िट के दौरान navigator.serviceWorker.register()
,
नो-ऑप नहीं होता है. इसे जब कहा जाता है
वह काम का नहीं होता.
जल्दी रजिस्टर करने की वजहें
क्या कोई ऐसा मामला है जिसमें अपने सर्विस वर्कर को जल्द से जल्द रजिस्टर करना सही रहेगा? सबसे पहले इसका ध्यान तब आता है, जब आपका सर्विस वर्कर पहली बार विज़िट करने के दौरान पेज का कंट्रोल कंट्रोल करने के लिए, clients.claim()
का इस्तेमाल करता है. इसके बाद, सर्विस वर्कर fetch
हैंडलर के अंदर गंभीर तरीके से रनटाइम
कैश मेमोरी में सेव करने की प्रोसेस को पूरा करता है. ऐसी स्थिति में, सर्विस वर्कर को जल्द से जल्द चालू करने का फ़ायदा होता है. इसकी मदद से, रनटाइम कैश मेमोरी में ऐसे संसाधनों को भरा जा सकता है जो बाद में काम आ सकते हैं. अगर
आपका वेब ऐप्लिकेशन इस कैटगरी में आता है, तो यह पक्का करना ज़रूरी है कि
आपके सर्विस वर्कर का install
हैंडलर, उन संसाधनों का अनुरोध न करे जो मुख्य पेज के अनुरोधों के साथ बैंडविथ की अहमियत रखते हैं.
चीज़ों को टेस्ट करना
पहली विज़िट को सिम्युलेट करने का सबसे अच्छा तरीका यह है कि आप अपने वेब ऐप्लिकेशन को Chrome गुप्त विंडो में खोलें. साथ ही, Chrome के DevTools में नेटवर्क ट्रैफ़िक देखें. वेब डेवलपर के तौर पर, हो सकता है कि आप अपने वेब ऐप्लिकेशन के लोकल इंस्टेंस को दिन में दर्जनों और कई बार फिर से लोड करें. हालांकि, अगर पहले से ही कोई सर्विस वर्कर और कैश मेमोरी में सेव सारी जानकारी मौजूद है, तो अपनी साइट पर दोबारा विज़िट करने से आपको वैसा ही अनुभव नहीं मिलता जैसा नए उपयोगकर्ता को मिलता है. साथ ही, किसी संभावित समस्या को अनदेखा करना आसान होता है.
यहां एक उदाहरण में बताया गया है कि रजिस्ट्रेशन के समय में क्या अंतर हो सकता है. धीमे इंटरनेट कनेक्शन को सिम्युलेट करने के लिए, नेटवर्क थ्रॉटलिंग का इस्तेमाल करके गुप्त मोड में सैंपल ऐप्लिकेशन पर जाते समय दोनों स्क्रीनशॉट लिए जाते हैं.
![तय समय से पहले रजिस्ट्रेशन के साथ नेटवर्क ट्रैफ़िक.](https://web.dev/static/articles/service-workers-registration/image/network-traffic-early-re-63d00e80875ce.png?authuser=6&hl=hi)
ऊपर दिया गया स्क्रीनशॉट, नेटवर्क ट्रैफ़िक को दिखाता है, जब सैंपल को सर्विस वर्कर का रजिस्ट्रेशन जल्द से जल्द पूरा करने के लिए बदला गया था. पेज को दिखाने के लिए ज़रूरी अन्य संसाधनों के अनुरोधों के साथ, पहले से कैप्चर किए गए अनुरोधों (उनके बगल में मौजूद गियर आइकॉन वाली एंट्री, जो सर्विस वर्कर के install
हैंडलर से शुरू होती हैं) को देखी जा सकती है.
![देर से रजिस्ट्रेशन करने पर नेटवर्क ट्रैफ़िक.](https://web.dev/static/articles/service-workers-registration/image/network-traffic-late-reg-17e31ea5d01ab.png?authuser=6&hl=hi)
ऊपर दिए गए स्क्रीनशॉट में, पेज लोड होने तक सर्विस वर्कर के रजिस्ट्रेशन में देरी हुई. देख सकते हैं कि पहले से कैश मेमोरी में सेव करने के अनुरोध तब तक शुरू नहीं होते, जब तक नेटवर्क से सभी संसाधन फ़ेच नहीं हो जाते. इससे बैंडविथ से जुड़ी कोई भी समस्या खत्म हो जाती है. इसके अलावा, क्योंकि कुछ ऐसे आइटम जिन्हें हम प्रीकैश कर रहे हैं
वे पहले से ही ब्राउज़र के एचटीटीपी कैश में मौजूद होते हैं, यानी कि साइज़ कॉलम में (from disk cache)
वाले आइटम. हम नेटवर्क पर दोबारा जाए बिना ही, सर्विस वर्कर के कैश में जानकारी भर सकते हैं.
असली मोबाइल नेटवर्क पर, कम कीमत वाले डिवाइस से इस तरह का टेस्ट करने पर बोनस पॉइंट. यूएसबी के ज़रिए Android फ़ोन को अपनी डेस्कटॉप मशीन से अटैच करने के लिए, Chrome की रिमोट डीबग करने की क्षमताओं का फ़ायदा लिया जा सकता है. साथ ही, यह पक्का किया जा सकता है कि जो टेस्ट चलाए जा रहे हैं वे आपके कई उपयोगकर्ताओं का असल अनुभव दिखाते हों.
नतीजा
संक्षेप में, यह पक्का करना सबसे पहली प्राथमिकता होनी चाहिए कि आपके उपयोगकर्ताओं को पहली बार वेबसाइट पर आने का बेहतरीन अनुभव मिले. शुरुआती विज़िट के दौरान, पेज लोड होने तक सर्विस वर्कर के रजिस्ट्रेशन को देर से करने से, यह पक्का किया जा सकता है. आपको अब भी अपनी बार-बार होने वाली विज़िट के लिए सर्विस वर्कर के सभी फ़ायदे मिलेंगे.
पहले पेज के लोड होने तक, अपने सर्विस वर्कर के शुरुआती रजिस्ट्रेशन को देर से शुरू करने का आसान तरीका यह है कि आप नीचे दिए गए निर्देशों का इस्तेमाल करें:
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('/service-worker.js');
});
}