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

एडी उस्मान
एडी उस्मानी
मैट गौंट

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

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

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

एचटीएमएल, JS, और सीएसएस शेल और एचटीएमएल कॉन्टेंट का ऐप्लिकेशन शेल सेपरेशन

बैकग्राउंड

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

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

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

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

ऐप्लिकेशन शेल के लिए DevTools में चल रहे सर्विस वर्कर की इमेज

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

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

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

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

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

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

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

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

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

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

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

केबल कनेक्शन के लिए वेब पेज टेस्ट पेंट डायग्राम

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

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

3G कनेक्शन के लिए वेब पेज टेस्ट पेंट डायग्राम

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

वेब पेज टेस्ट से पहले व्यू के लिए टाइमलाइन पेंट करें

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

वेब पेज टेस्ट से, दोहराए जाने वाले व्यू के लिए टाइमलाइन पेंट करें

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

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

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

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

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

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

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

Safari, Chrome, और Firefox में लोड किए गए ऐप्लिकेशन शेल की इमेज

इस आर्किटेक्चर का इस्तेमाल कब किया जा सकता है?

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

क्या अभी तक कोई प्रोडक्शन ऐप्लिकेशन इस पैटर्न का इस्तेमाल कर रहा है?

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

Google इनबॉक्स के लोड होने की इमेज. सर्विस वर्कर का इस्तेमाल करके इनबॉक्स को दिखाता है.

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

Wikipedia के जेक आर्किबाल्ड के डेमो के स्क्रीनशॉट.

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

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

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

ऐप्लिकेशन शेल की मदद से पहली बार लोड करने का डायग्राम

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

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

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

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

इसके लिए:

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

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

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

कॉन्टेंट के लिए ऐप्लिकेशन शेल

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

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

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

हमारे ऐप्लिकेशन शेल प्रोजेक्ट के लिए, हम sw-precache का इस्तेमाल करते हैं, जो नीचे दी गई सर्विस वर्कर लाइफ़साइकल देता है:

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

सर्वर बिट

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

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

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

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

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

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

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

फ़ाइल को अलग-अलग वर्शन में बदलना

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

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

  • केवल नेटवर्क और ऑफ़लाइन होने पर विफल.

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

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

टूलिंग

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

वेब की बुनियादी बातों पर सर्विस वर्कर लाइब्रेरी साइट का स्क्रीनशॉट

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

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

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

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

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

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

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

नतीजा

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

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

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

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