tl;dr
Chrome 68 से, सर्विस वर्कर स्क्रिप्ट के अपडेट की जांच करने वाले एचटीटीपी अनुरोधों को अब डिफ़ॉल्ट रूप से, एचटीटीपी कैश मेमोरी से पूरा नहीं किया जाएगा. यह डेवलपर से जुड़ी सामान्य समस्या के आस-पास काम करता है. इसमें सर्विस वर्कर स्क्रिप्ट पर अनजाने में Cache-Control हेडर सेट करने से, अपडेट में देरी हो सकती है.
अगर आपने अपनी /service-worker.js स्क्रिप्ट को Cache-Control: max-age=0 के साथ दिखाकर, एचटीटीपी कैश मेमोरी से
पहले ही ऑप्ट-आउट कर लिया है, तो
नई डिफ़ॉल्ट कार्रवाई की वजह से आपको कोई बदलाव नहीं दिखेगा.
इसके अलावा, Chrome 78 से, बाइट-के-बाइट की तुलना, सर्विस वर्कर में लोड की गई स्क्रिप्ट पर importScripts() के ज़रिए लागू की जाएगी.
इंपोर्ट की गई स्क्रिप्ट में किया गया कोई भी बदलाव, सर्विस वर्कर अपडेट फ़्लो को ट्रिगर करेगा. यह बिलकुल वैसा ही है, जैसे टॉप-लेवल सर्विस वर्कर में होने वाले बदलाव से होता है.
बैकग्राउंड
जब भी आप सर्विस वर्कर के दायरे में आने वाले किसी नए पेज पर जाते हैं, तो JavaScript से साफ़ तौर पर registration.update() को कॉल करते हैं. इसके अलावा, जब भी किसी सर्विस वर्कर को push या sync इवेंट के ज़रिए "जागना" होता है, तब ब्राउज़र, सर्विस वर्कर स्क्रिप्ट के अपडेट देखने के लिए, navigator.serviceWorker.register() कॉल में पास किए गए JavaScript संसाधन का अनुरोध करता है.
इस लेख में दी गई जानकारी के लिए, मान लेते हैं कि इसका यूआरएल /service-worker.js है और इसमें importScripts() को एक बार कॉल किया गया है. यह सर्विस वर्कर के अंदर चलाए जाने वाले अतिरिक्त कोड को लोड करता है:
// Inside our /service-worker.js file:
importScripts('path/to/import.js');
// Other top-level code goes here.
क्या बदलाव होने वाले हैं?
Chrome 68 से पहले, /service-worker.js के लिए अपडेट का अनुरोध एचटीटीपी कैश के ज़रिए किया जाता था
(जैसा कि ज़्यादातर फ़ेच किए जाते हैं). इसका मतलब यह है कि अगर स्क्रिप्ट मूल रूप से Cache-Control:
max-age=600 के साथ भेजी गई थी, तो अगले 600 सेकंड (10 मिनट) में किए गए अपडेट नेटवर्क में नहीं जाएंगे, इसलिए हो सकता है कि उपयोगकर्ता को सर्विस वर्कर का सबसे अप-टू-डेट वर्शन न मिले. हालांकि, अगर max-age का साइज़ 86400 (24 घंटे) से ज़्यादा था, तो इसे 86400 के तौर पर माना जाएगा, ताकि उपयोगकर्ता हमेशा के लिए किसी खास वर्शन का इस्तेमाल न कर पाएं.
सर्विस वर्कर स्क्रिप्ट को अपडेट करने का अनुरोध करते समय, 68 से शुरू होने वाले एचटीटीपी कैश मेमोरी को अनदेखा कर दिया जाएगा. इससे मौजूदा वेब ऐप्लिकेशन को सर्विस वर्कर स्क्रिप्ट के लिए किए जाने वाले अनुरोधों की संख्या में बढ़ोतरी दिख सकती है. importScripts के अनुरोध अब भी एचटीटीपी कैश मेमोरी के ज़रिए किए जाएंगे. हालांकि, यह सिर्फ़ एक डिफ़ॉल्ट विकल्प है. रजिस्ट्रेशन का एक नया विकल्प updateViaCache उपलब्ध है, जो इस तरह के व्यवहार को कंट्रोल करता है.
updateViaCache
navigator.serviceWorker.register() को कॉल करते समय, डेवलपर अब एक नए विकल्प को पास कर सकते हैं: updateViaCache पैरामीटर.
इसके लिए तीन में से एक वैल्यू की ज़रूरत होती है: 'imports', 'all' या 'none'.
वैल्यू से यह तय होता है कि अपडेट किए गए सर्विस वर्कर रिसॉर्स की जांच करने का एचटीटीपी अनुरोध करते समय, ब्राउज़र का स्टैंडर्ड एचटीटीपी कैश काम करता है या नहीं. साथ ही, यह कैसे काम करता है.
अगर
'imports'पर सेट किया जाता है, तो/service-worker.jsस्क्रिप्ट के अपडेट की जांच करते समय, एचटीटीपी कैश मेमोरी से कभी भी सलाह नहीं ली जाएगी. हालांकि, इंपोर्ट की गई किसी स्क्रिप्ट (हमारे उदाहरण में,path/to/import.js) को फ़ेच करते समय आपसे सलाह ली जाएगी. यह डिफ़ॉल्ट सेटिंग है और यह Chrome 68 में शुरू होने वाले तरीके से मेल खाती है.अगर नीति को
'all'पर सेट किया जाता है, तो टॉप-लेवल/service-worker.jsस्क्रिप्ट के साथ-साथ सर्विस वर्कर में इंपोर्ट की गई किसी भी स्क्रिप्ट, जैसे किpath/to/import.jsके लिए अनुरोध करते समय, एचटीटीपी कैश मेमोरी की मदद ली जाएगी. यह विकल्प, Chrome 68 और उससे पहले के वर्शन में की गई सुविधा के हिसाब से काम करता है.अगर नीति को
'none'पर सेट किया जाता है, तो टॉप लेवल/service-worker.jsया इंपोर्ट की गई किसी स्क्रिप्ट, जैसे किpath/to/import.jsके लिए अनुरोध करते समय, एचटीटीपी कैश मेमोरी से मदद नहीं ली जाएगी.
उदाहरण के लिए, यह कोड सर्विस वर्कर को रजिस्टर करेगा. साथ ही, यह पक्का करेगा कि /service-worker.js स्क्रिप्ट या /service-worker.js में मौजूद importScripts() से रेफ़र की गई किसी भी स्क्रिप्ट के लिए अपडेट देखते समय एचटीटीपी कैश मेमोरी से सलाह कभी न ली जाए:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/service-worker.js', {
updateViaCache: 'none',
// Optionally, set 'scope' here, if needed.
});
}
इंपोर्ट की गई स्क्रिप्ट के अपडेट की जांच करता है
Chrome 78 से पहले, importScripts() से लोड की गई किसी भी सर्विस वर्कर स्क्रिप्ट को सिर्फ़ एक बार वापस लाया जाएगा (updateViaCache कॉन्फ़िगरेशन के आधार पर, एचटीटीपी कैश या नेटवर्क के ज़रिए जांच की जाएगी). पहली बार वापस पाने
के बाद, उसे ब्राउज़र में अंदरूनी तौर पर सेव किया जाएगा और उसे कभी फिर से फ़ेच नहीं किया जाएगा.
पहले से इंस्टॉल किए गए सर्विस वर्कर को इंपोर्ट की गई स्क्रिप्ट में बदलाव करने के लिए मजबूर करने का एक ही तरीका था. इसके लिए, स्क्रिप्ट का यूआरएल बदला जा सकता है. आम तौर पर, ऐसा सेमवर वैल्यू (जैसे, importScripts('https://example.com/v1.1.0/index.js')) जोड़कर या कॉन्टेंट का हैश (जैसे, importScripts('https://example.com/index.abcd1234.js')) शामिल करके किया जाता है. इंपोर्ट किए गए यूआरएल को बदलने का एक असर यह होता है कि टॉप-लेवल सर्विस वर्कर स्क्रिप्ट में बदलाव होता है.
Chrome 78 और उसके बाद के वर्शन में, जब भी किसी टॉप-लेवल की सर्विस वर्कर फ़ाइल के लिए अपडेट की जांच की जाती है, तो एक ही समय में जांच करके यह तय किया जाता है कि इंपोर्ट की गई स्क्रिप्ट के कॉन्टेंट में बदलाव हुआ है या नहीं. इस्तेमाल किए गए Cache-Control हेडर के आधार पर, अगर updateViaCache को 'all' या 'imports' (जो डिफ़ॉल्ट वैल्यू है) पर सेट किया गया हो, तो इंपोर्ट की गई स्क्रिप्ट की ये जांच एचटीटीपी कैश से पूरी हो सकती हैं. इसके अलावा, अगर updateViaCache को 'none' पर सेट किया गया है, तो जांच सीधे नेटवर्क से जुड़ी हो सकती है.
अगर इंपोर्ट की गई स्क्रिप्ट के लिए अपडेट की जांच करने पर, सर्विस वर्कर के सेव किए गए डेटा और बाइट के लिए बाइट का अंतर दिखता है, तो सर्विस वर्कर के अपडेट का फ़्लो ट्रिगर होगा. भले ही, टॉप लेवल सर्विस वर्कर फ़ाइल में कोई बदलाव न हो.
Chrome 78 का व्यवहार वही होता है जिसे Firefox ने कई साल पहले, Firefox 56 में लागू किया था. Safari पहले से ही इस व्यवहार को लागू करता है.
डेवलपर को क्या करना होगा?
अगर आपने अपनी /service-worker.js स्क्रिप्ट को Cache-Control: max-age=0 (या इससे मिलती-जुलती वैल्यू) के साथ दिखाकर, एचटीटीपी कैश मेमोरी से ऑप्ट-आउट कर लिया है, तो हो सकता है कि नए डिफ़ॉल्ट तरीके की वजह से आपको कोई बदलाव न दिखे.
अगर आपकी /service-worker.js स्क्रिप्ट को एचटीटीपी कैश मेमोरी में सेव करने की सुविधा चालू की गई है, तो जान-बूझकर या होस्टिंग एनवायरमेंट के लिए डिफ़ॉल्ट सेटिंग होने की वजह से, आपको अपने सर्वर से /service-worker.js के लिए किए गए अन्य एचटीटीपी अनुरोधों में बढ़ोतरी दिख सकती है. ये ऐसे अनुरोध होते हैं जिन्हें एचटीटीपी कैश मेमोरी से पूरा किया जाता था. अगर आपको Cache-Control हेडर वैल्यू को अपने /service-worker.js की फ़्रेशनेस को बनाए रखने की अनुमति देनी है, तो सर्विस वर्कर को रजिस्टर करते समय, आपको साफ़ तौर पर updateViaCache: 'all' सेट करना होगा.
ऐसा हो सकता है कि ब्राउज़र के पुराने वर्शन का इस्तेमाल करने वाले लोग, ब्राउज़र के पुराने वर्शन का इस्तेमाल कर रहे हों. इसलिए, सर्विस वर्कर स्क्रिप्ट पर Cache-Control: max-age=0 एचटीटीपी हेडर को सेट करते रहना बेहतर होगा. भले ही, नए ब्राउज़र उन्हें अनदेखा करें.
डेवलपर इस अवसर का इस्तेमाल यह तय करने के लिए कर सकते हैं कि क्या वे अपनी इंपोर्ट की गई स्क्रिप्ट को
खास तौर पर एचटीटीपी कैश मेमोरी से बाहर रखना चाहते हैं. साथ ही, अगर ज़रूरी हो, तो वे अपने सर्विस वर्कर रजिस्ट्रेशन में updateViaCache: 'none' को जोड़ सकते हैं.
इंपोर्ट की गई स्क्रिप्ट दिखाई जा रही हैं
Chrome 78 और इसके बाद के वर्शन में, importScripts() से लोड किए गए रिसॉर्स के लिए, डेवलपर को आने वाले ज़्यादा एचटीटीपी अनुरोध दिख सकते हैं. ऐसा इसलिए होगा, क्योंकि अब अपडेट के लिए उनकी जांच की जाएगी.
अगर आपको इस अतिरिक्त एचटीटीपी ट्रैफ़िक से बचना है, तो 'imports' के डिफ़ॉल्ट updateViaCache तरीके का इस्तेमाल करें. साथ ही, ऐसी स्क्रिप्ट देते समय Cache-Control हेडर सेट करें जो लंबे समय से चल रही हों. साथ ही, ऐसी स्क्रिप्ट देते समय Cache-Control हेडर सेट करें जिनके यूआरएल में सेवर या हैश शामिल हों.
इसके अलावा, अगर आप चाहते हैं कि इंपोर्ट की गई स्क्रिप्ट की बार-बार होने वाले अपडेट की जांच की जाए, तो उन्हें Cache-Control: max-age=0 के साथ इस्तेमाल करना न भूलें या updateViaCache: 'none' का इस्तेमाल करें.
इसके बारे में और पढ़ें
वेब पर कुछ भी डिप्लॉय करने वाले सभी डेवलपर को पढ़ने का सुझाव दिया जाता है. ये लेख, जेक आर्चीबाल्ड के "सर्विस वर्कर लाइफ़साइकल" और कैशिंग के सबसे सही तरीके और मैक्स-एज गॉचास" के बारे में दिए गए हैं.