इस बारे में बताएं कि क्या शिप किया गया, असर को कैसे मेज़र किया गया, और कौनसे बदलाव किए गए.
बैकग्राउंड
Google पर किसी भी विषय को खोजने पर, आपको तुरंत काम के और काम के नतीजे दिखते हैं. शायद आपको पता न हो कि खोज के नतीजों का यह पेज, कुछ मामलों में सेवा वर्कर नाम की वेब टेक्नोलॉजी की मदद से दिखाया जाता है.
Google Search के लिए, परफ़ॉर्मेंस पर बुरा असर डाले बिना, सेवा वर्कर की सुविधा को रोल आउट करने के लिए, कई टीमों में काम करने वाले दर्जनों इंजीनियर की ज़रूरत पड़ी. इस लेख में बताया गया है कि क्या शिप किया गया, परफ़ॉर्मेंस को कैसे मेज़र किया गया, और क्या बदलाव किए गए.
सेवा वर्कर को एक्सप्लोर करने की मुख्य वजहें
अपनी साइट के आर्किटेक्चर में कोई बदलाव करने की तरह ही, किसी वेब ऐप्लिकेशन में सेवा वर्कर जोड़ने के लिए भी, आपको अपने लक्ष्यों को ध्यान में रखना चाहिए. Google Search टीम के लिए, सेवा वर्कर को जोड़ने की कुछ अहम वजहें थीं.
खोज के नतीजों को सीमित तौर पर कैश मेमोरी में सेव करना
Google Search की टीम को पता चला है कि उपयोगकर्ता अक्सर कम समय में एक ही शब्द को एक से ज़्यादा बार खोजते हैं. Search की टीम, एक ही तरह के नतीजे पाने के लिए, नए बैकएंड अनुरोध को ट्रिगर करने के बजाय, कैश मेमोरी का फ़ायदा लेना चाहती थी. साथ ही, बार-बार किए जाने वाले अनुरोधों को स्थानीय तौर पर पूरा करना चाहती थी.
नतीजों के अप-टू-डेट होने की अहमियत को नज़रअंदाज़ नहीं किया जा सकता. कभी-कभी उपयोगकर्ता एक ही शब्द को बार-बार खोजते हैं, क्योंकि यह एक ऐसा विषय है जो लगातार बदल रहा है और उन्हें नए नतीजे देखने की उम्मीद होती है. Search की टीम, सेवा वर्कर का इस्तेमाल करके बेहतर लॉजिक लागू कर सकती है. इससे, खोज के नतीजों को कैश मेमोरी में सेव करने की अवधि को कंट्रोल किया जा सकता है. साथ ही, खोज के नतीजों को तेज़ी से अपडेट करने और उन्हें अप-टू-डेट रखने के बीच सही संतुलन बनाया जा सकता है.
काम का ऑफ़लाइन अनुभव
इसके अलावा, Google Search की टीम को लोगों को ऑफ़लाइन भी बेहतर अनुभव देना था. जब किसी उपयोगकर्ता को किसी विषय के बारे में जानकारी चाहिए, तो वह सीधे Google Search पेज पर जाकर, इंटरनेट कनेक्शन के बारे में चिंता किए बिना खोज शुरू करना चाहता है.
सेवा वर्कर के बिना, ऑफ़लाइन होने पर Google के खोज पेज पर जाने पर, ब्राउज़र पर नेटवर्क से जुड़ी गड़बड़ी का स्टैंडर्ड पेज दिखेगा. साथ ही, उपयोगकर्ताओं को कनेक्शन वापस आने पर, इस पेज पर वापस आकर फिर से कोशिश करनी होगी. सेवा वर्कर की मदद से, उपयोगकर्ताओं को उनकी खोज क्वेरी तुरंत डालने की अनुमति देने के साथ-साथ, कस्टम ऑफ़लाइन एचटीएमएल रिस्पॉन्स भी दिखाया जा सकता है.
इंटरनेट कनेक्शन न होने पर नतीजे उपलब्ध नहीं होंगे. हालांकि, सेवा वर्कर की मदद से खोज को बाद में करने की सुविधा मिलती है. साथ ही, डिवाइस के फिर से ऑनलाइन होने पर, बैकग्राउंड सिंक एपीआई का इस्तेमाल करके, नतीजों को Google के सर्वर पर भेजा जाता है.
बेहतर तरीके से JavaScript को कैश मेमोरी में सेव करना और उसे दिखाना
एक और वजह यह थी कि मॉड्यूलर किए गए JavaScript कोड को कैश मेमोरी में सेव करने और लोड करने की प्रोसेस को ऑप्टिमाइज़ किया जा सके. यह कोड, खोज के नतीजों वाले पेज पर अलग-अलग तरह की सुविधाओं को काम करता है. JavaScript बंडलिंग से कई फ़ायदे मिलते हैं. ये फ़ायदे तब मिलते हैं, जब सेवा वर्कर का इस्तेमाल न किया जा रहा हो. इसलिए, Search की टीम ने बंडलिंग की सुविधा को पूरी तरह बंद नहीं किया.
Search टीम को उम्मीद है कि रनटाइम के दौरान, JavaScript के छोटे-छोटे हिस्सों को वर्शन में बदलने और कैश मेमोरी में सेव करने की सेवा वर्कर की सुविधा का इस्तेमाल करके, कैश मेमोरी में बदलाव की संख्या को कम किया जा सकता है. साथ ही, यह भी पक्का किया जा सकता है कि आने वाले समय में, फिर से इस्तेमाल किए जाने वाले JavaScript को कैश मेमोरी में बेहतर तरीके से सेव किया जा सके. उनके सेवा वर्कर में मौजूद लॉजिक, ऐसे बंडल के लिए भेजे गए एचटीटीपी अनुरोध का विश्लेषण कर सकता है जिसमें कई JavaScript मॉड्यूल होते हैं. साथ ही, स्थानीय रूप से कैश मेमोरी में सेव किए गए कई मॉड्यूल को एक साथ जोड़कर, अनुरोध को पूरा कर सकता है. जब भी संभव हो, तब "बंडल को अनबंडल" किया जा सकता है. इससे उपयोगकर्ता की बैंडविड्थ बचती है और रिस्पॉन्सिवनेस बेहतर होती है.
सेवा वर्कर की मदद से कैश मेमोरी में सेव की गई JavaScript का इस्तेमाल करने से, परफ़ॉर्मेंस को भी बेहतर बनाने में मदद मिलती है: Chrome में, उस JavaScript का पार्स किया गया, बाइट कोड का प्रतिनिधित्व सेव किया जाता है और उसका फिर से इस्तेमाल किया जाता है. इससे, पेज पर JavaScript को लागू करने के लिए, रनटाइम के दौरान कम काम करना पड़ता है.
चुनौतियां और समाधान
टीम के बताए गए लक्ष्यों को हासिल करने के लिए, यहां बताई गई कुछ समस्याओं को हल करना ज़रूरी था. इनमें से कुछ समस्याएं सिर्फ़ Google Search से जुड़ी हैं, जबकि कई समस्याएं ऐसी साइटों पर भी लागू होती हैं जो सेवा वर्कर को डिप्लॉय करने पर विचार कर रही हैं.
समस्या: सेवा वर्कर का ओवरहेड
Google Search पर सेवा वर्कर को लॉन्च करने के लिए सबसे बड़ी चुनौती यह थी कि यह ऐसा कुछ न करे जिससे उपयोगकर्ता को लगने वाला इंतज़ार का समय बढ़े. Google Search, परफ़ॉर्मेंस को बहुत गंभीरता से लेता है. इसलिए, अगर किसी नई सुविधा की वजह से, किसी उपयोगकर्ता ग्रुप के लिए 10 मिलीसेकंड भी ज़्यादा इंतज़ार करना पड़ता है, तो Google Search उसे लॉन्च करने से रोक देता है.
जब टीम ने अपने शुरुआती प्रयोगों के दौरान परफ़ॉर्मेंस डेटा इकट्ठा करना शुरू किया, तो यह साफ़ तौर पर पता चल गया कि कोई समस्या होगी. खोज के नतीजों के पेज के लिए, नेविगेशन अनुरोधों के जवाब में दिखाया गया एचटीएमएल डाइनैमिक होता है. यह Search के वेब सर्वर पर चलने वाले लॉजिक के हिसाब से काफ़ी अलग-अलग होता है. फ़िलहाल, सेवा वर्कर के पास इस लॉजिक को दोहराने और कैश मेमोरी में सेव किए गए एचटीएमएल को तुरंत दिखाने का कोई तरीका नहीं है. हालांकि, यह नेविगेशन के अनुरोधों को बैकएंड वेब सर्वर पर भेज सकता है. इसके लिए, नेटवर्क अनुरोध की ज़रूरत होती है.
सेवा वर्कर के बिना, उपयोगकर्ता के नेविगेट करने पर, यह नेटवर्क अनुरोध तुरंत होता है. जब कोई सेवा वर्कर रजिस्टर किया जाता है, तो उसे हमेशा शुरू करना होता है और उसे अपने fetch इवेंट हैंडलर को लागू करने का मौका देना होता है. भले ही, फ़ेच हैंडलर के नेटवर्क पर जाने के अलावा कुछ करने की संभावना न हो. सेवा वर्कअर को शुरू करने और चलाने में लगने वाला समय, हर नेविगेशन के ऊपर जोड़ा जाता है:
इससे, सेवा वर्कर को लागू करने में बहुत ज़्यादा समय लगता है. इसलिए, इसकी तुलना में अन्य फ़ायदे मायने नहीं रखते. इसके अलावा, टीम को पता चला कि असल डिवाइसों पर सेवा वर्कर के बूट होने में लगने वाले समय को मेज़र करने के आधार पर, स्टार्टअप के समय में काफ़ी अंतर था. कुछ लो-एंड मोबाइल डिवाइसों में, सेवा वर्कर को शुरू करने में उतना ही समय लगता है जितना नतीजों वाले पेज के एचटीएमएल के लिए नेटवर्क का अनुरोध करने में लगता है.
समाधान: नेविगेशन प्रीलोड का इस्तेमाल करना
नेविगेशन प्रीलोड, एक ऐसी अहम सुविधा है जिसकी मदद से Google Search की टीम ने सेवा वर्कर लॉन्च करने का फ़ैसला लिया. नेविगेशन प्रीलोड का इस्तेमाल करना, किसी भी ऐसे सेवा वर्कर के लिए परफ़ॉर्मेंस में अहम फ़ायदा है जिसे नेविगेशन अनुरोधों को पूरा करने के लिए, नेटवर्क से मिले जवाब का इस्तेमाल करना पड़ता है. यह ब्राउज़र को यह संकेत देता है कि सेवा वर्कर्स के शुरू होने के साथ ही, नेविगेशन का अनुरोध तुरंत शुरू किया जाए:
जब तक सेवा वर्कर को शुरू होने में लगने वाला समय, नेटवर्क से जवाब पाने में लगने वाले समय से कम होता है, तब तक सेवा वर्कर की वजह से कोई इंतज़ार नहीं होना चाहिए.
Search टीम को कम क्षमता वाले मोबाइल डिवाइसों पर भी सेवा वर्कर का इस्तेमाल करने से बचना था. ऐसा इसलिए, क्योंकि सेवा वर्कर के बूट होने में लगने वाला समय, नेविगेशन अनुरोध से ज़्यादा हो सकता है. "लो-एंड" डिवाइस को तय करने के लिए कोई सटीक नियम नहीं है. इसलिए, उन्होंने डिवाइस में इंस्टॉल की गई कुल रैम की जांच करने का तरीका अपनाया. दो गीगाबाइट से कम मेमोरी वाले डिवाइसों को, उनके कम-एंड डिवाइसों की कैटगरी में रखा गया था. इन डिवाइसों पर, सेवा वर्कर के शुरू होने में लगने वाला समय स्वीकार नहीं किया जा सकता.
उपलब्ध स्टोरेज स्पेस भी एक अहम बात है, क्योंकि आने वाले समय में इस्तेमाल के लिए कैश मेमोरी में सेव किए जाने वाले संसाधनों का पूरा सेट कई मेगाबाइट तक का हो सकता है. navigator.storage इंटरफ़ेस की मदद से, Google Search पेज को पहले से पता चल जाता है कि डेटा को कैश मेमोरी में सेव करने की कोशिश करने पर, स्टोरेज कोटा की वजह से डेटा सेव न होने का खतरा है या नहीं.
इससे Search की टीम के पास कई शर्तें थीं जिनका इस्तेमाल करके यह तय किया जा सकता था कि सेवा वर्कर का इस्तेमाल करना है या नहीं: अगर कोई उपयोगकर्ता नेविगेशन प्रीलोड की सुविधा वाले ब्राउज़र का इस्तेमाल करके Google Search पेज पर आता है और उसके पास कम से कम 2 गीगाबाइट रैम और ज़रूरत के मुताबिक स्टोरेज है, तो सेवा वर्कर रजिस्टर हो जाता है. जिन ब्राउज़र या डिवाइसों पर ये ज़रूरी शर्तें पूरी नहीं होतीं उन्हें सेवा सहायता देने वाला कोई व्यक्ति नहीं मिलेगा. हालांकि, उन्हें Google Search का वही अनुभव मिलेगा जो उन्हें हमेशा मिलता है.
चुनिंदा ऐप्लिकेशन के लिए रजिस्ट्रेशन करने का एक फ़ायदा यह है कि इससे छोटे और ज़्यादा असरदार सेवा वर्कर को शिप किया जा सकता है. सेवा वर्कर कोड को चलाने के लिए, अप-टू-डेट ब्राउज़र को टारगेट करने से, पुराने ब्राउज़र के लिए ट्रांसपाइलेशन और polyfills का ओवरहेड खत्म हो जाता है. इससे, सेवा वर्कर को लागू करने के कुल साइज़ से, बिना कंप्रेस किए गए JavaScript कोड के करीब 8 किलोबाइट काट दिए गए.
समस्या: सर्विस वर्कर के दायरे
जब Search की टीम ने इंतज़ार के समय से जुड़े ज़रूरत के मुताबिक प्रयोग कर लिए और उन्हें भरोसा हो गया कि नेविगेशन प्रीलोड का इस्तेमाल करके, सेवा वर्कर का इस्तेमाल करने के लिए, इंतज़ार के समय से जुड़ी समस्याओं को हल किया जा सकता है, तब कुछ व्यावहारिक समस्याएं सामने आने लगीं. इनमें से एक समस्या, सेवा वर्कर के स्कोपिंग नियमों से जुड़ी है. सर्विस वर्कर के दायरे से यह तय होता है कि वह किन पेजों को कंट्रोल कर सकता है.
स्कोपिंग, यूआरएल पाथ प्रीफ़िक्स के आधार पर काम करती है. एक वेब ऐप्लिकेशन को होस्ट करने वाले डोमेन के लिए, यह कोई समस्या नहीं है. आम तौर पर, / के ज़्यादा से ज़्यादा दायरे वाले सर्विस वर्कर का इस्तेमाल किया जाता है. यह डोमेन के किसी भी पेज को कंट्रोल कर सकता है.
हालांकि, Google Search का यूआरएल स्ट्रक्चर थोड़ा ज़्यादा जटिल है.
अगर सर्विस वर्कर को / का ज़्यादा से ज़्यादा दायरा दिया जाता है, तो वह www.google.com (या क्षेत्र के हिसाब से मिलते-जुलते डोमेन) के तहत होस्ट किए गए किसी भी पेज को कंट्रोल कर पाएगा. साथ ही, उस डोमेन में ऐसे यूआरएल भी हैं जिनका Google Search से कोई लेना-देना नहीं है. /search एक ज़्यादा सही और पाबंदी वाला दायरा होगा. इससे, खोज के नतीजों से पूरी तरह से अलग यूआरएल हट जाएंगे.
माफ़ करें, वह /search यूआरएल पाथ भी Google Search के अलग-अलग नतीजों के साथ शेयर किया जाता है. यूआरएल क्वेरी पैरामीटर से यह तय होता है कि खोज के नतीजों में किस तरह का नतीजा दिखाया जाए. इनमें से कुछ फ़्लेवर, वेब पर खोज के नतीजों वाले पारंपरिक पेज के मुकाबले, पूरी तरह से अलग कोडबेस का इस्तेमाल करते हैं. उदाहरण के लिए, इमेज सर्च और शॉपिंग सर्च, दोनों को अलग-अलग क्वेरी पैरामीटर वाले /search यूआरएल पाथ के तहत दिखाया जाता है. हालांकि, अब तक इनमें से कोई भी इंटरफ़ेस, सेवा वर्कर के अनुभव को शिप करने के लिए तैयार नहीं था.
समाधान: डिस्पैच और रूटिंग फ़्रेमवर्क बनाएं
ऐसे कुछ प्रस्ताव हैं जिनकी मदद से, यूआरएल पाथ के प्रीफ़िक्स के मुकाबले ज़्यादा बेहतर तरीके से, सर्विस वर्कर के स्कोप तय किए जा सकते हैं. हालांकि, Google Search की टीम को एक ऐसे सर्विस वर्कर को डिप्लॉय करने में समस्या आ रही थी जो अपने कंट्रोल में रखे गए पेजों के सबसेट के लिए कुछ भी नहीं करता था.
इस समस्या को हल करने के लिए, Google Search की टीम ने एक खास डिस्पैच और रूटिंग फ़्रेमवर्क बनाया है. इसे क्लाइंट पेज के क्वेरी पैरामीटर जैसी शर्तों की जांच करने के लिए कॉन्फ़िगर किया जा सकता है. साथ ही, इसका इस्तेमाल करके यह तय किया जा सकता है कि कौनसा खास कोड पाथ इस्तेमाल किया जाए. नियमों को हार्डकोड करने के बजाय, सिस्टम को ज़्यादा बेहतर बनाने के लिए बनाया गया था. इससे, इमेज सर्च और शॉपिंग सर्च जैसी टीमों को यूआरएल स्पेस शेयर करने की अनुमति मिलती है. साथ ही, अगर वे इसे लागू करना चाहें, तो वे अपने हिसाब से सेवा वर्कर लॉजिक को बाद में जोड़ सकती हैं.
समस्या: आपके हिसाब से नतीजे और मेट्रिक
उपयोगकर्ता अपने Google खातों का इस्तेमाल करके, Google Search में साइन इन कर सकते हैं. साथ ही, उनके खाते के डेटा के आधार पर, खोज के नतीजों का अनुभव पसंद के मुताबिक बनाया जा सकता है. लॉग इन किए हुए उपयोगकर्ताओं की पहचान, खास ब्राउज़र कुकी से की जाती है. यह एक मान्य और व्यापक तौर पर इस्तेमाल किया जाने वाला स्टैंडर्ड है.
हालांकि, ब्राउज़र कुकी का इस्तेमाल करने का एक नुकसान यह है कि ये सर्विस वर्कर के अंदर नहीं दिखती हैं. साथ ही, इनकी वैल्यू की अपने-आप जांच करने का कोई तरीका नहीं है. साथ ही, यह पक्का करने का भी कोई तरीका नहीं है कि उपयोगकर्ता के लॉग आउट करने या खाते बदलने की वजह से, इनमें कोई बदलाव नहीं हुआ है. (सेवा वर्कर को कुकी का ऐक्सेस देने के लिए काम किया जा रहा है. हालांकि, फ़िलहाल यह तरीका एक्सपेरिमेंट के तौर पर उपलब्ध है और बड़े पैमाने पर काम नहीं करता.)
अगर लॉग इन किए हुए मौजूदा उपयोगकर्ता और Google Search के वेब इंटरफ़ेस में लॉग इन किए हुए असल उपयोगकर्ता के बीच, सेवा वर्कर के व्यू में अंतर होता है, तो हो सकता है कि खोज के नतीजे आपके हिसाब से न हों या मेट्रिक और लॉगिंग को गलत तरीके से एट्रिब्यूट किया गया हो. इनमें से किसी भी स्थिति में, Google Search की टीम के लिए यह गंभीर समस्या होगी.
समाधान: postMessage का इस्तेमाल करके कुकी भेजना
Google Search की टीम ने एक्सपेरिमेंटल एपीआई के लॉन्च होने और सेवा वर्कर के अंदर ब्राउज़र की कुकी को सीधे ऐक्सेस करने का इंतज़ार करने के बजाय, एक ऐसा तरीका अपनाया है जिससे इस समस्या को कुछ समय के लिए हल किया जा सकता है: जब भी सेवा वर्कर से कंट्रोल किया जाने वाला कोई पेज लोड होता है, तो वह काम की कुकी पढ़ता है और उन्हें सेवा वर्कर को भेजने के लिए postMessage() का इस्तेमाल करता है.
इसके बाद, सेवा वर्कर मौजूदा कुकी वैल्यू की तुलना, अपनी उम्मीद की गई वैल्यू से करता है. अगर कोई अंतर मिलता है, तो वह अपने स्टोरेज से उपयोगकर्ता से जुड़े किसी भी डेटा को मिटाने के लिए कदम उठाता है. साथ ही, खोज के नतीजों वाले पेज को फिर से लोड करता है, ताकि उपयोगकर्ता के हिसाब से पेज को फिर से सही तरीके से बनाया जा सके.
सेवा वर्कर, चीज़ों को बेसलाइन पर रीसेट करने के लिए जो खास तरीके अपनाता है वे Google Search की ज़रूरतों के हिसाब से होते हैं. हालांकि, ब्राउज़र कुकी से मिले उपयोगकर्ता के हिसाब से बनाए गए डेटा को मैनेज करने वाले अन्य डेवलपर के लिए, यह सामान्य तरीका काम का हो सकता है.
समस्या: एक्सपेरिमेंट और डाइनैमिक
जैसा कि बताया गया है, Google Search की टीम, प्रोडक्शन में प्रयोग चलाने पर काफ़ी निर्भर करती है. साथ ही, डिफ़ॉल्ट रूप से चालू करने से पहले, नए कोड और सुविधाओं के असर की जांच असल दुनिया में करती है. कैश मेमोरी में सेव किए गए डेटा पर ज़्यादा निर्भर रहने वाले स्टैटिक सेवा वर्कर के लिए, यह थोड़ा मुश्किल हो सकता है. ऐसा इसलिए, क्योंकि उपयोगकर्ताओं को प्रयोगों में शामिल करने और उनसे बाहर निकालने के लिए, अक्सर बैकएंड सर्वर से संपर्क करना पड़ता है.
समाधान: डाइनैमिक तौर पर जनरेट की गई सेवा वर्कर स्क्रिप्ट
टीम ने इस समस्या को हल करने के लिए, डाइनैमिक तौर पर जनरेट होने वाली सेवा वर्कर स्क्रिप्ट का इस्तेमाल किया. यह स्क्रिप्ट, वेब सर्वर के हिसाब से हर उपयोगकर्ता के लिए अलग-अलग बनाई जाती है. ऐसा करने के बजाय, टीम ने पहले से जनरेट की गई एक स्टैटिक सेवा वर्कर स्क्रिप्ट का इस्तेमाल किया. जिन प्रयोगों से सेवा वर्कर के व्यवहार या सामान्य तौर पर नेटवर्क अनुरोधों पर असर पड़ सकता है उनकी जानकारी, सीधे तौर पर पसंद के मुताबिक बनाई गई सेवा वर्कर स्क्रिप्ट में शामिल की जाती है. किसी उपयोगकर्ता के लिए, ऐक्टिव अनुभवों के सेट को बदलने के लिए, ब्राउज़र कुकी जैसी पारंपरिक तकनीकों के साथ-साथ, रजिस्टर किए गए सेवा वर्कर यूआरएल में अपडेट किया गया कोड दिखाया जाता है.
डाइनैमिक तौर पर जनरेट की गई सेवा वर्कर स्क्रिप्ट का इस्तेमाल करने से, किसी भी तरह की गड़बड़ी होने पर, उसे ठीक करना आसान हो जाता है. डाइनैमिक सर्वर वर्कर्स का रिस्पॉन्स कोई कार्रवाई नहीं की गई हो सकता है. इससे, कुछ या सभी मौजूदा उपयोगकर्ताओं के लिए, सर्वर वर्कर्स को असरदार तरीके से बंद कर दिया जाता है.
समस्या: अपडेट को मैनेज करना
असल दुनिया में सेवा वर्कर को डिप्लॉय करने के दौरान, सबसे बड़ी चुनौती यह होती है कि कैश मेमोरी का इस्तेमाल करने के लिए, नेटवर्क का इस्तेमाल कम से कम किया जाए. साथ ही, यह भी पक्का किया जाए कि प्रोडक्शन में डिप्लॉय होने के बाद, मौजूदा उपयोगकर्ताओं को ज़रूरी अपडेट और बदलाव जल्द से जल्द मिल जाएं. सही बैलेंस कई बातों पर निर्भर करता है:
- आपका वेब ऐप्लिकेशन, लंबे समय तक चलने वाला सिंगल पेज ऐप्लिकेशन है या नहीं, जिसे उपयोगकर्ता नए पेजों पर जाने के बिना, हमेशा के लिए खुला रखता है.
- आपके बैकएंड वेब सर्वर के अपडेट के लिए, डिप्लॉयमेंट का क्रम क्या है.
- क्या औसत उपयोगकर्ता आपके वेब ऐप्लिकेशन के थोड़े पुराने वर्शन का इस्तेमाल करेगा या अपडेट करना सबसे ज़्यादा ज़रूरी है.
Google Search की टीम ने सेवा वर्कर के साथ प्रयोग करते समय, शेड्यूल किए गए कई बैकएंड अपडेट के दौरान, प्रयोगों को चालू रखने का ध्यान रखा. इससे यह पक्का किया जा सका कि मेट्रिक और उपयोगकर्ता अनुभव, असल दुनिया में वापस आने वाले उपयोगकर्ताओं को दिखने वाले अनुभव से ज़्यादा मिलता-जुलता हो.
समाधान: डेटा को अप-टू-डेट रखने और कैश मेमोरी का इस्तेमाल करने के बीच संतुलन बनाए रखना
कॉन्फ़िगरेशन के कई अलग-अलग विकल्पों को आज़माने के बाद, Google Search की टीम को पता चला कि यहां दिया गया सेटअप, कॉन्टेंट के अपडेट होने की फ़्रीक्वेंसी और कैश मेमोरी के इस्तेमाल के बीच सही संतुलन देता है.
सेवा वर्कर स्क्रिप्ट का यूआरएल, Cache-Control: private, max-age=1500 (1500 सेकंड या 25 मिनट) रिस्पॉन्स हेडर के साथ दिखाया जाता है. साथ ही, हेडर का इस्तेमाल किया जा सके, यह पक्का करने के लिए, इसे updateViaCache के साथ 'सभी' पर सेट करके रजिस्टर किया जाता है. Google Search का वेब बैकएंड, दुनिया भर में मौजूद सर्वर का एक बड़ा सेट है. इसमें ज़्यादा से ज़्यादा अपटाइम की ज़रूरत होती है. सेवा वर्कर स्क्रिप्ट के कॉन्टेंट पर असर डालने वाले बदलाव को रोलिंग फ़ैशन में डिप्लॉय किया जाता है.
अगर कोई उपयोगकर्ता अपडेट किए गए बैकएंड पर जाता है और फिर तुरंत किसी ऐसे पेज पर जाता है जो ऐसे बैकएंड पर जाता है जिसे अब तक अपडेट किया गया सेवा वर्कर नहीं मिला है, तो वह कई बार वर्शन के बीच स्विच करेगा. इसलिए, ब्राउज़र को यह बताना कि अपडेट की गई स्क्रिप्ट की जांच सिर्फ़ तब करनी है, जब पिछली जांच के 25 मिनट बाद ही कोई अपडेट किया गया हो, इससे कोई खास नुकसान नहीं होता. इस व्यवहार के लिए ऑप्ट-इन करने का फ़ायदा यह है कि इससे उस एंडपॉइंट पर मिलने वाले ट्रैफ़िक में काफ़ी कमी आती है जो सेवा वर्कर स्क्रिप्ट को डाइनैमिक तौर पर जनरेट करता है.
इसके अलावा, सेवा वर्कर स्क्रिप्ट के एचटीटीपी रिस्पॉन्स पर एक ETag हेडर सेट किया जाता है. इससे यह पक्का होता है कि 25 मिनट बाद अपडेट की जांच करने पर, अगर इस दौरान सेवा वर्कर में कोई अपडेट नहीं हुआ है, तो सर्वर एचटीटीपी 304 रिस्पॉन्स के साथ बेहतर तरीके से जवाब दे सकता है.
Google Search के वेब ऐप्लिकेशन में कुछ इंटरैक्शन, एक पेज वाले ऐप्लिकेशन स्टाइल वाले नेविगेशन (जैसे, इतिहास एपीआई के ज़रिए) का इस्तेमाल करते हैं. हालांकि, ज़्यादातर मामलों में Google Search एक पारंपरिक वेब ऐप्लिकेशन है, जो "असल" नेविगेशन का इस्तेमाल करता है. यह तब लागू होता है, जब टीम यह तय करती है कि सेवा वर्कर के अपडेट के लाइफ़साइकल को तेज़ करने के लिए, इन दो विकल्पों का इस्तेमाल करना कारगर होगा:
clients.claim() और
skipWaiting().
Google Search के इंटरफ़ेस पर क्लिक करने पर, आम तौर पर नए एचटीएमएल दस्तावेज़ों पर रीडायरेक्ट कर दिया जाता है. skipWaiting को कॉल करने से यह पक्का होता है कि अपडेट किए गए सेवा वर्कर को, इंस्टॉल होने के तुरंत बाद उन नए नेविगेशन अनुरोधों को मैनेज करने का मौका मिलता है. इसी तरह, clients.claim() को कॉल करने का मतलब है कि अपडेट किए गए सेवा वर्कर को, सेवा वर्कर चालू होने के बाद, ऐसे सभी Google Search पेजों को कंट्रोल करने का मौका मिलता है जो कंट्रोल नहीं किए जा रहे हैं.
ज़रूरी नहीं है कि Google Search का यह तरीका सभी के लिए काम करे. यह तरीका, विज्ञापन दिखाने के अलग-अलग विकल्पों के कई कॉम्बिनेशन को ध्यान से A/B टेस्ट करने के बाद तय किया गया है. ऐसा तब तक किया गया, जब तक कि उन्हें यह पता नहीं चल गया कि उनके लिए कौनसा विकल्प सबसे अच्छा है.
जिन डेवलपर के बैकएंड इन्फ़्रास्ट्रक्चर की मदद से, अपडेट तेज़ी से डिप्लॉय किए जा सकते हैं वे ब्राउज़र को अपडेट की गई सेवा वर्कर स्क्रिप्ट की जांच, जितनी बार हो सके उतनी बार करने के लिए कह सकते हैं. इसके लिए, वे एचटीटीपी कैश मेमोरी को हमेशा अनदेखा कर सकते हैं.
अगर आपको एक ऐसा सिंगल पेज ऐप्लिकेशन बनाना है जिसे उपयोगकर्ता लंबे समय तक खुला रखें, तो हो सकता है कि skipWaiting() का इस्तेमाल करना आपके लिए सही न हो. अगर लंबे समय तक चलने वाले क्लाइंट मौजूद होने पर, नए सेवा वर्कर को चालू करने की अनुमति दी जाती है, तो कैश मेमोरी में गड़बड़ियां हो सकती हैं.
सीखने लायक ज़रूरी बातें
डिफ़ॉल्ट रूप से, सर्विस वर्कर की परफ़ॉर्मेंस पर कोई असर नहीं पड़ता
अपने वेब ऐप्लिकेशन में सर्विस वर्कर जोड़ने का मतलब है कि JavaScript का एक और हिस्सा जोड़ना. इस हिस्से को लोड और चलाने के बाद ही, आपके वेब ऐप्लिकेशन को उसके अनुरोधों के जवाब मिलते हैं. अगर ये रिस्पॉन्स, नेटवर्क के बजाय लोकल कैश मेमोरी से मिलते हैं, तो कैश मेमोरी का इस्तेमाल करने से मिलने वाली परफ़ॉर्मेंस की तुलना में, आम तौर पर सेवा वर्कर को चलाने का ओवरहेड मामूली होता है. हालांकि, अगर आपको पता है कि नेविगेशन के अनुरोधों को मैनेज करते समय, आपके सेवा वर्कर को हमेशा नेटवर्क से संपर्क करना पड़ता है, तो नेविगेशन प्रीलोड का इस्तेमाल करना परफ़ॉर्मेंस के लिहाज़ से बहुत ज़रूरी है.
सर्विस वर्कर, अब भी प्रोग्रेसिव एन्हैंसमेंट हैं
एक साल पहले की तुलना में, आज सेवा वर्कर के लिए सहायता की सुविधा काफ़ी बेहतर है. सभी आधुनिक ब्राउज़र में अब कम से कम कुछ सेवा वर्कर के लिए सहायता उपलब्ध है. हालांकि, माफ़ करें, बैकग्राउंड सिंक और नेविगेशन प्रीलोड जैसी सेवा वर्कर की कुछ बेहतर सुविधाएं, सभी ब्राउज़र में उपलब्ध नहीं हैं. सुविधाओं के उस खास सबसेट की जांच करना जो आपको ज़रूरी हैं और सिर्फ़ तब सेवा वर्कर को रजिस्टर करना जब वे मौजूद हों, अब भी एक सही तरीका है.
इसी तरह, अगर आपने एक्सपेरिमेंट चलाए हैं और आपको पता है कि सेवा वर्कर के अतिरिक्त ओवरहेड की वजह से, कम-एंड डिवाइसों की परफ़ॉर्मेंस खराब हो जाती है, तो उन स्थितियों में भी सेवा वर्कर को रजिस्टर करने से बचा जा सकता है.
आपको सेवा वर्कर को प्रगतिशील बेहतर बनाने के तौर पर इस्तेमाल करना चाहिए. यह वेब ऐप्लिकेशन में तब जोड़ा जाता है, जब सभी ज़रूरी शर्तें पूरी हो जाती हैं और सेवा वर्कर, उपयोगकर्ता अनुभव और लोड होने की परफ़ॉर्मेंस को बेहतर बनाता है.
सब कुछ मेज़र करना
प्रयोग करके और नतीजों को मेज़र करके ही यह पता लगाया जा सकता है कि सेवा वर्कर को शिप करने से, उपयोगकर्ताओं के अनुभव पर अच्छा असर पड़ा है या बुरा.
काम के मेज़रमेंट सेट अप करने की खास बातें, इस बात पर निर्भर करती हैं कि आपने आंकड़ों की सेवा देने वाली किस कंपनी का इस्तेमाल किया है. साथ ही, यह भी इस बात पर निर्भर करता है कि आपने डिप्लॉयमेंट सेटअप में आम तौर पर प्रयोग कैसे किए हैं. मेट्रिक इकट्ठा करने के लिए Google Analytics का इस्तेमाल करने के एक तरीके के बारे में, इस केस स्टडी में बताया गया है. यह तरीका, Google I/O वेब ऐप्लिकेशन में सेवा वर्कर का इस्तेमाल करने के अनुभव पर आधारित है.
नॉन-लक्ष्य
वेब डेवलपमेंट कम्यूनिटी में कई लोग, सर्विस वर्कर को प्रगतिशील वेब ऐप्लिकेशन से जोड़ते हैं. हालांकि, "Google Search का PWA" बनाना, टीम का शुरुआती लक्ष्य नहीं था. फ़िलहाल, Google Search का वेब ऐप्लिकेशन, वेब ऐप्लिकेशन मेनिफ़ेस्ट के ज़रिए मेटाडेटा उपलब्ध नहीं कराता. साथ ही, यह उपयोगकर्ताओं को होम स्क्रीन पर जोड़ने के फ़्लो का इस्तेमाल करने के लिए भी नहीं बढ़ावा देता. फ़िलहाल, Search की टीम को इस बात से संतुष्टि है कि उपयोगकर्ता Google Search के पारंपरिक एंट्री पॉइंट के ज़रिए, उनके वेब ऐप्लिकेशन पर आ रहे हैं.
Google Search के वेब वर्शन को इंस्टॉल किए गए ऐप्लिकेशन के बराबर बनाने के बजाय, शुरुआती रोल आउट में मौजूदा वेबसाइट को बेहतर बनाने पर फ़ोकस किया गया था.
आभार
Google Search की वेब डेवलपमेंट टीम को धन्यवाद, जिसने सेवा वर्कर को लागू करने के लिए काम किया. साथ ही, इस लेख को लिखने के लिए बैकग्राउंड में काम करने वाला कॉन्टेंट शेयर किया. खास तौर पर, फ़िलिप गोले, राजेश जगन्नाथ, और आर. सैमुअल क्लैचको, ऐंडी मार्टोने, लियोनार्डो पेना, रेचल शियरर, ग्रेग टेरनो, और क्ले वूलम.
अपडेट (अक्टूबर 2021): इस लेख को मूल रूप से पब्लिश किए जाने के बाद, Google Search की टीम ने अपने मौजूदा सेवा वर्कर आर्किटेक्चर के फ़ायदों और नुकसानों का फिर से आकलन किया है. ऊपर बताए गए सर्विस वर्कर को बंद किया जा रहा है. Google Search के वेब इन्फ़्रास्ट्रक्चर के बेहतर होते जाने के साथ, टीम अपने सर्विस वर्कर के डिज़ाइन पर फिर से विचार कर सकती है.