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

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

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

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

बैकग्राउंड

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

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

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

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

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

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

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

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

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

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

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

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

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

पहला टेस्ट: Chrome Dev का इस्तेमाल करके, Nexus 5 की मदद से केबल की जांच करना

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

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

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

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

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

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

क्या सर्विस वर्कर के लिए हमें ऐप्लिकेशन को स्ट्रक्चर करने के अपने तरीके के बारे में दोबारा सोचने की ज़रूरत है?

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

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

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

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

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

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

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

क्या प्रोडक्शन से जुड़े किसी ऐप्लिकेशन में अब तक इस पैटर्न का इस्तेमाल किया जा रहा है?

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

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

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

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

सबसे पहले दूसरे पेजों को लोड करना और उन्हें लोड करना

सामान्य तौर पर ऐप्लिकेशन शेल आर्किटेक्चर:

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

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

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

इसके लिए:

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

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

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

व्यावहारिक तौर पर लागू करना

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

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

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

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

सर्वर बिट

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

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

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

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

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

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

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

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

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

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

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

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

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

टूलिंग

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

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

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

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

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

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

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

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

नतीजा

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

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

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

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