ऐप्लिकेशन शेल आर्किटेक्चर के साथ झटपट लोड होने वाले वेब ऐप्लिकेशन

ऐप्लिकेशन शेल, यूज़र इंटरफ़ेस को चलाने के लिए ज़रूरी एचटीएमएल, सीएसएस, और JavaScript होता है. ऐप्लिकेशन शेल में ये चीज़ें होनी चाहिए:

• तेज़ी से लोड होना चाहिए
• कैश मेमोरी में सेव किया गया हो
• डाइनैमिक तौर पर कॉन्टेंट दिखाना

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

बैकग्राउंड

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

इन सुविधाओं का पूरा फ़ायदा पाने के लिए, हमें वेबसाइटों के बारे में नए तरीके से सोचने की ज़रूरत है: ऐप्लिकेशन शेल आर्किटेक्चर.

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

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

सर्विस वर्कर क्या होते हैं?

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

सामान्य ब्राउज़िंग कॉन्टेक्स्ट में JavaScript की तुलना में, सेवा वर्कर के पास भी एपीआई का सीमित सेट होता है. यह वेब पर वर्कर्स के लिए स्टैंडर्ड है. सेवा वर्कर, डीओएम को ऐक्सेस नहीं कर सकता. हालांकि, वह Cache API जैसी चीज़ों को ऐक्सेस कर सकता है. साथ ही, Fetch API का इस्तेमाल करके नेटवर्क अनुरोध कर सकता है. IndexedDB API और postMessage() का इस्तेमाल, डेटा को सेव रखने और सेवा वर्कर और उसके कंट्रोल वाले पेजों के बीच मैसेज भेजने के लिए भी किया जा सकता है. आपके सर्वर से भेजे गए पुश इवेंट, उपयोगकर्ता ऐक्टिविटी बढ़ाने के लिए Notification API को ट्रिगर कर सकते हैं.

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

सर्विस वर्कर के बारे में ज़्यादा जानने के लिए, सर्विस वर्कर के बारे में जानकारी लेख पढ़ें.

परफ़ॉर्मेंस के फ़ायदे

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

बार-बार आने पर, इससे आपको नेटवर्क के बिना स्क्रीन पर काम के पिक्सल मिल सकते हैं. भले ही, आपका कॉन्टेंट आखिर में वहां से ही आता हो. इसे इस तरह समझें कि टूलबार और कार्ड तुरंत दिखते हैं. इसके बाद, बाकी कॉन्टेंट धीरे-धीरे लोड होता है.

इस आर्किटेक्चर को असली डिवाइसों पर टेस्ट करने के लिए, हमने WebPageTest.org पर अपना ऐप्लिकेशन शेल सैंपल चलाया है. साथ ही, इसके नतीजे यहां दिखाए हैं.

पहला टेस्ट: Chrome Dev का इस्तेमाल करके, Nexus 5 के साथ केबल से कनेक्ट करके टेस्ट करना

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

दूसरा टेस्ट: Chrome Dev का इस्तेमाल करके, Nexus 5 पर 3G पर टेस्ट करना

हम अपने सैंपल की जांच, थोड़े धीमे 3G कनेक्शन से भी कर सकते हैं. इस बार, पहली विज़िट पर फ़र्स्ट मीनिंगफ़ुल पेंट में 2.5 सेकंड लगते हैं. पेज को पूरी तरह से लोड होने में 7.1 सेकंड लगते हैं. सेवा वर्कर कैश मेमोरी की मदद से, दोबारा विज़िट करने पर पेज तुरंत दिखने लगता है और 0.8 सेकंड में पूरी तरह से लोड हो जाता है.

अन्य व्यू से भी यही जानकारी मिलती है. ऐप्लिकेशन शेल में फ़र्स्ट मीनिंगफ़ुल पेंट को पूरा होने में लगने वाले तीन सेकंड की तुलना करें:

से 0.9 सेकंड में लोड हो जाता है. इससे हमारे असली उपयोगकर्ताओं को दो सेकंड से ज़्यादा का समय बचता है.

ऐप्लिकेशन शेल आर्किटेक्चर का इस्तेमाल करके, अपने ऐप्लिकेशन के लिए भी ऐसी ही और भरोसेमंद परफ़ॉर्मेंस हासिल की जा सकती है.

क्या सेवा वर्कर की वजह से, हमें ऐप्लिकेशन के स्ट्रक्चर के बारे में फिर से सोचना होगा?

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

इस बंटवारे के कई असर हैं. पहली विज़िट पर, सर्वर पर कॉन्टेंट रेंडर किया जा सकता है और क्लाइंट पर सेवा वर्कर इंस्टॉल किया जा सकता है. इसके बाद, आपको सिर्फ़ डेटा का अनुरोध करना होगा.

प्रोग्रेसिव एन्हैंसमेंट के बारे में क्या जानकारी है?

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

यहां Chrome, Firefox Nightly, और Safari में रेंडर किया गया पूरा वर्शन देखा जा सकता है. सबसे बाईं ओर, Safari का वह वर्शन दिखता है जिसमें कॉन्टेंट को सर्वर पर, सेवा वर्कर के बिना रेंडर किया जाता है. दाईं ओर, हमें Chrome और Firefox के Nightly वर्शन दिख रहे हैं. ये वर्शन, सेवा वर्कर की मदद से काम करते हैं.

इस आर्किटेक्चर का इस्तेमाल कब करना चाहिए?

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

क्या इस पैटर्न का इस्तेमाल करने वाले कोई प्रोडक्शन ऐप्लिकेशन मौजूद हैं?

ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) में कुछ बदलाव करके, ऐप्लिकेशन शेल आर्किटेक्चर बनाया जा सकता है. यह बड़े पैमाने पर साइटों के लिए अच्छा काम करता है. जैसे, Google का I/O 2015 प्रोग्रेसिव वेब ऐप्लिकेशन और Google का Inbox.

ऑफ़लाइन ऐप्लिकेशन शेल, परफ़ॉर्मेंस को बेहतर बनाने में काफ़ी मददगार होते हैं. इनका इस्तेमाल, जैक आर्किबाल्ड के ऑफ़लाइन Wikipedia ऐप्लिकेशन और Flipkart Lite के प्रगतिशील वेब ऐप्लिकेशन में भी किया गया है.

आर्किटेक्चर के बारे में जानकारी

पहली बार लोड होने के दौरान, आपका लक्ष्य उपयोगकर्ता की स्क्रीन पर काम का कॉन्टेंट जल्द से जल्द दिखाना होता है.

पहला लोड और अन्य पेजों को लोड करना

आम तौर पर, ऐप्लिकेशन शेल आर्किटेक्चर में ये चीज़ें होंगी:

• शुरुआती लोड को प्राथमिकता दें, लेकिन सेवा वर्कर को ऐप्लिकेशन शेल को कैश मेमोरी में सेव करने दें, ताकि बार-बार आने पर शेल को नेटवर्क से फिर से फ़ेच न करना पड़े.

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

• sw-precache जैसे सेवा वर्कर टूल का इस्तेमाल करें. उदाहरण के लिए, अपने स्टैटिक कॉन्टेंट को मैनेज करने वाले सेवा वर्कर को भरोसेमंद तरीके से कैश मेमोरी में सेव और अपडेट करने के लिए. (sw-precache के बारे में ज़्यादा जानकारी बाद में दी जाएगी.)

ऐसा करने के लिए:

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

• पेज में, दस्तावेज़ <head> में <style> टैग में इनलाइन सीएसएस स्टाइल शामिल होंगे, ताकि ऐप्लिकेशन शेल को तेज़ी से पेंट किया जा सके. हर पेज, मौजूदा व्यू के लिए ज़रूरी JavaScript को एसिंक्रोनस तरीके से लोड करेगा. सीएसएस को एसिंक्रोनस तरीके से लोड नहीं किया जा सकता. इसलिए, हम JavaScript का इस्तेमाल करके स्टाइल का अनुरोध कर सकते हैं, क्योंकि यह पार्स करने वाले और सिंक्रोनस के बजाय एसिंक्रोनस है. हम requestAnimationFrame() का फ़ायदा भी ले सकते हैं, ताकि ऐसे मामलों से बचा जा सके जहां हमें तेज़ी से कैश हिट मिल सकता है और स्टाइल गलती से क्रिटिकल रेंडरिंग पाथ का हिस्सा बन सकती हैं. requestAnimationFrame(), स्टाइल लोड होने से पहले पहले फ़्रेम को पेंट करने के लिए मजबूर करता है. JavaScript का इस्तेमाल करके, एसिंक्रोनस तरीके से सीएसएस का अनुरोध करने के लिए, Filament Group के loadCSS जैसे प्रोजेक्ट का इस्तेमाल किया जा सकता है.

• सर्विस वर्क, ऐप्लिकेशन शेल की कैश मेमोरी में सेव की गई एंट्री को सेव करेगा, ताकि बार-बार विज़िट करने पर, शेल को पूरी तरह से सेवा वर्क कैश मेमोरी से लोड किया जा सके. ऐसा तब तक किया जा सकता है, जब तक नेटवर्क पर कोई अपडेट उपलब्ध न हो.

लागू करने का तरीका

हमने ऐप्लिकेशन शेल आर्किटेक्चर का इस्तेमाल करके, क्लाइंट के लिए वैनिला ES2015 JavaScript और सर्वर के लिए Express.js का इस्तेमाल करके, पूरी तरह से काम करने वाला सैंपल लिखा है. हालांकि, क्लाइंट या सर्वर के हिस्सों (जैसे, PHP, Ruby, Python) के लिए, अपने स्टैक का इस्तेमाल करने से कोई नहीं रोकता.

सर्विस वर्कर का लाइफ़साइकल

अपने ऐप्लिकेशन शेल प्रोजेक्ट के लिए, हम sw-precache का इस्तेमाल करते हैं. इससे, सेवा वर्कर का यह लाइफ़साइकल मिलता है:

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

सर्वर बिट

इस आर्किटेक्चर में, सर्वर साइड कॉम्पोनेंट (हमारे मामले में, Express में लिखा गया) को कॉन्टेंट और प्रज़ेंटेशन को अलग-अलग तरीके से दिखाना चाहिए. कॉन्टेंट को किसी ऐसे एचटीएमएल लेआउट में जोड़ा जा सकता है जिससे पेज का स्टैटिक रेंडर होता है. इसके अलावा, कॉन्टेंट को अलग से दिखाया जा सकता है और डाइनैमिक तरीके से लोड किया जा सकता है.

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

• एंडपॉइंट, आपके ऐप्लिकेशन के तीन हिस्सों के लिए तय किए जाते हैं: उपयोगकर्ता को दिखने वाले यूआरएल (इंडेक्स/वाइल्डकार्ड), ऐप्लिकेशन शेल (सर्विस वर्कर्स) और आपके एचटीएमएल पार्टल.

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

• उपयोगकर्ता को शुरुआत में कॉन्टेंट वाला स्टैटिक पेज दिखाया जाता है. अगर सर्विस वर्कर काम करता है, तो यह पेज उसे रजिस्टर करता है. यह सर्विस वर्कर, ऐप्लिकेशन शेल और उससे जुड़ी सभी चीज़ों (सीएसएस, JS वगैरह) को कैश मेमोरी में सेव करता है.

• इसके बाद, ऐप्लिकेशन शेल एक पेज वाले वेब ऐप्लिकेशन के तौर पर काम करेगा. इसमें किसी खास यूआरएल के कॉन्टेंट में XHR करने के लिए, JavaScript का इस्तेमाल किया जाएगा. XHR कॉल, /partials* एंडपॉइंट पर किए जाते हैं. यह एंडपॉइंट, उस कॉन्टेंट को दिखाने के लिए ज़रूरी एचटीएमएल, सीएसएस, और JS का छोटा हिस्सा दिखाता है. ध्यान दें: इस काम को करने के कई तरीके हैं और XHR उनमें से एक है. कुछ ऐप्लिकेशन, शुरुआती रेंडर के लिए अपने डेटा को इनलाइन करेंगे. ऐसा शायद JSON का इस्तेमाल करके किया जाएगा. इसलिए, ये ऐप्लिकेशन, फ़्लैट किए गए एचटीएमएल के हिसाब से "स्टैटिक" नहीं हैं.

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

फ़ाइल का वर्शन

एक सवाल यह उठता है कि फ़ाइल के वर्शन और अपडेट को कैसे मैनेज किया जाए. यह ऐप्लिकेशन के हिसाब से तय होता है. इसके लिए, ये विकल्प उपलब्ध हैं:

• नेटवर्क से डाउनलोड करें. अगर नेटवर्क उपलब्ध नहीं है, तो कैश मेमोरी में सेव किए गए वर्शन का इस्तेमाल करें.

• सिर्फ़ नेटवर्क पर काम करता है और ऑफ़लाइन होने पर काम नहीं करता.

• पुराने वर्शन को कैश मेमोरी में सेव करें और बाद में अपडेट करें.

ऐप्लिकेशन शेल के लिए, सेवा वर्कर सेटअप करते समय कैश मेमोरी का इस्तेमाल करना चाहिए. अगर ऐप्लिकेशन शेल को कैश मेमोरी में सेव नहीं किया जा रहा है, तो इसका मतलब है कि आपने आर्किटेक्चर को सही तरीके से अपनाया नहीं है.

टूलिंग

हम कई अलग-अलग सेवा वर्कर हेल्पर लाइब्रेरी मैनेज करते हैं. इनकी मदद से, आपके ऐप्लिकेशन के शेल को पहले से कैश मेमोरी में सेव करने या कैश मेमोरी में डेटा सेव करने के सामान्य पैटर्न को सेटअप करने की प्रोसेस आसान हो जाती है.

अपने ऐप्लिकेशन के शेल के लिए sw-precache का इस्तेमाल करना

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

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

रनटाइम कैश मेमोरी में सेव करने के लिए, sw-toolbox का इस्तेमाल करना

रिसॉर्स के हिसाब से अलग-अलग रणनीतियों के साथ, रनटाइम कैश मेमोरी के लिए sw-toolbox का इस्तेमाल करें:

• इमेज के लिए cacheFirst के साथ-साथ, एक खास कैश मेमोरी, जिसमें N maxEntries की कस्टम समयसीमा खत्म होने की नीति है.

• कॉन्टेंट के अपडेट होने की फ़्रीक्वेंसी के हिसाब से, एपीआई अनुरोधों के लिए networkFirst या सबसे तेज़. सबसे तेज़ विकल्प का इस्तेमाल किया जा सकता है. हालांकि, अगर कोई ऐसा खास एपीआई फ़ीड है जिसे अक्सर अपडेट किया जाता है, तो networkFirst का इस्तेमाल करें.

नतीजा

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

अपने प्रयोगों में, हमने क्लाइंट और सर्वर के बीच टेंप्लेट शेयर करने का फ़ायदा उठाया, ताकि दो ऐप्लिकेशन लेयर बनाने के काम को कम किया जा सके. इससे यह पक्का होता है कि प्रगतिशील बेहतर बनाने की सुविधा अब भी मुख्य सुविधा है.

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

समीक्षा करने वाले लोगों को धन्यवाद: जेफ़ पॉस्निक, पॉल लुइस, ऐलेक्स रसेल, सेथ थॉम्पसन, रॉब डॉडसन, टेलर सैवेज, और जो मेडली.