लोड होने की स्पीड बढ़ाने के लिए, क्रिटिकल ऐसेट पहले से लोड करें

जब कोई वेब पेज खोला जाता है, तो ब्राउज़र किसी सर्वर से एचटीएमएल दस्तावेज़ के लिए अनुरोध करता है. साथ ही, वह इसका कॉन्टेंट पार्स करता है और रेफ़रंस वाले सभी संसाधनों के लिए अलग-अलग अनुरोध सबमिट करता है. डेवलपर के तौर पर, आपको अपने पेज के लिए ज़रूरी सभी संसाधनों और उनमें से सबसे अहम संसाधनों के बारे में पहले से ही पता होता है. इस जानकारी का इस्तेमाल करके, अहम संसाधनों के लिए समय से पहले ही अनुरोध किया जा सकता है और लोडिंग की प्रोसेस को तेज़ किया जा सकता है. इस पोस्ट में बताया गया है कि <link rel="preload"> की मदद से ऐसा कैसे किया जा सकता है.

पेजों को पहले से लोड करने की प्रक्रिया कैसे काम करती है

पेजों को पहले से लोड करने की सुविधा, ऐसे रिसॉर्स के लिए सबसे अच्छा है जिन्हें आम तौर पर ब्राउज़र देर से खोजता है.

Chrome DevTools नेटवर्क पैनल का स्क्रीनशॉट.
इस उदाहरण में, Pacifico फ़ॉन्ट को स्टाइलशीट में @font-face नियम के साथ तय किया गया है. ब्राउज़र, फ़ॉन्ट फ़ाइल को सिर्फ़ तब लोड करता है, जब स्टाइलशीट को डाउनलोड और पार्स कर दिया जाता है.

किसी संसाधन को पहले से लोड करके, आप ब्राउज़र को बताते हैं कि आप उसे जल्दी फ़ेच करना चाहते हैं, क्योंकि ऐसा न करने पर ब्राउज़र उसे खोज लेता है, क्योंकि आपको भरोसा होता है कि यह मौजूदा पेज के लिए ज़रूरी है.

पहले से लोड करना लागू करने के बाद, Chrome DevTools नेटवर्क पैनल का स्क्रीनशॉट.
इस उदाहरण में, Pacifico फ़ॉन्ट पहले से लोड किया गया है, इसलिए स्टाइलशीट के साथ डाउनलोड होता है.

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

Lighthouse के पहले से लोड किए गए मुख्य अनुरोधों का ऑडिट.

अपने एचटीएमएल दस्तावेज़ के सबसे ऊपर rel="preload" वाला <link> टैग जोड़कर, संसाधनों को पहले से लोड किया जा सकता है:

<link rel="preload" as="script" href="critical.js">

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

रिसॉर्स से जुड़े संकेत, जैसे कि preconnect और prefetch, ब्राउज़र के हिसाब से अपने-आप लागू होते हैं. दूसरी ओर, preload ब्राउज़र के लिए ज़रूरी है. मॉडर्न ब्राउज़र, संसाधनों को प्राथमिकता देने में पहले से बहुत अच्छे हैं. इसलिए, यह ज़रूरी है कि preload का कम से कम इस्तेमाल किया जाए और सबसे ज़रूरी संसाधनों को ही पहले से लोड किया जाए.

ऐसी गड़बड़ियों की वजह से, load इवेंट के करीब तीन सेकंड बाद, Chrome में कंसोल पर पहले से लोड की गई एक चेतावनी ट्रिगर होती है.

पहले से लोड नहीं किए गए संसाधनों के बारे में Chrome DevTools Console की चेतावनी.

इस्तेमाल के उदाहरण

सीएसएस में तय किए गए संसाधनों को पहले से लोड करना

@font-face नियमों के साथ तय किए गए फ़ॉन्ट या सीएसएस फ़ाइलों में तय किए गए बैकग्राउंड इमेज तब तक नहीं खोजे जाते, जब तक ब्राउज़र उन सीएसएस फ़ाइलों को डाउनलोड और पार्स नहीं कर देता. इन संसाधनों को पहले से लोड करने से, यह पक्का हो जाता है कि सीएसएस फ़ाइलें डाउनलोड होने से पहले इन्हें फ़ेच कर लिया जाए.

सीएसएस फ़ाइलों को पहले से लोड किया जा रहा है

अगर सीएसएस का अहम तरीका इस्तेमाल किया जा रहा है, तो अपने सीएसएस को दो हिस्सों में बांट दें. वेबपेज पर सबसे ऊपर दिखने वाले कॉन्टेंट को रेंडर करने के लिए ज़रूरी सीएसएस, दस्तावेज़ के <head> में इनलाइन होती है. साथ ही, गै़र-ज़रूरी सीएसएस में JavaScript लेज़ी लोड होता है. गै़र-ज़रूरी सीएसएस को लोड करने से पहले JavaScript के काम करने का इंतज़ार करने से, उपयोगकर्ताओं के स्क्रोल करने पर रेंडर होने में देरी हो सकती है. इसलिए, जल्द डाउनलोड शुरू करने के लिए <link rel="preload"> का इस्तेमाल करना बेहतर होगा.

JavaScript फ़ाइलों को पहले से लोड करना

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

rel=preload को लागू करने का तरीका

preload को लागू करने का सबसे आसान तरीका, दस्तावेज़ के <head> में <link> टैग को जोड़ना है:

<head>
  <link rel="preload" as="script" href="critical.js">
</head>

as एट्रिब्यूट देने से ब्राउज़र को प्रीफ़ेच किए गए संसाधन की प्राथमिकता को उसके टाइप के हिसाब से सेट करने, सही हेडर सेट करने, और यह तय करने में मदद मिलती है कि रिसॉर्स पहले से कैश मेमोरी में मौजूद है या नहीं. इस एट्रिब्यूट के लिए ये वैल्यू इस्तेमाल की जा सकती हैं: script, style, font, image, और अन्य.

कुछ तरह के संसाधन, जैसे कि फ़ॉन्ट बिना पहचान वाले मोड में लोड किए जाते हैं. उनके लिए, आपको crossorigin एट्रिब्यूट को preload के साथ सेट करना होगा:

<link rel="preload" href="ComicSans.woff2" as="font" type="font/woff2" crossorigin>

<link> एलिमेंट, type एट्रिब्यूट भी स्वीकार करते हैं, जिसमें लिंक किए गए संसाधन का MIME टाइप शामिल होता है. ब्राउज़र type एट्रिब्यूट की वैल्यू का इस्तेमाल यह पक्का करने के लिए करते हैं कि संसाधन पहले से लोड हों, सिर्फ़ तब. अगर कोई ब्राउज़र, बताए गए रिसॉर्स टाइप के साथ काम नहीं करता, तो यह <link rel="preload"> को अनदेखा कर देगा.

Link एचटीटीपी हेडर की मदद से, किसी भी तरह के संसाधन को पहले से लोड भी किया जा सकता है:

Link: </css/style.css>; rel="preload"; as="style"

एचटीटीपी हेडर में preload के बारे में बताने का एक फ़ायदा यह है कि ब्राउज़र को खोजने के लिए उसे पार्स करने की ज़रूरत नहीं होती. इससे कुछ मामलों में छोटे सुधार किए जा सकते हैं.

वेबपैक के साथ JavaScript मॉड्यूल पहले से लोड करना

अगर ऐसे मॉड्यूल बंडलर का इस्तेमाल किया जा रहा है जो आपके ऐप्लिकेशन की बिल्ड फ़ाइलें बनाता है, तो आपको यह देखना होगा कि वह प्रीलोड टैग के इंजेक्शन के साथ काम करता है या नहीं. वेबपैक 4.6.0 या इसके बाद के वर्शन में, import() में मैजिक टिप्पणियों की मदद से, पेजों को पहले से लोड करने की सुविधा काम करती है:

import(_/* webpackPreload: true */_ "CriticalChunk")

अगर वेबपैक का पुराना वर्शन इस्तेमाल किया जा रहा है, तो तीसरे पक्ष के प्लगिन का इस्तेमाल करें, जैसे कि preload-webpack-plugin.

वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी वाली रिपोर्ट को पहले से लोड करने के असर

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

सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी)

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

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

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

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

कुल लेआउट शिफ़्ट (सीएलएस)

कुल लेआउट शिफ़्ट (सीएलएस), वेब फ़ॉन्ट के बारे में जानकारी देने वाली खास मेट्रिक है. साथ ही, सीएलएस में वेब फ़ॉन्ट के साथ काफ़ी इंटरप्ले होता है, जो फ़ॉन्ट के लोड होने के तरीके को मैनेज करने के लिए, font-display सीएसएस प्रॉपर्टी का इस्तेमाल करता है. वेब फ़ॉन्ट से जुड़े लेआउट शिफ़्ट को कम करने के लिए, ये रणनीतियां अपनाएं:

  1. font-display के लिए, block डिफ़ॉल्ट वैल्यू का इस्तेमाल करते समय, फ़ॉन्ट पहले से लोड करें. यह एक नायाब संतुलन है. फ़ॉलबैक के बिना फ़ॉन्ट दिखाने पर रोक लगाने से, उपयोगकर्ता को परेशानी हो सकती है. एक तरफ़, font-display: block; की मदद से फ़ॉन्ट लोड करने पर, वेब फ़ॉन्ट से जुड़े लेआउट शिफ़्ट नहीं होते. दूसरी ओर, अगर वेब फ़ॉन्ट उपयोगकर्ता को अच्छा अनुभव देने के लिए ज़रूरी हों, तो आपको उन्हें जल्द से जल्द लोड करवाना चाहिए. प्रीलोड को font-display: block; के साथ जोड़ना, एक बेहतर समझौता हो सकता है.
  2. font-display के लिए fallback वैल्यू का इस्तेमाल करते समय, फ़ॉन्ट पहले से लोड करें. fallback, swap और block के बीच एक समझौता है, क्योंकि इसे ब्लॉक करने की अवधि बहुत कम है.
  3. पहले से लोड किए बिना font-display के लिए, optional वैल्यू का इस्तेमाल करें. अगर कोई वेब फ़ॉन्ट, उपयोगकर्ता अनुभव के लिए अहम नहीं है, लेकिन इसका इस्तेमाल पेज के टेक्स्ट को रेंडर करने के लिए अब भी किया जा रहा है, तो optional वैल्यू का इस्तेमाल करें. उलटी स्थितियों में, optional पेज के टेक्स्ट को फ़ॉलबैक फ़ॉन्ट में दिखाएगा. हालांकि, ऐसा तब होगा, जब यह अगले नेविगेशन के लिए बैकग्राउंड में फ़ॉन्ट लोड करेगा. इन स्थितियों में कुल नतीजा, सीएलएस में सुधार होता है, क्योंकि सिस्टम फ़ॉन्ट तुरंत रेंडर होते हैं. वहीं, बाद में पेज लोड होने पर, फ़ॉन्ट लेआउट शिफ़्ट के बिना तुरंत लोड हो जाते हैं.

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

इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी)

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

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

नतीजा

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