सर्विस वर्कर को Google Search पर लाना

इसमें यह जानकारी होती है कि क्या शिप किया गया है, इसका असर कैसे मापा गया, और क्या-क्या फ़ायदे हुए.

बैकग्राउंड

Google पर किसी भी विषय के बारे में खोजें. ऐसा करने पर आपको ऐसा पेज दिखता है जिसे तुरंत आसानी से पहचाना जा सकता है और आपको काम के और काम के नतीजे दिखाए जाते हैं. शायद आपको यह नहीं पता कि खोज के नतीजों वाला यह पेज कुछ खास मामलों में, सर्विस वर्कर नाम की बेहतरीन वेब टेक्नोलॉजी से आता है.

Google Search के लिए सर्विस वर्कर की मदद शुरू करने से, परफ़ॉर्मेंस पर बुरा असर डाले बिना कई टीमों में काम करने वाले कई इंजीनियर की ज़रूरत पड़ती है. इससे यह पता चलता है कि कौनसा सामान शिप किया गया है, परफ़ॉर्मेंस को कैसे मेज़र किया गया, और कौनसा कारोबारी लेन-देन हुआ.

सर्विस वर्कर को एक्सप्लोर करने की मुख्य वजहें

किसी वेब ऐप्लिकेशन में सर्विस वर्कर को जोड़ने से, आपको अपनी साइट की बनावट में किसी भी तरह का बदलाव करने की तरह, साफ़ तौर पर लक्ष्य तय करने चाहिए. Google Search टीम के लिए, इसकी कुछ मुख्य वजहें थीं कि किसी सर्विस वर्कर को जोड़ना क्यों सही था.

खोज के नतीजों को सीमित तौर पर कैश मेमोरी में सेव करना

Google Search की टीम ने पाया कि लोग आम तौर पर कम समय में एक जैसे शब्दों को एक से ज़्यादा बार खोजते हैं. एक जैसे नतीजे पाने के लिए, बैकएंड का नया अनुरोध करने के बजाय, Search की टीम कैश मेमोरी का फ़ायदा लेना चाहती थी. साथ ही, बार-बार किए जाने वाले अनुरोधों को स्थानीय तौर पर पूरा करना चाहती थी.

अपडेट की अहमियत को कम नहीं किया जा सकता. कई बार उपयोगकर्ता एक ही शब्द को बार-बार खोजते हैं, क्योंकि यह एक नया विषय है और वे नए नतीजे देखने की उम्मीद करते हैं. सर्विस वर्कर का इस्तेमाल करने से सर्च टीम, लोकल कैश मेमोरी में कैश मेमोरी में सेव किए गए खोज नतीजों की अवधि को कंट्रोल करने के लिए सबसे पहले से सटीक लॉजिक लागू कर सकती है. साथ ही, उपयोगकर्ता के हिसाब से उनकी रफ़्तार और अपडेट हुए जैसी जानकारी पा सकती है.

ऑफ़लाइन मोड में काम का अनुभव

इसके अलावा, Google Search की टीम बेहतर ऑफ़लाइन अनुभव देना चाहती थी. जब कोई उपयोगकर्ता किसी विषय के बारे में जानकारी पाना चाहता है, तो वह सीधे Google Search पेज पर जाकर, इंटरनेट कनेक्शन की चिंता किए बिना, खोजना शुरू करना चाहता है.

किसी सर्विस वर्कर के बिना, ऑफ़लाइन रहते हुए Google खोज पेज पर जाने से सिर्फ़ ब्राउज़र के स्टैंडर्ड नेटवर्क गड़बड़ी पेज पर ले जाया जाएगा और उपयोगकर्ताओं को यह याद रखना होगा कि उनके कनेक्शन पर वापस आने के बाद फिर से कोशिश करनी होगी. सर्विस वर्कर की मदद से, कस्टम ऑफ़लाइन एचटीएमएल रिस्पॉन्स दिया जा सकता है. साथ ही, उपयोगकर्ताओं को तुरंत अपनी खोज क्वेरी डालने की अनुमति दी जा सकती है.

इंटरनेट कनेक्शन न होने तक परिणाम उपलब्ध नहीं होंगे, लेकिन सर्विस वर्कर, बैकग्राउंड सिंक एपीआई का इस्तेमाल करके डिवाइस के वापस ऑनलाइन होने पर, खोज को स्थगित करने और Google के सर्वर पर भेजने की अनुमति देता है.

JavaScript को बेहतर तरीके से कैश मेमोरी में सेव करना और दिखाना

दूसरा मकसद, मॉड्यूलराइज़ किए गए JavaScript कोड की कैश मेमोरी और लोडिंग को ऑप्टिमाइज़ करना था. इससे खोज नतीजों के पेज पर कई तरह की सुविधाएं उपलब्ध होती हैं. JavaScript बंडलिंग से ऐसे कई फ़ायदे मिलते हैं जो सर्विस वर्कर की भागीदारी न होने पर भी काम करते हैं. इसलिए, सर्च टीम पूरी तरह से बंडल बनाना नहीं बंद करना चाहती थी.

रनटाइम के दौरान सर्विस वर्कर के JavaScript के छोटे-छोटे हिस्सों को वर्शन और कैश मेमोरी में सेव करने की क्षमता का इस्तेमाल करके Search टीम को शक हुआ कि वे कैश चर्न आउट की संख्या को कम कर सकते हैं. साथ ही, यह पक्का कर सकते हैं कि आने वाले समय में फिर से इस्तेमाल किए जाने वाले JavaScript को सही तरीके से कैश मेमोरी में सेव किया जा सके. उनके सर्विस वर्कर के अंदर का लॉजिक, ऐसे बंडल के लिए भेजे जाने वाले एचटीटीपी अनुरोध का विश्लेषण कर सकता है जिसमें कई JavaScript मॉड्यूल हों. साथ ही, जब भी संभव हो, तब कई और लोकल कैश मेमोरी वाले मॉड्यूल को एक साथ जोड़कर पूरा किया जा सकता है. इससे उपयोगकर्ता की बैंडविड्थ कम होती है और ज़रूरत के हिसाब से ज़्यादा रिस्पॉन्स मिलता है.

सर्विस वर्कर से मिले, कैश मेमोरी में सेव किए गए JavaScript का इस्तेमाल करने के भी फ़ायदे होते हैं: Chrome में, उस JavaScript को पार्स किया गया बाइट कोड दिखाना, जिसे सेव किया जाता है और उसका फिर से इस्तेमाल किया जाता है. इससे, पेज पर JavaScript चलाने के लिए, रनटाइम के दौरान कम काम करना पड़ता है.

चुनौतियां और समाधान

टीम के बताए गए लक्ष्यों को हासिल करने के लिए जिन रुकावटों को दूर करना ज़रूरी है, वे यहां दिए गए हैं. हालांकि, इनमें से कुछ चुनौतियां सिर्फ़ Google Search के लिए हैं, लेकिन उनमें से कई चुनौतियां ऐसी कई साइटों पर लागू होती हैं जो सर्विस वर्कर के डिप्लॉयमेंट के बारे में सोच रही होंगी.

समस्या: सर्विस वर्कर ओवरहेड

Google Search पर सर्विस वर्कर को लॉन्च करने में, सबसे बड़ी चुनौती यह थी कि इसमें ऐसा कोई काम नहीं किया गया जिससे उपयोगकर्ता को इंतज़ार करने में लगने वाला समय बढ़ जाए. Google Search, परफ़ॉर्मेंस को बहुत गंभीरता से लेता है. इससे पहले, यह सुविधा नई सुविधाओं के लॉन्च को ब्लॉक कर देती है. ऐसा तब होता है, जब इस सुविधा ने उपयोगकर्ताओं की किसी बड़ी संख्या के लिए, दस मिलीसेकंड तक अतिरिक्त इंतज़ार का समय भी दिया हो.

जब टीम ने अपने शुरुआती प्रयोगों के दौरान परफ़ॉर्मेंस डेटा इकट्ठा करना शुरू किया, तो यह साफ़ हो गया कि कोई समस्या होगी. खोज के नतीजों वाले पेज के लिए, नेविगेशन अनुरोधों के जवाब में दिखने वाला एचटीएमएल डाइनैमिक होता है. साथ ही, यह Search के वेब सर्वर पर चलाए जाने वाले लॉजिक के हिसाब से अलग-अलग होता है. फ़िलहाल, ऐसा कोई तरीका नहीं है कि सर्विस वर्कर इस लॉजिक को दोहराकर तुरंत कैश मेमोरी में सेव किए गए एचटीएमएल को दिखा सकें. सबसे अच्छा तरीका है कि बैकएंड वेब सर्वर पर नेविगेशन अनुरोध भेजें. इसके लिए नेटवर्क अनुरोध करना ज़रूरी होता है.

सर्विस वर्कर के बिना, नेटवर्क का यह अनुरोध उपयोगकर्ता के नेविगेशन के तुरंत बाद होता है. किसी सर्विस वर्कर के रजिस्टर होने पर, उसे हमेशा चालू होना चाहिए और उसे fetch इवेंट हैंडलर को चलाने का एक मौका देना चाहिए. ऐसा तब भी होता है, जब यह ज़रूरी नहीं हो कि ये फ़ेच हैंडलर, नेटवर्क पर जाने के अलावा कुछ और करें. सर्विस वर्कर कोड को चालू होने और उसे चलाने में लगने वाला समय, हर नेविगेशन के ऊपर जोड़ा जाता है, जो कि पूरी तरह से ओवरहेड होता है:

इसकी वजह से, सर्विस वर्कर को लागू करने में इंतज़ार के समय को बहुत नुकसान पहुंचता है, ताकि किसी अन्य फ़ायदे को सही ठहराया न जा सके. इसके अलावा, टीम ने पाया कि असल दुनिया के डिवाइसों पर सर्विस वर्कर के बूट टाइम को मापने के आधार पर, स्टार्टअप टाइम का एक बड़ा डिस्ट्रिब्यूशन था. कुछ लो-एंड मोबाइल डिवाइसों को सर्विस वर्कर को शुरू करने में उतना ही समय लगता था जितना नतीजे वाले पेज के एचटीएमएल के लिए नेटवर्क अनुरोध बनाने में लग सकता है.

समाधान: नेविगेशन प्रीलोड का इस्तेमाल करना

नेविगेशन प्रीलोड, एक ऐसी सबसे खास सुविधा है जिसने Google Search टीम को अपने सर्विस वर्कर लॉन्च के साथ आगे जाने में मदद की. नेविगेशन प्रीलोड का इस्तेमाल करना, किसी भी सर्विस वर्कर के लिए परफ़ॉर्मेंस की एक अहम जीत है. इसे नेविगेशन के अनुरोधों को पूरा करने के लिए, नेटवर्क से मिले रिस्पॉन्स का इस्तेमाल करना होता है. इससे, ब्राउज़र को इस बात का संकेत मिलता है कि सर्विस वर्कर चालू होते ही तुरंत नेविगेशन अनुरोध शुरू कर दिया जाएगा:

अगर सर्विस वर्कर को चालू होने में लगने वाला समय नेटवर्क से वापस जवाब मिलने में लगने वाले समय से कम है, तो सर्विस वर्कर को इंतज़ार के समय के बारे में कोई ओवरहेड नहीं देना चाहिए.

सर्च टीम को ऐसे कम कीमत वाले मोबाइल डिवाइसों पर सर्विस वर्कर का इस्तेमाल करने से बचना था जिन पर सर्विस वर्कर के बूट होने में लगने वाला समय, नेविगेशन के अनुरोध से ज़्यादा हो सकता है. "कम कीमत वाले" डिवाइस में कोई मुश्किल और आसान नियम नहीं है, इसलिए वे डिवाइस पर इंस्टॉल किए गए कुल रैम की जांच करने के अनुमान से जुड़े हैं. 2 गीगाबाइट (जीबी) से कम की मेमोरी वाली कोई भी चीज़, उन डिवाइस की लो-एंड कैटगरी में चली गई जहां सर्विस वर्कर के शुरू होने में लगने वाला समय स्वीकार नहीं किया जाएगा.

स्टोरेज के लिए उपलब्ध जगह एक और बात है, क्योंकि आने वाले समय में इस्तेमाल करने के लिए, कैश मेमोरी में सेव किए जाने वाले संसाधनों का पूरा सेट, कई मेगाबाइट तक चल सकता है. navigator.storage इंटरफ़ेस की मदद से Google Search पेज, पहले से यह पता लगा लेता है कि क्या स्टोरेज कोटा पूरा न हो पाने की वजह से, डेटा को कैश मेमोरी में सेव करने की उनकी कोशिश के काम न करने का जोखिम है या नहीं.

इससे Search टीम के पास कई शर्तों के आधार पर ऐसे नियम हैं जिनका इस्तेमाल करके वे यह तय कर सकते हैं कि सर्विस वर्कर का इस्तेमाल करना है या नहीं: अगर कोई उपयोगकर्ता 'Google सर्च' पेज पर ऐसे ब्राउज़र पर आता है जो नेविगेशन प्रीलोड की सुविधा देता हो और उसके पास कम से कम 2 गीगाबाइट (जीबी) रैम हो और स्टोरेज के लिए जगह हो, तो सर्विस वर्कर रजिस्टर किया जाता है. इन शर्तों को पूरा न करने वाले ब्राउज़र या डिवाइसों पर, सेवा देने वाला कोई व्यक्ति नहीं होगा. हालांकि, उन्हें Google Search का वही अनुभव मिलेगा जो उन्हें हमेशा दिखता है.

इस चुनिंदा रजिस्ट्रेशन का एक फ़ायदा यह है कि इसमें छोटे और ज़्यादा कुशल सर्विस वर्कर को शिप किया जा सकता है. सर्विस वर्कर कोड को चलाने के लिए, मॉडर्न ब्राउज़र को टारगेट करने से पुराने ब्राउज़र के लिए ट्रांसपिलेशन और पॉलीफ़िल का काम खत्म हो जाता है. इसकी वजह से, सर्विस वर्कर के लागू किए गए कोड के कुल साइज़ से, बिना कंप्रेस किए JavaScript कोड करीब 8 किलोबाइट कट गया.

समस्या: सर्विस वर्कर के दायरे

जब Search की टीम को इंतज़ार के समय से जुड़े काफ़ी प्रयोग करने लगे और उन्हें भरोसा हो गया कि नेविगेशन प्रीलोड का इस्तेमाल करने से, उन्हें सर्विस वर्कर का इस्तेमाल करने के लिए एक बेहतर और इंतज़ार का इंतज़ार करने वाला पाथ मिलेगा, तब कुछ व्यावहारिक समस्याएं सामने आने लगीं. इनमें से एक समस्या सर्विस वर्कर के स्कोपिंग नियमों से जुड़ी है. सर्विस वर्कर के दायरे से यह तय होता है कि वह किन पेजों को कंट्रोल कर सकता है.

स्कोपिंग, यूआरएल पाथ प्रीफ़िक्स के आधार पर काम करती है. एक वेब ऐप्लिकेशन होस्ट करने वाले डोमेन के लिए, यह कोई समस्या नहीं है. ऐसा इसलिए है, क्योंकि आम तौर पर / के ज़्यादा से ज़्यादा दायरे वाले सर्विस वर्कर का इस्तेमाल किया जाता है, जो डोमेन में मौजूद किसी भी पेज को कंट्रोल कर सकता है. हालांकि, Google Search के यूआरएल का स्ट्रक्चर थोड़ा मुश्किल है.

अगर सर्विस वर्कर को / का सबसे ज़्यादा स्कोप दिया जाता, तो इससे www.google.com (या क्षेत्रीय स्तर पर) के तहत होस्ट किए गए किसी भी पेज को कंट्रोल किया जा सकेगा. साथ ही, इस डोमेन में ऐसे यूआरएल हैं जिनका Google Search से कोई लेना-देना नहीं है. ज़्यादा सही और पाबंदी वाला दायरा /search होगा. इससे कम से कम ऐसे यूआरएल को हटा दिया जाएगा जिनका खोज के नतीजों से कोई लेना-देना नहीं है.

बदकिस्मती से, भले ही /search यूआरएल पाथ को Google Search के अलग-अलग नतीजों के साथ शेयर किया गया हो, लेकिन यूआरएल क्वेरी पैरामीटर से यह तय होता है कि खोज के किस तरह के नतीजे दिखाए जाएंगे. इनमें से कुछ फ़्लेवर, पारंपरिक वेब खोज नतीजे वाले पेज के मुकाबले पूरी तरह से अलग कोडबेस का इस्तेमाल करते हैं. उदाहरण के लिए, इमेज सर्च और Shopping 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 मिनट) रिस्पॉन्स हेडर के साथ दिखाया जाता है. साथ ही, इसे updateVia cache को 'सभी' पर सेट करने के लिए रजिस्टर किया जाता है, ताकि यह पक्का किया जा सके कि हेडर सही है. Google Search वेब बैकएंड, जैसा कि आप कल्पना कर सकते हैं, यह दुनिया भर में डिस्ट्रिब्यूट होने वाला एक बड़ा सर्वर सेट है. इसे जितना हो सके करीब 100% अपटाइम की ज़रूरत होती है. सर्विस वर्कर स्क्रिप्ट के कॉन्टेंट पर असर डालने वाले बदलाव को, रोलिंग तरीके से डिप्लॉय किया जाता है.

अगर कोई उपयोगकर्ता अपडेट किए गए किसी बैकएंड पर जाता है और फिर तेज़ी से दूसरे पेज पर जाता है, जिससे ऐसे बैकएंड को हिट किया जाता है जिसे अब तक अपडेट किया गया सर्विस वर्कर नहीं मिला है, तो वह वर्शन के बीच कई बार फ़्लिप-फ़्लॉप हो जाएगा. इसलिए, ब्राउज़र को अपडेट की गई स्क्रिप्ट की जांच करने के लिए कहें. ऐसा तब करें, जब पिछली जांच के बाद 25 मिनट बीत चुके हों. इस तरीके के लिए ऑप्ट-इन करने से, सर्विस वर्कर स्क्रिप्ट को डाइनैमिक तरीके से जनरेट करने वाले एंडपॉइंट से मिलने वाले ट्रैफ़िक में काफ़ी कमी आ रही है.

इसके अलावा, ETag हेडर, सर्विस वर्कर स्क्रिप्ट के एचटीटीपी रिस्पॉन्स पर सेट होता है, जिससे यह पक्का होता है कि 25 मिनट बीत जाने के बाद अपडेट की जांच किए जाने पर, सर्वर HTTP 304 रिस्पॉन्स के साथ बेहतर तरीके से रिस्पॉन्स दे सकता है. ऐसा तब होता है, जब इस दौरान डिप्लॉय किए गए सर्विस वर्कर के लिए कोई अपडेट न हो.

Google Search के वेब ऐप्लिकेशन में कुछ इंटरैक्शन के लिए, एक पेज वाले ऐप्लिकेशन-स्टाइल वाले नेविगेशन का इस्तेमाल किया जाता है.जैसे, इतिहास एपीआई की मदद से. हालांकि, Google Search एक पारंपरिक वेब ऐप्लिकेशन है, जो “रीयल” नेविगेशन का इस्तेमाल करता है. इसका असर तब होता है, जब टीम ने यह तय किया कि सर्विस वर्कर अपडेट की लाइफ़साइकल को तेज़ी से बढ़ाने वाले दो विकल्पों का इस्तेमाल करना असरदार होगा: clients.claim() और skipWaiting(). आम तौर पर, Google Search के इंटरफ़ेस पर क्लिक करके, नए एचटीएमएल दस्तावेज़ों पर जाया जाता है. skipWaiting को कॉल करने से यह पक्का होता है कि अपडेट किए गए सर्विस वर्कर को इंस्टॉलेशन के तुरंत बाद उन नए नेविगेशन अनुरोधों को मैनेज करने का मौका मिलता है. इसी तरह, clients.claim() को कॉल करने का मतलब है कि अपडेट किए गए सर्विस वर्कर को सर्विस वर्कर ऐक्टिवेट होने के बाद, ऐसे किसी भी खुले Google Search पेज को कंट्रोल करने का मौका मिलता है जो अनियंत्रित हैं.

यह ज़रूरी नहीं है कि Google Search ने जो समाधान अपनाया वह सभी के लिए कारगर साबित हुआ. इसकी वजह यह थी कि अलग-अलग सेवाओं के लिए, A/B टेस्टिंग के अलग-अलग कॉम्बिनेशन आज़माए गए. जिन डेवलपर का बैकएंड इन्फ़्रास्ट्रक्चर उन्हें ज़्यादा तेज़ी से अपडेट डिप्लॉय करने की सुविधा देता है वे शायद यह चाहें कि ब्राउज़र, अपडेट की गई सर्विस वर्कर स्क्रिप्ट को जितनी बार हो सके उतनी बार जांच करे. ऐसा करने के लिए, हमेशा एचटीटीपी कैश को अनदेखा करके ऐसा किया जा सकता है. अगर ऐसा सिंगल पेज ऐप्लिकेशन बनाया जा रहा है जिसे उपयोगकर्ता लंबे समय तक चालू रख सकते हैं, तो skipWaiting() का इस्तेमाल करना शायद आपके लिए सही न हो. अगर क्लाइंट के लंबे समय तक इस्तेमाल के दौरान नए सर्विस वर्कर को चालू करने की अनुमति दी जाती है, तो कैश मेमोरी में गड़बड़ी होने का जोखिम हो सकता है.

सीखने लायक ज़रूरी बातें

डिफ़ॉल्ट रूप से, सर्विस वर्कर परफ़ॉर्मेंस न्यूट्रल नहीं होते हैं

अपने वेब ऐप्लिकेशन में सर्विस वर्कर जोड़ने का मतलब है कि JavaScript का एक और हिस्सा शामिल करना, जिसे आपके वेब ऐप्लिकेशन से अनुरोधों पर रिस्पॉन्स मिलने से पहले लोड और एक्ज़ीक्यूट करने की ज़रूरत होती है. अगर वे जवाब नेटवर्क के बजाय लोकल कैश मेमोरी से आ रहे हैं, तो सर्विस वर्कर को चलाने का काम आम तौर पर कैश-फ़र्स्ट. हालांकि, अगर आपको पता है कि नेविगेशन अनुरोधों को हैंडल करते समय, आपके सर्विस वर्कर को हमेशा नेटवर्क से सलाह लेनी पड़ती है, तो नेविगेशन प्रीलोड का इस्तेमाल करना, परफ़ॉर्मेंस का एक अहम फ़ायदा है.

सर्विस वर्कर (अब भी!) लगातार बेहतर होते जा रहे हैं

सर्विस वर्कर की सहायता की कहानी एक साल पहले की तुलना में, आज और भी बेहतर हो गई है. सभी मॉडर्न ब्राउज़र में अब सर्विस वर्कर के लिए कुछ सुविधाएं हैं, लेकिन अफ़सोस है कि इनमें सर्विस वर्कर की कुछ बेहतर सुविधाएं हैं, जैसे कि बैकग्राउंड सिंक और नेविगेशन प्रीलोड, जिन्हें दुनिया भर में रोल आउट नहीं किया गया है. अपनी ज़रूरत के हिसाब से सुविधाओं की जांच करना और सर्विस वर्कर के मौजूद होने पर ही उन्हें रजिस्टर करना अब भी सही तरीका है.

इसी तरह, अगर आपने लंबे समय में एक्सपेरिमेंट चलाए हैं और आपको पता है कि कम कीमत वाले डिवाइस, सर्विस वर्कर के अतिरिक्त ओवरहेड के साथ खराब परफ़ॉर्म कर रहे हैं, तो उन स्थितियों में भी सर्विस वर्कर को रजिस्टर करने से बचा जा सकता है.

आपको सर्विस वर्कर के साथ प्रोग्रेसिव एन्हैंसमेंट के तौर पर इस काम को जारी रखना चाहिए. इसे वेब ऐप्लिकेशन में तब जोड़ा जाता है, जब सभी ज़रूरी शर्तें पूरी होती हैं. इससे सर्विस वर्कर, उपयोगकर्ता अनुभव और लोडिंग की पूरी परफ़ॉर्मेंस को बेहतर बनाता है.

हर चीज़ का आकलन करें

इसका मतलब है कि शिपिंग से जुड़े किसी सर्विस वर्कर का आपके उपयोगकर्ताओं के अनुभवों पर सकारात्मक या नकारात्मक असर पड़ता है या नहीं. इसका पता लगाने का सिर्फ़ एक तरीका है, नतीजों को आज़माना और उनका आकलन करना.

सही मेज़रमेंट सेट अप करने की खास बात इस बात पर निर्भर करती है कि आप किस Analytics प्रोवाइडर का इस्तेमाल कर रहे हैं और अपने डिप्लॉयमेंट सेटअप में आम तौर पर प्रयोग कैसे करते हैं. मेट्रिक इकट्ठा करने के लिए Google Analytics का इस्तेमाल करने का एक तरीका इस केस स्टडी में बताया गया है. यह Google I/O वेब ऐप्लिकेशन में सर्विस वर्कर के इस्तेमाल के अनुभव पर आधारित है.

गैर-लक्ष्य

वेब डेवलपमेंट कम्यूनिटी में शामिल कई सर्विस वर्कर प्रोग्रेसिव वेब ऐप्लिकेशन के साथ काम करते हैं, लेकिन "Google Search PWA" बनाना टीम का शुरुआती लक्ष्य नहीं था. Google Search का वेब ऐप्लिकेशन फ़िलहाल किसी वेब ऐप्लिकेशन मेनिफ़ेस्ट की मदद से मेटाडेटा उपलब्ध नहीं कराता है. न ही यह उपयोगकर्ताओं को होम स्क्रीन पर जोड़ें वाले फ़्लो से जाने के लिए बढ़ावा देता है. फ़िलहाल, खोज टीम उन उपयोगकर्ताओं से संतुष्ट है जो उनके वेब ऐप्लिकेशन पर Google Search के लिए परंपरागत एंट्री पॉइंट से आते हैं.

Google Search के वेब अनुभव को इंस्टॉल किए गए ऐप्लिकेशन की तरह बनाने के बजाय, शुरुआती रोल आउट पर ध्यान दिया गया था.

स्वीकार हैं

सर्विस वर्कर को लागू करने पर काम करने, और इस लेख को लिखने में इस्तेमाल हुए बैकग्राउंड कॉन्टेंट को शेयर करने के लिए, Google Search की पूरी वेब डेवलपमेंट टीम को धन्यवाद. खास तौर पर, उनका धन्यवाद फ़िलिप गोले, राजेश जगन्नाथन, आर॰ सैमुअल क्लेचको, ऐंडी मार्टन, लियोनार्डो पेनिया, रेचल शरर, ग्रेग टेरोनो, और क्ले वूलम.

अपडेट (अक्टूबर 2021): इस लेख को मूल रूप से पब्लिश किए जाने के बाद, Google Search की टीम ने अपने मौजूदा सर्विस वर्कर आर्किटेक्चर के फ़ायदों और कमियों का फिर से आकलन किया है. ऊपर जिस सर्विस वर्कर के बारे में बताया गया है उसे बंद किया जा रहा है. जैसे-जैसे Google Search का वेब इंफ़्रास्ट्रक्चर बेहतर हो रहा है, वैसे-वैसे टीम अपने सर्विस वर्कर डिज़ाइन को बेहतर बना सकती है.