प्रीफ़ेच करना, पहले से रेंडर करना, और सर्विस वर्कर प्रीकैशिंग

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

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

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

आने वाले समय में, ज़रूरी संसाधनों को कम प्राथमिकता पर प्रीफ़ेच करें

हो सकता है कि <link rel="prefetch"> रिसॉर्स संकेत का इस्तेमाल करके, रिसॉर्स को पहले से ही फ़ेच किया जा सके. इनमें इमेज, स्टाइलशीट या JavaScript रिसॉर्स शामिल हैं. prefetch संकेत, ब्राउज़र को यह बताता है कि आने वाले समय में संसाधन की ज़रूरत पड़ सकती है.

जब prefetch संकेत दिया जाता है, तब ब्राउज़र सबसे कम प्राथमिकता पर उस संसाधन के लिए अनुरोध कर सकता है, ताकि मौजूदा पेज के लिए ज़रूरी संसाधनों के साथ मुकाबला करने से बचा जा सके.

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

<head>
  <!-- ... -->
  <link rel="prefetch" as="script" href="/date-picker.js">
  <link rel="prefetch" as="style" href="/date-picker.css">
  <!-- ... -->
</head>

पिछला एचटीएमएल स्निपेट, ब्राउज़र को बताता है कि कुछ समय के लिए इस्तेमाल न होने पर, date-picker.js और date-picker.css को प्रीफ़ेच किया जा सकता है. अगर उपयोगकर्ता, JavaScript में पेज से इंटरैक्ट करता है, तो संसाधन को डाइनैमिक तौर पर प्रीफ़ेच भी किया जा सकता है.

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

आने वाले समय में नेविगेशन तेज़ी से करने के लिए, पेजों को प्रीफ़ेच करें

किसी पेज और उसके सभी सबरिसॉर्स को एचटीएमएल दस्तावेज़ के तौर पर ले जाते समय as="document" एट्रिब्यूट के बारे में बताकर, उसे प्रीफ़ेच किया जा सकता है:

<link rel="prefetch" href="/page" as="document">

अगर ब्राउज़र कुछ समय से इस्तेमाल में नहीं है, तो हो सकता है कि यह /page के लिए कम प्राथमिकता वाला अनुरोध भेजे.

Chromium पर काम करने वाले ब्राउज़र में, अनुमान नियम एपीआई का इस्तेमाल करके दस्तावेज़ों को प्रीफ़ेच किया जा सकता है. अनुमान के नियम, पेज के एचटीएमएल में शामिल JSON ऑब्जेक्ट या JavaScript के ज़रिए डाइनैमिक तरीके से जोड़े जाते हैं:

<script type="speculationrules">
{
  "prefetch": [{
    "source": "list",
    "urls": ["/page-a", "/page-b"]
  }]
}
</script>

JSON ऑब्जेक्ट एक या उससे ज़्यादा कार्रवाइयों के बारे में बताता है. फ़िलहाल, यह ऑब्जेक्ट सिर्फ़ prefetch और prerender के साथ काम करता है. साथ ही, इन कार्रवाइयों से जुड़े यूआरएल की सूची भी मौजूद है. पिछले एचटीएमएल स्निपेट में, ब्राउज़र को /page-a और /page-b को प्रीफ़ेच करने का निर्देश दिया गया है. <link rel="prefetch"> की तरह, अनुमान लगाने के नियम इस बात के संकेत हैं कि कुछ खास स्थितियों में ब्राउज़र इसे अनदेखा कर सकता है.

Quicklink जैसी लाइब्रेरी, पेज के लिंक को डाइनैमिक तौर पर प्रीफ़ेच या प्रीरेंडरिंग करके, उपयोगकर्ता के व्यूपोर्ट में दिखने के बाद पेज नेविगेशन को बेहतर बनाती हैं. इससे पेज के सभी लिंक को प्रीफ़ेच करने के मुकाबले, उपयोगकर्ता के उस पेज पर जाने की संभावना बढ़ जाती है.

पेजों को पहले से रेंडर करें

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

अनुमान लगाने के नियम वाले एपीआई की मदद से, प्रीरेंडरिंग की सुविधा काम करती है:

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/page-a", "page-b"]
    }
  ]
}
</script>

डेमो को प्रीफ़ेच और प्रीरेंडर करने की सुविधा

सर्विस वर्कर प्री-कैश कर रहा है

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

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

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

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

[{  
    url: 'script.ffaa4455.js',
    revision: null
}, {
    url: '/index.html',
    revision: '518747aa'
}]

पिछला कोड, मेनिफ़ेस्ट का एक उदाहरण है. इसमें दो फ़ाइलें हैं: script.ffaa4455.js और /index.html. अगर किसी संसाधन में वर्शन की जानकारी फ़ाइल में मौजूद है (जिसे फ़ाइल हैश भी कहा जाता है), तो revision प्रॉपर्टी को null के तौर पर छोड़ा जा सकता है, क्योंकि फ़ाइल का वर्शन पहले से मौजूद है (उदाहरण के लिए, पिछले कोड में script.ffaa4455.js संसाधन के लिए ffaa4455). जिन संसाधनों का इस्तेमाल नहीं किया गया है उनके लिए, बिल्ड के समय बदलाव जनरेट किए जा सकते हैं.

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

workbox.precaching.precacheAndRoute([
  '/styles/product-page.ac29.css',
  '/styles/product-page.39a1.js',
]);

उदाहरण के लिए, किसी ई-कॉमर्स प्रॉडक्ट लिस्टिंग पेज पर, सर्विस वर्कर का इस्तेमाल करके, सीएसएस और JavaScript को प्रीकैश मेमोरी में सेव किया जा सकता है. इससे प्रॉडक्ट की जानकारी वाले पेज को रेंडर करने में मदद मिलती है. इससे प्रॉडक्ट की जानकारी वाले पेज पर नेविगेट करने की प्रोसेस ज़्यादा तेज़ हो जाती है. ऊपर दिए गए उदाहरण में, product-page.ac29.css और product-page.39a1.js प्रीकैश किए गए हैं. workbox-precaching में उपलब्ध precacheAndRoute तरीका, ज़रूरी हैंडलर को अपने-आप रजिस्टर करता है, ताकि ज़रूरत पड़ने पर, पहले से कैश मेमोरी में सेव किए गए संसाधन सर्विस वर्कर एपीआई से फ़ेच किए जा सकें.

सर्विस वर्कर बड़े पैमाने पर काम करते हैं, इसलिए किसी भी मॉडर्न ब्राउज़र पर सर्विस वर्कर का इस्तेमाल किया जा सकता है.

देखें कि आपको कितना ज्ञान है

prefetch संकेत किस प्राथमिकता पर होता है?

ज़्यादा.
फिर से कोशिश करें.
न कम न ज़्यादा.
फिर से कोशिश करें.
कम.
सही जवाब!

किसी पेज को प्रीफ़ेच करने और प्रीरेंडरिंग में क्या अंतर होता है?

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

सर्विस वर्कर कैश मेमोरी और एचटीटीपी कैश मेमोरी एक जैसी होती है.

सही
फिर से कोशिश करें.
गलत
सही जवाब!

अगला लेख: वेब वर्कर के बारे में खास जानकारी

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

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