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