सेवा वर्कर के रजिस्ट्रेशन के लिए समय तय करने के सबसे सही तरीके.
सेवा वर्कर्स की मदद से, आपके वेब ऐप्लिकेशन पर बार-बार आने में लगने वाला समय कम किया जा सकता है. हालांकि, आपको यह पक्का करना होगा कि सेवा वर्कर्स के शुरुआती इंस्टॉलेशन से, उपयोगकर्ता के पहली बार आने के अनुभव पर कोई असर न पड़े.
आम तौर पर, शुरुआती पेज लोड होने तक, सेवा वर्कर के रजिस्ट्रेशन को टालने से, उपयोगकर्ताओं को बेहतर अनुभव मिलता है. खास तौर पर, उन उपयोगकर्ताओं को जो धीमे इंटरनेट कनेक्शन वाले मोबाइल डिवाइसों का इस्तेमाल करते हैं.
सामान्य रजिस्ट्रेशन बॉयलरप्लेट
अगर आपने कभी सेवा वर्कर के बारे में पढ़ा है, तो आपको शायद कुछ ऐसा बोइलरप्लेट मिला हो जो काफ़ी हद तक यहां दिए गए बोइलरप्लेट से मिलता-जुलता हो:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/service-worker.js');
}
कभी-कभी ऐसा कुछ console.log() स्टेटमेंट या कोड के साथ हो सकता है जो किसी पिछले सर्विस वर्कर रजिस्ट्रेशन में हुए अपडेट का पता लगाता है. इससे उपयोगकर्ताओं को पेज रीफ़्रेश करने के बारे में जानकारी मिलती है. हालांकि, ये कोड की कुछ लाइनों में हुए छोटे-मोटे बदलाव हैं.
तो, क्या navigator.serviceWorker.register में कोई अंतर है? क्या इनके लिए कोई सबसे सही तरीका है? इस लेख में आगे बताया गया है कि इन दोनों सवालों का जवाब "हां!" है.
उपयोगकर्ता की पहली विज़िट
मान लें कि कोई उपयोगकर्ता किसी वेब ऐप्लिकेशन पर पहली बार आया है. अब तक कोई सर्विस वर्कर नहीं है और ब्राउज़र के पास यह जानने का कोई तरीका नहीं है कि आखिर में कोई सर्विस वर्कर इंस्टॉल होगा या नहीं.
डेवलपर के तौर पर, आपकी प्राथमिकता यह होनी चाहिए कि ब्राउज़र को कोई इंटरैक्टिव पेज दिखाने के लिए, ज़रूरी संसाधनों का कम से कम सेट तुरंत मिल जाए. जो कुछ भी उन प्रतिक्रियाओं को वापस पाने में समय लेता है, वह तेज़ स्पीड वाले टाइम-टू-इंटरैक्टिव अनुभव के ख़िलाफ़ है.
अब मान लें कि आपके पेज को जिन JavaScript या इमेज को रेंडर करना है उन्हें डाउनलोड करने की प्रोसेस में, आपका ब्राउज़र बैकग्राउंड थ्रेड या प्रोसेस शुरू करने का फ़ैसला करता है. इसे छोटा रखने के लिए, हम इसे एक थ्रेड मानेंगे. मान लें कि आपके पास एक बेहतरीन डेस्कटॉप मशीन नहीं है, बल्कि एक ऐसा मोबाइल फ़ोन है जिसे दुनिया के ज़्यादातर लोग अपना मुख्य डिवाइस मानते हैं. इस अतिरिक्त थ्रेड को शुरू करने से, सीपीयू के समय और मेमोरी पर असर पड़ता है. इस समय और मेमोरी का इस्तेमाल, आपका ब्राउज़र किसी इंटरैक्टिव वेब पेज को रेंडर करने के लिए कर सकता है.
कुछ समय से इस्तेमाल में न होने पर, बैकग्राउंड में चल रहे थ्रेड पर शायद ज़्यादा असर न पड़े. हालांकि, अगर वह थ्रेड काम नहीं कर रही है, लेकिन नेटवर्क से संसाधन डाउनलोड करने का फ़ैसला लेती है, तो क्या होगा? सीपीयू या मेमोरी के इस्तेमाल से जुड़ी किसी भी समस्या को, कई मोबाइल डिवाइसों के लिए उपलब्ध सीमित बैंडविड्थ की समस्या के मुकाबले कम अहमियत दी जानी चाहिए. बैंडविड्थ की अहमियत बहुत ज़्यादा है. इसलिए, एक ही समय पर कम अहमियत वाले रिसोर्स डाउनलोड करके, ज़रूरी रिसोर्स को कम अहमियत न दें.
इसका मतलब है कि बैकग्राउंड में संसाधनों को डाउनलोड और कैश मेमोरी में सेव करने के लिए, नई सेवा वर्कर थ्रेड को स्पिन अप करने से, उपयोगकर्ता को आपकी साइट पर पहली बार आने पर, इंटरैक्टिव अनुभव देने के आपके लक्ष्य के ख़िलाफ़ काम किया जा सकता है.
बॉयलरप्लेट को बेहतर बनाना
इसका समाधान यह है कि navigator.serviceWorker.register() को कॉल करने का समय चुनकर, सेवा वर्कर के शुरू होने को कंट्रोल किया जाए. एक आसान नियम यह है कि window पर load
event ट्रिगर होने तक, रजिस्ट्रेशन में देरी करें. जैसे:
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 में नेटवर्क ट्रैफ़िक देखें. एक वेब डेवलपर के रूप में, हो सकता है कि आप अपने वेब ऐप्लिकेशन के किसी स्थानीय इंस्टेंस को दिन में दर्जनों और कई बार फिर से लोड करते हों. हालांकि, जब आपकी साइट पर पहले से ही कोई सेवा वर्कर मौजूद हो और कैश मेमोरी पूरी तरह से भरी हो, तो साइट पर दोबारा जाने पर आपको वैसा अनुभव नहीं मिलता जैसा किसी नए उपयोगकर्ता को मिलता है. साथ ही, किसी संभावित समस्या को अनदेखा करना आसान हो जाता है.
यहां एक उदाहरण दिया गया है, जिसमें बताया गया है कि रजिस्ट्रेशन के समय की वजह से क्या अंतर हो सकता है. दोनों स्क्रीनशॉट, गुप्त मोड में सैंपल ऐप्लिकेशन पर विज़िट करते समय लिए गए हैं. इनमें, धीमे कनेक्शन का अनुकरण करने के लिए, नेटवर्क को धीमा किया गया है.
ऊपर दिए गए स्क्रीनशॉट में, नेटवर्क ट्रैफ़िक दिखाया गया है. यह ट्रैफ़िक तब रिकॉर्ड किया गया था, जब सैंपल में बदलाव करके, सेवा वर्कर को जल्द से जल्द रजिस्टर किया गया था. आपको पहले से कैश मेमोरी में सेव किए गए अनुरोध दिखेंगे. ये अनुरोध, सर्विस वर्कर के install हैंडलर से शुरू होने वाले गियर आइकॉन वाली एंट्री के बगल में होते हैं. इनके साथ, पेज को दिखाने के लिए ज़रूरी अन्य संसाधनों के अनुरोध भी देखे जा सकते हैं.
ऊपर दिए गए स्क्रीनशॉट में, सर्विस वर्कर के रजिस्ट्रेशन में पेज लोड होने तक देरी हुई. यह देखा जा सकता है कि पहले से कैश मेमोरी में सेव करने के अनुरोध तब तक शुरू नहीं होते, जब तक नेटवर्क से सभी संसाधन फ़ेच नहीं हो जाते. ऐसा करने से, बैंडविथ से जुड़ी कोई समस्या नहीं रहती. इसके अलावा, हम जिन आइटम को पहले से कैश मेमोरी में सेव कर रहे हैं वे पहले से ही ब्राउज़र के एचटीटीपी कैश मेमोरी में मौजूद होते हैं. ये वे आइटम होते हैं जिनके साइज़ कॉलम में (from disk cache) होता है. इसलिए, हम नेटवर्क पर फिर से जाने के बिना, सेवा वर्कर के कैश मेमोरी को पॉप्युलेट कर सकते हैं.
असली मोबाइल नेटवर्क पर, कम कीमत वाले किसी असल डिवाइस से इस तरह का टेस्ट चलाने पर बोनस पॉइंट मिलते हैं. Chrome की रिमोट डीबगिंग की सुविधाओं का इस्तेमाल करके, किसी Android फ़ोन को यूएसबी के ज़रिए अपने डेस्कटॉप मशीन से जोड़ा जा सकता है. इससे यह पक्का किया जा सकता है कि आपके ऐप्लिकेशन के लिए की जा रही जांच, असल में आपके कई उपयोगकर्ताओं के अनुभव को दिखाती हो.
नतीजा
खास तौर पर, यह पक्का करना कि उपयोगकर्ताओं को पहली बार आने पर सबसे अच्छा अनुभव मिले, यह आपकी सबसे पहली प्राथमिकता होनी चाहिए. पहली विज़िट के दौरान, पेज लोड होने तक सर्विस वर्कर के रजिस्ट्रेशन में देरी करने से, यह पक्का करने में मदद मिल सकती है. हालांकि, आपको फिर से आने वाले उपयोगकर्ताओं के लिए, अब भी सेवा वर्कर के सभी फ़ायदे मिलते रहेंगे.
अपने सेवा वर्कर के शुरुआती रजिस्ट्रेशन को पहले पेज के लोड होने तक रोकने के लिए, यहां दिए गए तरीके का इस्तेमाल करें:
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('/service-worker.js');
});
}