वेब वर्कर और सर्विस वर्कर, आपकी साइट की परफ़ॉर्मेंस को कैसे बेहतर बना सकते हैं. साथ ही, वेब वर्कर और सर्विस वर्कर का इस्तेमाल कब करना चाहिए.
इस खास जानकारी में बताया गया है कि वेब वर्कर और सर्विस वर्कर, आपकी वेबसाइट की परफ़ॉर्मेंस को कैसे बेहतर बना सकते हैं. साथ ही, यह भी बताया गया है कि वेब वर्कर और सर्विस वर्कर का इस्तेमाल कब करना चाहिए. विंडो और सर्विस वर्कर के बीच कम्यूनिकेशन के खास पैटर्न के बारे में जानने के लिए, इस सीरीज़ के बाकी वीडियो देखें.
वर्कर्स आपकी वेबसाइट को कैसे बेहतर बना सकते हैं
ब्राउज़र, वेब पेज में मौजूद सभी JavaScript को चलाने के लिए एक ही थ्रेड (मुख्य थ्रेड) का इस्तेमाल करता है. साथ ही, पेज को रेंडर करने और गार्बेज कलेक्शन जैसे टास्क पूरे करने के लिए भी इसी थ्रेड का इस्तेमाल करता है. ज़्यादा JavaScript कोड चलाने से मुख्य थ्रेड ब्लॉक हो सकती है. इससे ब्राउज़र को इन टास्क को पूरा करने में देरी होती है और उपयोगकर्ता को खराब अनुभव मिलता है.
iOS/Android ऐप्लिकेशन डेवलपमेंट में, यह पक्का करने के लिए कि ऐप्लिकेशन का मुख्य थ्रेड, उपयोगकर्ता के इवेंट का जवाब देने के लिए उपलब्ध रहे, अतिरिक्त थ्रेड पर ऑपरेशन ऑफ़लोड करने का एक सामान्य पैटर्न है. दरअसल, Android के नए वर्शन में, मुख्य थ्रेड को ज़्यादा समय तक ब्लॉक करने से ऐप्लिकेशन क्रैश हो जाता है.
वेब पर, JavaScript को सिंगल थ्रेड के कॉन्सेप्ट के आधार पर डिज़ाइन किया गया था. इसमें ऐप्लिकेशन की तरह मल्टीथ्रेडिंग मॉडल लागू करने के लिए ज़रूरी सुविधाएं नहीं हैं. जैसे, शेयर की गई मेमोरी.
इन सीमाओं के बावजूद, वेब पर इसी तरह का पैटर्न हासिल किया जा सकता है. इसके लिए, बैकग्राउंड थ्रेड में स्क्रिप्ट चलाने के लिए वर्कर का इस्तेमाल किया जाता है. इससे, मुख्य थ्रेड में रुकावट डाले बिना टास्क पूरे किए जा सकते हैं. वर्कर, एक पूरा JavaScript स्कोप होता है. यह किसी अलग थ्रेड पर चलता है और इसकी मेमोरी शेयर नहीं की जाती.
इस पोस्ट में, आपको दो अलग-अलग तरह के वर्कर (वेब वर्कर और सर्विस वर्कर) के बारे में जानकारी मिलेगी. साथ ही, आपको यह भी पता चलेगा कि ये दोनों एक-दूसरे से कितने मिलते-जुलते हैं और इनमें क्या अंतर है. इसके अलावा, आपको प्रोडक्शन वेबसाइटों में इनका इस्तेमाल करने के सबसे सामान्य पैटर्न के बारे में भी जानकारी मिलेगी.
वेब वर्कर और सर्विस वर्कर
समानताएं
वेब वर्कर और सर्विस वर्कर, वेबसाइटों के लिए उपलब्ध दो तरह के वर्कर होते हैं. इनमें कुछ चीज़ें एक जैसी हैं:
- ये दोनों, सेकंडरी थ्रेड में चलते हैं. इससे JavaScript कोड को मुख्य थ्रेड और यूज़र इंटरफ़ेस को ब्लॉक किए बिना एक्ज़ीक्यूट किया जा सकता है.
- उनके पास
WindowऔरDocumentऑब्जेक्ट का ऐक्सेस नहीं होता. इसलिए, वे सीधे तौर पर DOM से इंटरैक्ट नहीं कर सकते. साथ ही, उनके पास ब्राउज़र एपीआई का सीमित ऐक्सेस होता है.
अंतर
कुछ लोगों को लग सकता है कि वेब वर्कर को सौंपे जा सकने वाले ज़्यादातर काम, सर्विस वर्कर में किए जा सकते हैं और इसके उलट भी ऐसा किया जा सकता है. हालांकि, इन दोनों के बीच कुछ अहम अंतर हैं:
- वेब वर्कर के उलट, सर्विस वर्कर की मदद से नेटवर्क अनुरोधों (
fetchइवेंट के ज़रिए) को इंटरसेप्ट किया जा सकता है. साथ ही, बैकग्राउंड में Push API इवेंट (pushइवेंट के ज़रिए) को सुना जा सकता है. - कोई पेज कई वेब वर्कर जनरेट कर सकता है. हालांकि, एक सर्विस वर्कर, स्कोप में रजिस्टर किए गए सभी चालू टैब को कंट्रोल करता है.
- वेब वर्कर का लाइफ़स्पैन, उस टैब से जुड़ा होता है जिससे वह जुड़ा होता है. वहीं, सर्विस वर्कर का लाइफ़साइकल इससे अलग होता है. इस वजह से, जिस टैब में वेब वर्कर चल रहा है उसे बंद करने पर, वह बंद हो जाएगा. वहीं, सर्विस वर्कर बैकग्राउंड में काम करता रहता है. भले ही, साइट के कोई भी टैब खुले न हों.
उपयोग के उदाहरण
दोनों तरह के वर्कर के बीच के अंतर से पता चलता है कि किस स्थिति में, इनमें से किसी एक का इस्तेमाल किया जा सकता है:
वेब वर्कर के इस्तेमाल से जुड़े उदाहरण, आम तौर पर काम को सेकंडरी थ्रेड पर ऑफ़लोड करने से जुड़े होते हैं. जैसे, ज़्यादा कैलकुलेशन. ऐसा यूज़र इंटरफ़ेस (यूआई) को ब्लॉक होने से बचाने के लिए किया जाता है.
- उदाहरण: वीडियो गेम PROXX बनाने वाली टीम चाहती थी कि मुख्य थ्रेड को ज़्यादा से ज़्यादा खाली रखा जाए, ताकि उपयोगकर्ता के इनपुट और ऐनिमेशन का ध्यान रखा जा सके. इसके लिए, उन्होंने गेम के लॉजिक को चलाने और अलग थ्रेड पर स्थिति बनाए रखने के लिए, वेब वर्कर का इस्तेमाल किया.
सर्विस वर्कर के टास्क आम तौर पर, नेटवर्क प्रॉक्सी के तौर पर काम करने, बैकग्राउंड टास्क मैनेज करने, और कैश मेमोरी और ऑफ़लाइन जैसी चीज़ों से ज़्यादा जुड़े होते हैं.
उदाहरण: किसी पॉडकास्ट PWA में, कोई व्यक्ति उपयोगकर्ताओं को पूरे एपिसोड डाउनलोड करने की अनुमति दे सकता है, ताकि वे ऑफ़लाइन होने पर उन्हें सुन सकें. इसके लिए, सर्विस वर्कर और खास तौर पर Background Fetch API का इस्तेमाल किया जा सकता है. इस तरह, अगर उपयोगकर्ता एपिसोड डाउनलोड होने के दौरान टैब बंद कर देता है, तो टास्क में कोई रुकावट नहीं आएगी.
टूल और लाइब्रेरी
विंडो और वर्कर के बीच कम्यूनिकेशन को, अलग-अलग लोअर लेवल एपीआई का इस्तेमाल करके लागू किया जा सकता है. हालांकि, ऐसी लाइब्रेरी उपलब्ध हैं जो इस प्रोसेस को आसान बनाती हैं. साथ ही, सामान्य इस्तेमाल के उदाहरणों का ध्यान रखती हैं. इस सेक्शन में, हम इनमें से दो के बारे में बताएंगे. ये दोनों, विंडो से वेब वर्कर और सर्विस वर्कर के बीच कम्यूनिकेशन को मैनेज करते हैं. ये हैं: Comlink और Workbox.
Comlink
Comlink एक छोटी (1.6k) RPC लाइब्रेरी है. यह Web Workers का इस्तेमाल करने वाली वेबसाइटों को बनाते समय, कई बुनियादी बातों का ध्यान रखती है. इसका इस्तेमाल PROXX और Squoosh जैसी वेबसाइटों में किया गया है. इसके मकसद और कोड के सैंपल के बारे में खास जानकारी यहां देखी जा सकती है.
Workbox
Workbox, सर्विस वर्कर का इस्तेमाल करने वाली वेबसाइटों को बनाने के लिए एक लोकप्रिय लाइब्रेरी है. इसमें कैश मेमोरी, ऑफ़लाइन, बैकग्राउंड सिंक्रनाइज़ेशन वगैरह से जुड़े सबसे सही तरीकों का एक सेट होता है. workbox-window मॉड्यूल, सर्विस वर्कर और पेज के बीच मैसेज भेजने और पाने का आसान तरीका उपलब्ध कराता है.
अगले चरण
इस सीरीज़ के बाकी लेखों में, विंडो और सर्विस वर्कर के बीच कम्यूनिकेशन के पैटर्न के बारे में बताया गया है:
- कैशिंग से जुड़ी ज़रूरी गाइड: पेज से किसी सर्विस वर्कर को कॉल करके, संसाधनों को पहले से कैश मेमोरी में सेव करना. उदाहरण के लिए, प्रीफ़ेचिंग के उदाहरणों में.
- ब्रॉडकास्ट अपडेट: सर्विस वर्कर से पेज को कॉल करके, अहम अपडेट के बारे में सूचना देना. उदाहरण के लिए, वेबसाइट का नया वर्शन उपलब्ध है.
- दो-तरफ़ा कम्यूनिकेशन: किसी टास्क को सर्विस वर्कर को सौंपना (जैसे, कोई बड़ी फ़ाइल डाउनलोड करना) और पेज को टास्क की प्रोग्रेस के बारे में जानकारी देना.
विंडो और वेब वर्कर के बीच कम्यूनिकेशन के पैटर्न के बारे में जानने के लिए, यह लेख पढ़ें: ब्राउज़र के मुख्य थ्रेड से JavaScript को अलग करके चलाने के लिए वेब वर्कर का इस्तेमाल करना.