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