क्या शिप किया गया, असर का आकलन कैसे किया गया, और कौनसे फ़ैसले लिए गए.
पब्लिश होने की तारीख: 20 जून, 2019
Google पर किसी भी विषय के बारे में खोज करें. आपको तुरंत एक ऐसा पेज दिखेगा जिस पर काम के और खोज से मिलते-जुलते नतीजे होंगे. आपको शायद यह पता नहीं होगा कि कुछ मामलों में, खोज नतीजों वाले इस पेज को एक बेहतरीन वेब टेक्नोलॉजी की मदद से दिखाया जाता है. इसे सर्विस वर्कर कहा जाता है.
Google Search के लिए सर्विस वर्कर की सुविधा को रोल आउट करने के लिए, कई टीमों के दर्जनों इंजीनियरों ने मिलकर काम किया. इससे परफ़ॉर्मेंस पर कोई बुरा असर नहीं पड़ा. इस लेख में बताया गया है कि क्या शिप किया गया, परफ़ॉर्मेंस को कैसे मेज़र किया गया, और किन चीज़ों को प्राथमिकता दी गई.
सर्विस वर्कर एक्सप्लोर करने की मुख्य वजहें
किसी वेब ऐप्लिकेशन में सर्विस वर्कर जोड़ने के लिए, आपको कुछ लक्ष्यों को ध्यान में रखना होगा. ठीक वैसे ही जैसे अपनी साइट में कोई आर्किटेक्चरल बदलाव करते समय किया जाता है. Google Search टीम के लिए, सर्विस वर्कर को जोड़ने की कुछ मुख्य वजहें थीं.
खोज के नतीजों को सीमित समय के लिए कैश मेमोरी में सेव करना
Google Search की टीम को पता चला है कि उपयोगकर्ता अक्सर कम समय में एक ही शब्द को कई बार खोजते हैं. खोज टीम ने यह तय किया कि एक ही तरह के नतीजों के लिए, बार-बार बैकएंड से अनुरोध करने के बजाय, कैश मेमोरी का इस्तेमाल किया जाए. इससे, बार-बार किए जाने वाले अनुरोधों को स्थानीय तौर पर पूरा किया जा सकेगा.
ताज़ा जानकारी होना बहुत ज़रूरी है. कभी-कभी लोग एक ही विषय के बारे में बार-बार खोज करते हैं, क्योंकि यह एक ऐसा विषय होता है जिसमें लगातार बदलाव होते रहते हैं. इसलिए, वे चाहते हैं कि उन्हें नए नतीजे दिखें. सर्विस वर्कर का इस्तेमाल करके, Search टीम स्थानीय तौर पर कैश मेमोरी में सेव किए गए खोज नतीजों के लाइफ़टाइम को कंट्रोल करने के लिए, ज़्यादा बारीकी से लॉजिक लागू कर सकती है. साथ ही, स्पीड और नए नतीजों के बीच सही संतुलन बना सकती है. टीम का मानना है कि इससे उपयोगकर्ताओं को बेहतर नतीजे मिलेंगे.
ऑफ़लाइन होने पर भी काम की सुविधाएं
इसके अलावा, Google Search की टीम ऑफ़लाइन होने पर भी लोगों को काम का अनुभव देना चाहती थी. जब किसी व्यक्ति को किसी विषय के बारे में जानकारी चाहिए, तो वह सीधे Google Search पेज पर जाकर खोज शुरू करना चाहता है. इसके लिए, उसे इंटरनेट कनेक्शन के चालू होने की चिंता नहीं करनी चाहिए.
सर्विस वर्कर के बिना, ऑफ़लाइन होने पर Google Search पेज पर जाने से, ब्राउज़र का स्टैंडर्ड नेटवर्क गड़बड़ी वाला पेज दिखेगा. साथ ही, उपयोगकर्ताओं को कनेक्शन वापस आने पर, पेज पर वापस आकर फिर से कोशिश करनी होगी. सर्विस वर्कर की मदद से, ऑफ़लाइन होने पर एचटीएमएल का कस्टम जवाब दिया जा सकता है. साथ ही, उपयोगकर्ताओं को तुरंत अपनी खोज क्वेरी डालने की अनुमति दी जा सकती है.
इंटरनेट कनेक्शन होने पर ही नतीजे दिखेंगे. हालांकि, सर्विस वर्कर की मदद से खोज को कुछ समय के लिए रोका जा सकता है. साथ ही, डिवाइस के फिर से ऑनलाइन होने पर, बैकग्राउंड सिंक एपीआई का इस्तेमाल करके, खोज को Google के सर्वर पर भेजा जा सकता है.
JavaScript को ज़्यादा स्मार्ट तरीके से कैश मेमोरी में सेव करना और उसे दिखाना
इसके अलावा, हमारा मकसद मॉड्यूलर JavaScript कोड की कैश मेमोरी को ऑप्टिमाइज़ करना और उसे लोड करना भी था. यह कोड, खोज नतीजों वाले पेज पर अलग-अलग तरह की सुविधाओं को चालू करता है. JavaScript बंडलिंग के कई फ़ायदे हैं. ये फ़ायदे तब काम आते हैं, जब सर्विस वर्कर शामिल नहीं होता. इसलिए, Search टीम ने बंडलिंग की सुविधा को पूरी तरह से बंद नहीं किया.
Search टीम को लगा कि सर्विस वर्कर की मदद से, रनटाइम के दौरान JavaScript के छोटे-छोटे हिस्सों को वर्शन और कैश किया जा सकता है. इससे, कैश मेमोरी में बदलाव की संख्या को कम किया जा सकता है. साथ ही, यह पक्का किया जा सकता है कि आने वाले समय में इस्तेमाल की जाने वाली JavaScript को बेहतर तरीके से कैश किया जा सके. उनका सर्विस वर्कर, एक ऐसे बंडल के लिए भेजे गए एचटीटीपी अनुरोध का विश्लेषण कर सकता है जिसमें कई JavaScript मॉड्यूल शामिल हैं. साथ ही, स्थानीय तौर पर कैश मेमोरी में सेव किए गए कई मॉड्यूल को एक साथ जोड़कर, उस अनुरोध को पूरा कर सकता है. इससे, जब भी संभव हो, बंडल को "अनबंडल" किया जा सकता है. इससे उपयोगकर्ता का बैंडविड्थ बचता है और पेज के रिस्पॉन्स देने की स्पीड बेहतर होती है.
सर्विस वर्कर की ओर से उपलब्ध कराई गई, कैश मेमोरी में सेव की गई JavaScript का इस्तेमाल करने से परफ़ॉर्मेंस भी बेहतर होती है: Chrome में, उस JavaScript का पार्स किया गया, बाइट कोड वाला वर्शन सेव किया जाता है और उसे फिर से इस्तेमाल किया जाता है. इससे पेज पर JavaScript को एक्ज़ीक्यूट करने के लिए, रनटाइम में कम काम करना पड़ता है.
चुनौतियां और समाधान
टीम के तय किए गए लक्ष्यों को हासिल करने के लिए, यहां कुछ समस्याओं को हल करना ज़रूरी था. इनमें से कुछ समस्याएं सिर्फ़ Google Search से जुड़ी हैं. हालांकि, इनमें से कई समस्याएं उन साइटों पर भी लागू होती हैं जो सर्विस वर्कर को डिप्लॉय करने के बारे में सोच रही हैं.
समस्या: सर्विस वर्कर का ओवरहेड
Google Search पर सर्विस वर्कर लॉन्च करने में सबसे बड़ी चुनौती यह थी कि यह पक्का किया जाए कि इससे उपयोगकर्ता को दिखने वाली लेटेन्सी न बढ़े. Google Search, परफ़ॉर्मेंस को बहुत गंभीरता से लेता है. पिछले समय में, Google Search ने नई सुविधाओं को लॉन्च करने से रोक दिया था. ऐसा तब किया गया था, जब किसी उपयोगकर्ता समूह के लिए, नई सुविधाओं की वजह से कुछ मिलीसेकंड की अतिरिक्त देरी हो रही थी.
टीम ने जब शुरुआती एक्सपेरिमेंट के दौरान परफ़ॉर्मेंस डेटा इकट्ठा करना शुरू किया, तो यह साफ़ हो गया कि समस्या आएगी. खोज नतीजों के पेज के लिए, नेविगेशन के अनुरोधों के जवाब में मिला एचटीएमएल डाइनैमिक होता है. यह Search के वेब सर्वर पर चलने वाले लॉजिक के हिसाब से अलग-अलग होता है. फ़िलहाल, सर्विस वर्कर के पास इस लॉजिक को दोहराने का कोई तरीका नहीं है. साथ ही, वह कैश मेमोरी में सेव किए गए एचटीएमएल को तुरंत वापस नहीं भेज सकता. वह सिर्फ़ नेविगेशन के अनुरोधों को बैकएंड वेब सर्वर को भेज सकता है. इसके लिए, नेटवर्क के अनुरोध की ज़रूरत होती है.
सर्विस वर्कर के बिना, उपयोगकर्ता के नेविगेट करते ही यह नेटवर्क अनुरोध तुरंत हो जाता है. जब कोई सर्विस वर्कर रजिस्टर हो जाता है, तो उसे हमेशा चालू करना होता है. साथ ही, उसे अपने fetch इवेंट हैंडलर को लागू करने का मौका देना होता है. भले ही, फ़ेच हैंडलर के नेटवर्क पर जाने के अलावा कुछ और करने की कोई संभावना न हो. सर्विस वर्कर कोड को शुरू होने और चलने में लगने वाला समय, हर नेविगेशन के ऊपर जोड़ा गया एक तरह का ओवरहेड होता है:
इस वजह से, सर्विस वर्कर को लागू करने में बहुत ज़्यादा समय लगता है. इसलिए, इसके अन्य फ़ायदों को सही ठहराना मुश्किल हो जाता है. इसके अलावा, टीम ने यह भी पाया कि असल दुनिया के डिवाइसों पर सर्विस वर्कर के बूट होने के समय को मेज़र करने के आधार पर, स्टार्टअप के समय में काफ़ी अंतर था. कुछ कमज़ोर मोबाइल डिवाइसों को सर्विस वर्कर शुरू करने में उतना ही समय लगता था जितना नतीजों के पेज के एचटीएमएल के लिए नेटवर्क अनुरोध करने में लग सकता है.
समाधान: नेविगेशन प्रीलोड का इस्तेमाल करें
Google Search टीम को सर्विस वर्कर लॉन्च करने में मदद करने वाली सबसे अहम सुविधा नेविगेशन प्रीलोड है. नेविगेशन प्रीलोड का इस्तेमाल करना, किसी भी ऐसे सर्विस वर्कर के लिए परफ़ॉर्मेंस को बेहतर बनाने का एक अहम तरीका है जिसे नेविगेशन के अनुरोधों को पूरा करने के लिए, नेटवर्क से मिले जवाब का इस्तेमाल करना होता है. यह ब्राउज़र को एक हिंट देता है, ताकि वह सर्विस वर्कर के चालू होते ही नेविगेशन का अनुरोध तुरंत शुरू कर सके:
जब तक सर्विस वर्कर को शुरू होने में लगने वाला समय, नेटवर्क से जवाब मिलने में लगने वाले समय से कम होता है, तब तक सर्विस वर्कर की वजह से कोई लेटेन्सी ओवरहेड नहीं होना चाहिए.
Search टीम को कम कॉन्फ़िगरेशन वाले मोबाइल डिवाइसों पर सर्विस वर्कर का इस्तेमाल करने से भी बचना था. ऐसा इसलिए, क्योंकि इन डिवाइसों पर सर्विस वर्कर को बूट होने में लगने वाला समय, नेविगेशन के अनुरोध से ज़्यादा हो सकता है. "लो-एंड" डिवाइस की कोई तय परिभाषा नहीं है. इसलिए, उन्होंने डिवाइस में इंस्टॉल की गई कुल रैम की जांच करने का अनुमान लगाया. दो गीगाबाइट से कम मेमोरी वाले डिवाइस, उनकी लो-एंड डिवाइस कैटगरी में आते हैं. इनमें सर्विस वर्कर के स्टार्टअप में लगने वाला समय स्वीकार नहीं किया जा सकता.
स्टोरेज की उपलब्ध जगह भी एक अहम पहलू है. ऐसा इसलिए, क्योंकि आने वाले समय में इस्तेमाल के लिए कैश मेमोरी में सेव किए जाने वाले संसाधनों का पूरा सेट, कई मेगाबाइट का हो सकता है. navigator.storage इंटरफ़ेस की मदद से, Google Search पेज को पहले से ही यह पता चल जाता है कि स्टोरेज कोटा पूरा होने की वजह से, डेटा को कैश मेमोरी में सेव करने की कोशिशें विफल हो सकती हैं या नहीं.
इस वजह से, Search टीम के पास कई शर्तें थीं. इनका इस्तेमाल करके, यह तय किया जा सकता था कि सर्विस वर्कर का इस्तेमाल करना है या नहीं: अगर कोई उपयोगकर्ता, नेविगेशन प्रीलोड की सुविधा के साथ काम करने वाले ब्राउज़र का इस्तेमाल करके Google Search पेज पर आता है और उसके डिवाइस में कम से कम दो जीबी रैम है और स्टोरेज की जगह भी काफ़ी है, तो सर्विस वर्कर रजिस्टर हो जाता है. जो ब्राउज़र या डिवाइस इस शर्त को पूरा नहीं करते हैं उनमें सर्विस वर्कर नहीं होगा. हालांकि, उन्हें Google Search का वही अनुभव मिलेगा जो उन्हें हमेशा मिलता है.
चुनिंदा रजिस्ट्रेशन का एक फ़ायदा यह है कि इससे छोटा और ज़्यादा असरदार सर्विस वर्कर शिप किया जा सकता है. सर्विस वर्कर कोड को चलाने के लिए, नए ब्राउज़र को टारगेट करने से, पुराने ब्राउज़र के लिए ट्रांसपाइलेशन और पॉलीफ़िल का ओवरहेड खत्म हो जाता है. इससे, सर्विस वर्कर के कुल साइज़ में से करीब आठ किलोबाइट का बिना कंप्रेस किया गया JavaScript कोड हट गया.
समस्या: सर्विस वर्कर के स्कोप
जब Search टीम ने लेटेन्सी से जुड़े कई एक्सपेरिमेंट किए और उन्हें भरोसा हो गया कि नेविगेशन प्रीलोड का इस्तेमाल करने से, उन्हें सर्विस वर्कर का इस्तेमाल करने के लिए एक सही और लेटेन्सी-न्यूट्रल पाथ मिल गया है, तो कुछ व्यावहारिक समस्याएं सामने आने लगीं. इनमें से एक समस्या, सर्विस वर्कर के स्कोपिंग के नियमों से जुड़ी है. किसी सर्विस वर्कर का स्कोप यह तय करता है कि वह किन पेजों को कंट्रोल कर सकता है.
स्कोपिंग, यूआरएल पाथ प्रीफ़िक्स के आधार पर काम करती है. एक वेब ऐप्लिकेशन को होस्ट करने वाले डोमेन के लिए, यह समस्या नहीं है. ऐसा इसलिए, क्योंकि आम तौर पर / के ज़्यादा से ज़्यादा स्कोप वाले सर्विस वर्कर का इस्तेमाल किया जाता है. इससे डोमेन के किसी भी पेज को कंट्रोल किया जा सकता है.
हालांकि, Google Search के यूआरएल का स्ट्रक्चर थोड़ा ज़्यादा पेचीदा होता है.
अगर सर्विस वर्कर को / का ज़्यादा से ज़्यादा स्कोप दिया जाता है, तो वह / (या क्षेत्रीय भाषा में इसके बराबर) के तहत होस्ट किए गए किसी भी पेज का कंट्रोल ले सकता है. साथ ही, उस डोमेन के तहत ऐसे यूआरएल भी मौजूद हैं जिनका Google Search से कोई लेना-देना नहीं है.www.google.com ज़्यादा सही और पाबंदी वाला स्कोप /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 को 'all' पर सेट करके रजिस्टर किया जाता है, ताकि यह पक्का किया जा सके कि हेडर का पालन किया गया है. Google Search का वेब बैकएंड, जैसा कि आपको पता होगा, दुनिया भर में मौजूद सर्वर का एक बड़ा सेट है. इसके लिए, यह ज़रूरी है कि यह ज़्यादा से ज़्यादा समय तक काम करता रहे. सर्विस वर्कर स्क्रिप्ट के कॉन्टेंट पर असर डालने वाले बदलाव को धीरे-धीरे लागू किया जाता है.
अगर कोई उपयोगकर्ता अपडेट किए गए बैकएंड पर जाता है और फिर तुरंत किसी ऐसे दूसरे पेज पर जाता है जिसके बैकएंड को अब तक अपडेट किया गया सर्विस वर्कर नहीं मिला है, तो वह कई बार वर्शन के बीच फ़्लिप-फ़्लॉप करेगा. इसलिए, ब्राउज़र को यह निर्देश देने से कोई खास नुकसान नहीं होता कि वह अपडेट की गई स्क्रिप्ट की जांच सिर्फ़ तब करे, जब पिछली जांच के बाद 25 मिनट बीत चुके हों. इस सुविधा के लिए ऑप्ट-इन करने का फ़ायदा यह है कि इससे, उस एंडपॉइंट को मिलने वाले ट्रैफ़िक में काफ़ी कमी आ जाती है जो सर्विस वर्कर स्क्रिप्ट को डाइनैमिक तरीके से जनरेट करता है.
इसके अलावा, सर्विस वर्कर स्क्रिप्ट के एचटीटीपी रिस्पॉन्स पर एक ईटैग हेडर सेट किया जाता है. इससे यह पक्का होता है कि 25 मिनट के बाद अपडेट की जांच किए जाने पर, सर्वर एचटीटीपी 304 रिस्पॉन्स के साथ तुरंत जवाब दे सकता है. ऐसा तब होता है, जब इस दौरान डिप्लॉय किए गए सर्विस वर्कर में कोई अपडेट न हुआ हो.
Google Search के वेब ऐप्लिकेशन में कुछ इंटरैक्शन के लिए, सिंगल पेज ऐप्लिकेशन स्टाइल नेविगेशन का इस्तेमाल किया जाता है.जैसे, History API के ज़रिए. हालांकि, ज़्यादातर मामलों में Google Search एक पारंपरिक वेब ऐप्लिकेशन है, जो "असली" नेविगेशन का इस्तेमाल करता है. इनका इस्तेमाल तब किया जाता है, जब टीम यह तय करती है कि सर्विस वर्कर के अपडेट के लाइफ़साइकल को तेज़ करने के लिए, दो विकल्पों का इस्तेमाल करना असरदार होगा:
clients.claim()
और
skipWaiting().
Google Search के इंटरफ़ेस पर क्लिक करने से, आम तौर पर नए एचटीएमएल दस्तावेज़ों पर रीडायरेक्ट किया जाता है. skipWaiting को कॉल करने से यह पक्का होता है कि अपडेट किए गए सर्विस वर्कर को इंस्टॉल करने के तुरंत बाद, नेविगेशन के नए अनुरोधों को हैंडल करने का मौका मिले. इसी तरह, clients.claim() को कॉल करने का मतलब है कि अपडेट किया गया सर्विस वर्कर, Google Search के उन सभी खुले पेजों को कंट्रोल कर सकता है जिन्हें कंट्रोल नहीं किया गया है. ऐसा सर्विस वर्कर के चालू होने के बाद किया जाता है.
Google Search ने जिस तरीके का इस्तेमाल किया है वह ज़रूरी नहीं कि सभी के लिए काम करे. यह तरीका, अलग-अलग कॉम्बिनेशन के साथ A/B टेस्टिंग करने के बाद मिला है. इस टेस्टिंग में, Google Search ने अलग-अलग कॉम्बिनेशन के साथ खोज के नतीजे दिखाए. इसके बाद, उसे पता चला कि कौनसा कॉम्बिनेशन सबसे अच्छा काम करता है.
जिन डेवलपर के बैकएंड इन्फ़्रास्ट्रक्चर की मदद से, अपडेट को ज़्यादा तेज़ी से डिप्लॉय किया जा सकता है वे यह पसंद कर सकते हैं कि ब्राउज़र, अपडेट की गई सर्विस वर्कर स्क्रिप्ट की जांच ज़्यादा से ज़्यादा बार करे. इसके लिए, एचटीटीपी कैश मेमोरी को हमेशा अनदेखा करना ज़रूरी है.
अगर आपको ऐसा सिंगल पेज ऐप्लिकेशन बनाना है जिसे उपयोगकर्ता लंबे समय तक खुला रख सकते हैं, तो skipWaiting() का इस्तेमाल करना शायद आपके लिए सही विकल्प नहीं है. ऐसा इसलिए, क्योंकि अगर आपने लंबे समय तक चलने वाले क्लाइंट के दौरान नए सर्विस वर्कर को चालू करने की अनुमति दी, तो आपको कैश मेमोरी में मौजूद डेटा के अलग-अलग वर्शन की समस्या का सामना करना पड़ सकता है.
सीखने लायक ज़रूरी बातें
डिफ़ॉल्ट रूप से, सर्विस वर्कर परफ़ॉर्मेंस पर कोई असर नहीं डालते
अपने वेब ऐप्लिकेशन में सर्विस वर्कर जोड़ने का मतलब है कि आपको JavaScript का एक और हिस्सा जोड़ना होगा. इसे लोड और एक्ज़ीक्यूट करने के बाद ही, आपका वेब ऐप्लिकेशन अपने अनुरोधों के जवाब पा सकेगा. अगर वे जवाब नेटवर्क के बजाय लोकल कैश मेमोरी से मिलते हैं, तो सर्विस वर्कर को चलाने का ओवरहेड आम तौर पर, कैश मेमोरी को पहले इस्तेमाल करने से मिलने वाले फ़ायदे की तुलना में बहुत कम होता है. हालांकि, अगर आपको पता है कि नेविगेशन के अनुरोधों को मैनेज करते समय, आपके सर्विस वर्कर को हमेशा नेटवर्क से सलाह लेनी पड़ती है, तो नेविगेशन प्रीलोड का इस्तेमाल करना परफ़ॉर्मेंस के लिए बहुत फ़ायदेमंद होता है.
सर्विस वर्कर, अब भी प्रोग्रेसिव एन्हैंसमेंट हैं!
आज सर्विस वर्कर की सुविधा, एक साल पहले की तुलना में ज़्यादा बेहतर है. सभी मॉडर्न ब्राउज़र में अब कम से कम कुछ सर्विस वर्कर के लिए सहायता उपलब्ध है. हालांकि, अफ़सोस की बात है कि सर्विस वर्कर की कुछ बेहतर सुविधाएं, जैसे कि बैकग्राउंड सिंक और नेविगेशन प्रीलोड, सभी के लिए उपलब्ध नहीं हैं. आपको जिन सुविधाओं की ज़रूरत है उनके लिए सुविधा की जांच करना और सिर्फ़ तब सर्विस वर्कर को रजिस्टर करना, अब भी एक सही तरीका है.
इसी तरह, अगर आपने वाइल्ड में एक्सपेरिमेंट किए हैं और आपको पता है कि सर्विस वर्कर के अतिरिक्त ओवरहेड की वजह से, कम कॉन्फ़िगरेशन वाले डिवाइसों पर परफ़ॉर्मेंस खराब हो जाती है, तो उन स्थितियों में भी सर्विस वर्कर को रजिस्टर करने से बचा जा सकता है.
आपको सर्विस वर्कर को प्रोग्रेसिव एन्हांसमेंट के तौर पर इस्तेमाल करना चाहिए. इसे वेब ऐप्लिकेशन में तब जोड़ा जाता है, जब सभी ज़रूरी शर्तें पूरी हो जाती हैं. साथ ही, सर्विस वर्कर से उपयोगकर्ता अनुभव और पेज लोड होने की परफ़ॉर्मेंस को बेहतर बनाने में मदद मिलती है.
हर चीज़ को मेज़र करना
यह पता लगाने का सिर्फ़ एक तरीका है कि सर्विस वर्कर को शिप करने से, उपयोगकर्ताओं के अनुभव पर सकारात्मक या नकारात्मक असर पड़ा है या नहीं. इसके लिए, आपको एक्सपेरिमेंट करना होगा और नतीजों का आकलन करना होगा.
काम की मेज़रमेंट सेटिंग को सेट अप करने की खास जानकारी इस बात पर निर्भर करती है कि आपने किस Analytics सेवा देने वाली कंपनी की सेवा का इस्तेमाल किया है. साथ ही, यह इस बात पर भी निर्भर करती है कि आपने डिप्लॉयमेंट सेटअप में सामान्य तौर पर एक्सपेरिमेंट कैसे किए हैं. मेट्रिक इकट्ठा करने के लिए Google Analytics का इस्तेमाल करने का एक तरीका, इस केस स्टडी में बताया गया है. यह केस स्टडी, Google I/O वेब ऐप्लिकेशन में सर्विस वर्कर का इस्तेमाल करने के अनुभव पर आधारित है.
लक्ष्य नहीं
वेब डेवलपमेंट कम्यूनिटी के कई लोग, सर्विस वर्कर को प्रोग्रेसिव वेब ऐप्लिकेशन से जोड़ते हैं. हालांकि, टीम का शुरुआती लक्ष्य "Google Search PWA" बनाना नहीं था. Google Search का वेब ऐप्लिकेशन, वेब ऐप्लिकेशन मेनिफ़ेस्ट में मेटाडेटा उपलब्ध नहीं कराता. साथ ही, यह उपयोगकर्ताओं को 'होम स्क्रीन में जोड़ें' फ़्लो का इस्तेमाल करने के लिए भी नहीं कहता. Search टीम इस बात से संतुष्ट है कि उपयोगकर्ता, Google Search के क्लासिक एंट्री पॉइंट का इस्तेमाल करके उनके वेब ऐप्लिकेशन पर आ रहे हैं.
Google Search के वेब वर्शन को इंस्टॉल किए गए ऐप्लिकेशन के बराबर बनाने के बजाय, शुरुआती रिलीज़ में मौजूदा वेबसाइट को बेहतर बनाने पर फ़ोकस किया गया था.
Acknowledgements
Google Search की वेब डेवलपमेंट टीम को धन्यवाद. उन्होंने सर्विस वर्कर को लागू करने में हमारी मदद की. साथ ही, इस लेख को लिखने के लिए ज़रूरी बैकग्राउंड मटीरियल शेयर किया. खास तौर पर, फ़िलिप गोल, राजेश जगन्नाथन, आर. सैम्युअल क्लैचको, एंडी मार्टोन, लियोनार्डो पेना, राशेल शीरर, ग्रेग टेरोनो, और क्ले वूलम.
अपडेट (अक्टूबर 2021): इस लेख को पहली बार पब्लिश किए जाने के बाद, Google Search टीम ने अपने मौजूदा सर्विस वर्कर आर्किटेक्चर के फ़ायदों और नुकसानों का फिर से आकलन किया है. ऊपर बताया गया सर्विस वर्कर बंद किया जा रहा है. Google Search के वेब इन्फ़्रास्ट्रक्चर में बदलाव होने पर, टीम अपने सर्विस वर्कर के डिज़ाइन की समीक्षा कर सकती है.