सिंगल पेज वेब ऐप्लिकेशन (एसपीए) की एक सामान्य आर्किटेक्चरल सुविधा, किसी ऐप्लिकेशन के ग्लोबल फ़ंक्शन को बेहतर बनाने के लिए ज़रूरी एचटीएमएल, सीएसएस, और JavaScript का कम से कम सेट है. असल में, यह हेडर, नेविगेशन, और अन्य सामान्य यूज़र इंटरफ़ेस एलिमेंट की तरह होता है, जो सभी पेजों पर मौजूद रहता है. जब कोई सर्विस वर्कर, इस सामान्य यूज़र इंटरफ़ेस (यूआई) के एचटीएमएल और डिपेंडेंट ऐसेट को प्रीकैश करता है, तो हम इसे ऐप्लिकेशन शेल कहते हैं.
किसी वेब ऐप्लिकेशन के अनुमानित परफ़ॉर्मेंस में ऐप्लिकेशन शेल अहम भूमिका निभाता है. कॉन्टेंट के यूज़र इंटरफ़ेस में अपने-आप जानकारी भरने के दौरान, लोगों को सबसे पहले यही पेज लोड होता है.
हालांकि ऐप्लिकेशन शेल तेज़ी से लोड होता है—बशर्ते नेटवर्क उपलब्ध हो और यह कुछ हद तक तेज़ हो. यह सर्विस वर्कर ऐप्लिकेशन शेल को पहले से कैश मेमोरी में सेव करता है और इससे जुड़ी एसेट, ऐप्लिकेशन शेल मॉडल को ये अतिरिक्त फ़ायदे देती हैं:
- वेबसाइट पर बार-बार आने वाले लोगों की परफ़ॉर्मेंस पर भरोसा और एक जैसी परफ़ॉर्मेंस हो. सर्विस वर्कर के इंस्टॉल न होने पर, किसी ऐप्लिकेशन पर पहली बार जाने पर, सर्विस वर्कर को कैश मेमोरी में रखने से पहले, ऐप्लिकेशन के मार्कअप और उससे जुड़ी एसेट को नेटवर्क से लोड करना पड़ता है. हालांकि, बार-बार विज़िट करने पर कैश मेमोरी से ऐप्लिकेशन शेल मिलेगा. इसका मतलब है कि साइट का कॉन्टेंट तुरंत लोड और रेंडर हो जाएगा.
- ऑफ़लाइन स्थितियों में फ़ंक्शन का भरोसेमंद ऐक्सेस. कभी-कभी इंटरनेट का सही से ऐक्सेस नहीं होता या बिलकुल इंटरनेट नहीं होता और एक डरावना "हमें वह वेबसाइट नहीं मिल रही" स्क्रीन पीछे की ओर होती है. ऐप्लिकेशन शेल मॉडल, कैश मेमोरी से ऐप्लिकेशन शेल मार्कअप के साथ किसी भी नेविगेशन अनुरोध का जवाब देकर इसे पूरा करता है. अगर कोई व्यक्ति आपके वेब ऐप्लिकेशन में किसी ऐसे यूआरएल पर जाता है जहां वे पहले कभी नहीं गए थे, तब भी ऐप्लिकेशन शेल को कैश मेमोरी से भेजा जाएगा और उसे उपयोगी कॉन्टेंट से भरा जा सकता है.
ऐप्लिकेशन शेल मॉडल का इस्तेमाल कब किया जाना चाहिए
ऐप्लिकेशन शेल तब सबसे ज़्यादा कारगर साबित होता है, जब आपके पास ऐसे सामान्य यूज़र इंटरफ़ेस एलिमेंट होते हैं जो एक रूट से दूसरे रूट पर नहीं बदलते, लेकिन कॉन्टेंट में बदलाव होता है. ज़्यादातर एसपीए, ऐप्लिकेशन शेल मॉडल का इस्तेमाल करते हैं.
अगर यह आपके प्रोजेक्ट के बारे में बताती है और उसकी विश्वसनीयता और परफ़ॉर्मेंस को बेहतर बनाने के लिए किसी सर्विस वर्कर को जोड़ना है, तो ऐप्लिकेशन शेल को:
- तेज़ी से लोड करें.
Cache
इंस्टेंस से स्टैटिक ऐसेट का इस्तेमाल करें.- इसमें पेज के कॉन्टेंट से अलग, हेडर और साइडबार जैसे सामान्य इंटरफ़ेस एलिमेंट शामिल होते हैं.
- पेज-विशिष्ट सामग्री पुनर्प्राप्त करें और दिखाएं.
- अगर सही हो, तो ऑफ़लाइन देखने के लिए डाइनैमिक कॉन्टेंट को कैश मेमोरी में सेव करें. हालांकि, ऐसा करना ज़रूरी नहीं है.
ऐप्लिकेशन शेल, एपीआई या JavaScript में बंडल किए गए कॉन्टेंट की मदद से, पेज के हिसाब से खास कॉन्टेंट को डाइनैमिक तरीके से लोड करता है. इसे इस तरह से खुद अपडेट भी किया जाना चाहिए कि अगर ऐप्लिकेशन शेल के मार्कअप में बदलाव होता है, तो सर्विस वर्कर अपडेट को नया ऐप्लिकेशन शेल चुनना चाहिए और उसे अपने-आप कैश मेमोरी में सेव करना चाहिए.
ऐप्लिकेशन शेल बनाना
ऐप्लिकेशन शेल, कॉन्टेंट से अलग होना चाहिए. इसके बावजूद, उसमें कॉन्टेंट अपने-आप भरे जाने के लिए बेस उपलब्ध कराना चाहिए. आम तौर पर, इसे छोटा होना चाहिए. हालांकि, डाउनलोड करते समय ज़रूरत के मुताबिक कॉन्टेंट ऐसा होना चाहिए जिससे उपयोगकर्ता यह समझ सके कि अनुभव तेज़ी से लोड हो रहा है.
सही बैलेंस आपके ऐप्लिकेशन पर निर्भर करता है. जेक आर्चिबाल्ड के Trained to Thrill ऐप्लिकेशन के ऐप्लिकेशन शेल में एक हेडर मौजूद होता है. इस पर रीफ़्रेश बटन भी होता है, ताकि Flickr से नया कॉन्टेंट लाया जा सके.
ऐप्लिकेशन शेल मार्कअप हर प्रोजेक्ट के लिए अलग-अलग होता है. हालांकि, यहां ऐसी index.html
फ़ाइल का उदाहरण दिया गया है जो ऐप्लिकेशन बॉयलरप्लेट उपलब्ध कराती है:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>
Application Shell Example
</title>
<link rel="manifest" href="/manifest.json">
<meta name="viewport" content="width=device-width,initial-scale=1.0">
<link rel="stylesheet" type="text/css" href="styles/global.css">
</head>
<body>
<header class="header">
<!-- Application header -->
<h1 class="header__title">Application Shell Example</h1>
</header>
<nav class="nav">
<!-- Navigation items -->
</nav>
<main id="app">
<!-- Where the application content populates -->
</main>
<div class="loader">
<!-- Spinner/content placeholders -->
</div>
<!-- Critical application shell logic -->
<script src="app.js"></script>
<!-- Service worker registration script -->
<script>
if ('serviceWorker' in navigator) {
// Register a service worker after the load event
window.addEventListener('load', () => {
navigator.serviceWorker.register('/sw.js');
});
}
</script>
</body>
</html>
अगर आपने अपने प्रोजेक्ट के लिए ऐप्लिकेशन शेल बनाया है, तो उसकी ये विशेषताएं होनी चाहिए:
- एचटीएमएल में यूज़र इंटरफ़ेस के अलग-अलग एलिमेंट के लिए एरिया साफ़ तौर पर अलग-अलग होने चाहिए. ऊपर दिए गए उदाहरण में, ऐप्लिकेशन का हेडर, नेविगेशन, मुख्य कॉन्टेंट एरिया, और लोड होने वाले "स्पिनर" के लिए स्पेस शामिल है जो तब ही दिखते हैं, जब कॉन्टेंट लोड हो रहा हो.
- ऐप्लिकेशन शेल के लिए लोड किया गया शुरुआती JavaScript और CSS न्यूनतम होना चाहिए और केवल ऐप्लिकेशन शेल की कार्यक्षमता से संबंधित होना चाहिए, न कि सामग्री से. यह पक्का करता है कि ऐप्लिकेशन अपने शेल को जल्द से जल्द रेंडर करता है. साथ ही, मुख्य थ्रेड का काम तब तक कम करता है, जब तक कॉन्टेंट नहीं दिखता.
- सर्विस वर्कर को रजिस्टर करने वाली इनलाइन स्क्रिप्ट.
ऐप्लिकेशन शेल बन जाने के बाद, आप उसे और उसकी एसेट, दोनों को कैश करने के लिए सर्विस वर्कर बना सकते हैं.
ऐप्लिकेशन शेल को कैश मेमोरी में सेव करना
ऐप्लिकेशन शेल और इसकी ज़रूरी ऐसेट, सर्विस वर्कर को इंस्टॉल के समय तुरंत पहले से कैश मेमोरी में सेव होनी चाहिए. मान लें कि ऊपर दिए गए उदाहरण की तरह एक ऐप्लिकेशन शेल है, तो आइए देखते हैं कि workbox-build
का इस्तेमाल करके कोई बुनियादी Workbox उदाहरण में इसे कैसे पूरा कर सकता है:
// build-sw.js
import {generateSW} from 'workbox-build';
// Where the generated service worker will be written to:
const swDest = './dist/sw.js';
generateSW({
swDest,
globDirectory: './dist',
globPatterns: [
// The necessary CSS and JS for the app shell
'**/*.js',
'**/*.css',
// The app shell itself
'shell.html'
],
// All navigations for URLs not precached will use this HTML
navigateFallback: 'shell.html'
}).then(({count, size}) => {
console.log(`Generated ${swDest}, which precaches ${count} assets totaling ${size} bytes.`);
});
build-sw.js
में सेव किया गया यह कॉन्फ़िगरेशन, ऐप्लिकेशन की सीएसएस और JavaScript को इंपोर्ट करता है. इसमें shell.html
में मौजूद ऐप्लिकेशन शेल मार्कअप फ़ाइल भी शामिल है. स्क्रिप्ट को नोड का इस्तेमाल करके इस तरह एक्ज़ीक्यूट किया जाता है:
node build-sw.js
जनरेट किया गया सर्विस वर्कर, ./dist/sw.js
पर लिखा जाता है. काम पूरा होने पर, इस मैसेज को लॉग किया जाएगा:
Generated ./dist/sw.js, which precaches 5 assets totaling 44375 bytes.
पेज लोड होने पर, सर्विस वर्कर, ऐप्लिकेशन शेल मार्कअप और इसकी डिपेंडेंसी को पहले से कैश मेमोरी में सेव करता है:
बंडलर का इस्तेमाल करने वाले प्रोजेक्ट सहित करीब-करीब हर वर्कफ़्लो में अपने ऐप्लिकेशन शेल के एचटीएमएल, सीएसएस, और JavaScript को सुरक्षित किया जा सकता है. दस्तावेज़ में आगे बढ़ने पर, आपको पता चलेगा कि सीधे तौर पर अपने टूलचेन को सेट अप करने के लिए, Workbox का इस्तेमाल कैसे किया जाए, ताकि आपके प्रोजेक्ट के लिए सबसे सही सर्विस वर्कर बनाया जा सके. भले ही, यह एसपीए फ़ॉर्मैट में काम करता हो या नहीं.
नतीजा
ऐप्लिकेशन शेल मॉडल को सर्विस वर्कर के साथ जोड़ना, ऑफ़लाइन कैशिंग के लिए बहुत अच्छा है. खास तौर पर तब, जब आप मार्कअप या एपीआई रिस्पॉन्स के लिए, पहले से कैश मेमोरी में सेव करने की सुविधा को नेटवर्क को प्राथमिकता देने वाले, कैश मेमोरी की रणनीति पर वापस जाने के साथ जोड़ते हों. इसका नतीजा काफ़ी तेज़ी से मिलता है, जो बार-बार विज़िट करने पर आपके ऐप्लिकेशन शेल को तुरंत रेंडर कर देता है, भले ही वह ऑफ़लाइन होने की स्थिति में क्यों न हो.