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

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

पेजों को पहले से लोड करने की सुविधा कैसे काम करती है

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

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

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

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

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

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

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

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

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

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

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

पहले से लोड किए गए, इस्तेमाल न किए गए संसाधनों के बारे में 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 बताने का एक फ़ायदा यह है कि दस्तावेज़ खोजने के लिए ब्राउज़र को पार्स करने की ज़रूरत नहीं होती. इससे कुछ मामलों में छोटे सुधार हो सकते हैं.

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

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

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

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

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

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

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

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

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

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

जब एलसीपी और 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 का कम से कम इस्तेमाल करें और असल दुनिया पर इसका क्या असर होता है.