सिंगल पेज वेब ऐप्लिकेशन (एसपीए) की सामान्य आर्किटेक्चरल सुविधा, एचटीएमएल, सीएसएस, और JavaScript का कम से कम सेट है, जो किसी ऐप्लिकेशन की ग्लोबल सुविधाओं को बेहतर बनाने के लिए ज़रूरी है. व्यावहारिक तौर पर, यह हेडर, नेविगेशन, और यूज़र इंटरफ़ेस के दूसरे सामान्य एलिमेंट होते हैं, जो सभी पेजों पर मौजूद रहते हैं. जब कोई सर्विस वर्कर, कम से कम यूज़र इंटरफ़ेस (यूआई) के एचटीएमएल और डिपेंडेंट ऐसेट को प्री-कैश करता है, तो हम इसे ऐप्लिकेशन शेल कहते हैं.
ऐप्लिकेशन शेल, किसी वेब ऐप्लिकेशन की अनुमानित परफ़ॉर्मेंस में अहम भूमिका निभाता है. यह सबसे पहले लोड होता है. इसलिए, यूज़र इंटरफ़ेस में कॉन्टेंट दिखने का इंतज़ार करते समय, लोगों को सबसे पहले यही दिखता है.
जबकि ऐप्लिकेशन शेल तेज़ी से लोड होता है—इसके अलावा, नेटवर्क उपलब्ध होने पर और कम से कम थोड़ा तेज़ होने की ज़रूरत होती है—एक सर्विस वर्कर जो ऐप्लिकेशन शेल को पहले से कैश मेमोरी में सेव करता है और इससे जुड़ी एसेट, ऐप्लिकेशन शेल मॉडल को ये अतिरिक्त फ़ायदे देती हैं:
- बार-बार होने वाली विज़िट पर, भरोसेमंद और एक जैसा परफ़ॉर्मेंस. बिना सर्विस वर्कर के किसी ऐप्लिकेशन पर पहली बार जाने पर, सर्विस वर्कर के इन मार्कअप को कैश मेमोरी में रखने से पहले, इसका मार्कअप और उससे जुड़ी एसेट नेटवर्क से लोड होनी चाहिए. हालांकि, बार-बार होने वाली विज़िट, कैश मेमोरी से ऐप्लिकेशन शेल ले लेगी. इसका मतलब है कि लोड और रेंडरिंग तुरंत हो जाएगी.
- ऑफ़लाइन होने पर फ़ंक्शन का भरोसेमंद ऐक्सेस. कभी-कभी इंटरनेट ऐक्सेस नहीं होता है या पूरी तरह से उपलब्ध नहीं होता है, और "हमें वह वेबसाइट नहीं मिली" जैसी ख़ौफ़नाक स्क्रीन पर लोगों का सिर चकरा जाता है. ऐप्लिकेशन शेल मॉडल, कैश से ऐप्लिकेशन शेल मार्कअप की मदद से किसी भी नेविगेशन अनुरोध का जवाब देकर, इस समस्या को ठीक करता है. यहां तक कि अगर कोई व्यक्ति आपके वेब ऐप्लिकेशन में किसी ऐसे यूआरएल पर जाता है जो वह पहले कभी नहीं गया है, तो भी ऐप्लिकेशन शेल कैश मेमोरी से उपलब्ध कराया जाएगा और इसे उपयोगी कॉन्टेंट से भरा जा सकता है.
ऐप्लिकेशन शेल मॉडल का इस्तेमाल कब किया जाना चाहिए
आपके पास ऐसे सामान्य यूज़र इंटरफ़ेस एलिमेंट होने पर ऐप्लिकेशन शेल सबसे ज़्यादा फ़ायदेमंद साबित होता है जो रूट से रूट में नहीं बदलते, लेकिन कॉन्टेंट में बदलाव होते हैं. ज़्यादातर एसपीए, आम तौर पर उसी का इस्तेमाल करते हैं जो ऐप्लिकेशन शेल मॉडल पहले से लागू है.
अगर इससे आपके प्रोजेक्ट के बारे में जानकारी मिलती है और आपको किसी सर्विस वर्कर की विश्वसनीयता और परफ़ॉर्मेंस को बेहतर करने के लिए उसे जोड़ना है, तो ऐप्लिकेशन शेल में:
- तेज़ी से लोड करें.
Cache
इंस्टेंस की स्टैटिक ऐसेट का इस्तेमाल करें.- पेज के कॉन्टेंट से अलग, हेडर और साइडबार जैसे सामान्य इंटरफ़ेस एलिमेंट शामिल करें.
- पेज-विशिष्ट सामग्री वापस पाएं और दिखाएं.
- अगर ज़रूरी हो, तो ऑफ़लाइन कॉन्टेंट को कैश मेमोरी में सेव करने का विकल्प इस्तेमाल किया जा सकता है.
ऐप्लिकेशन शेल, API या 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
का इस्तेमाल करके बुनियादी वर्कबॉक्स उदाहरण में इसे कैसे पूरा किया जा सकता है:
// 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.
पेज लोड होने पर, सर्विस वर्कर ऐप्लिकेशन शेल मार्कअप और इसकी डिपेंडेंसी को पहले से कैश मेमोरी में सेव करता है:
![Chrome के DevTools में मौजूद नेटवर्क पैनल का स्क्रीनशॉट, जिसमें नेटवर्क से डाउनलोड की गई ऐसेट की सूची दिख रही है. सर्विस वर्कर की ओर से पहले से कैश की गई एसेट, पंक्ति में बाईं ओर मौजूद कोग वाली दूसरी एसेट से अलग होती हैं. इंस्टॉल के समय सर्विस वर्कर, कई JavaScript और सीएसएस फ़ाइलों को पहले से कैश मेमोरी में सेव करता है.](https://developer.chrome.google.cn/static/docs/workbox/app-shell-model/image/a-screenshot-the-network-96ad6896c678b.png?authuser=8&hl=hi)
बंडलर का इस्तेमाल करने वाले प्रोजेक्ट के साथ-साथ, करीब-करीब किसी भी वर्कफ़्लो में अपने ऐप्लिकेशन शेल के एचटीएमएल, सीएसएस, और JavaScript को प्री-कैश किया जा सकता है. दस्तावेज़ देखते समय, आपको यह सीखने को मिलेगा कि सीधे तौर पर Workbox का इस्तेमाल करके, अपने टूलचेन को कैसे सेट अप किया जा सकता है, ताकि आपके प्रोजेक्ट के लिए सबसे अच्छा सर्विस वर्कर बनाया जा सके. भले ही, वह एसपीए हो.
नतीजा
ऐप्लिकेशन शेल मॉडल को सर्विस वर्कर के साथ जोड़ना, ऑफ़लाइन कैश मेमोरी के लिए बहुत अच्छा होता है. खास तौर पर तब, जब आप इसकी प्री-कैशिंग सुविधा को कैश मेमोरी में वापस जाने वाली रणनीति के साथ मार्कअप या एपीआई रिस्पॉन्स के साथ जोड़ते हों. इससे आपको तेज़ी से और भरोसेमंद तरीके से ऐप्लिकेशन का शेल मिलता है, जो ऑफ़लाइन मोड में भी ऐप्लिकेशन को बार-बार देखने पर तुरंत आपके ऐप्लिकेशन शेल को रेंडर करता है.