सबसे बड़े कॉन्टेंटफ़ुल पेंट को ऑप्टिमाइज़ करें

एलसीपी को बेहतर बनाने के तरीके और उन अहम चीज़ों की पहचान करने के तरीके के बारे में सिलसिलेवार निर्देश जहां उन्हें बेहतर बनाया जा सकता है.

Philip Walton

Barry Pollard

पब्लिश किया गया: 30 अप्रैल, 2020

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

उपयोगकर्ताओं को अच्छा अनुभव देने के लिए, साइटों को यह कोशिश करनी चाहिए कि कम से कम 75% पेज विज़िट के लिए, एलसीपी 2.5 सेकंड या इससे कम हो.

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

ऐसा बहुत कम होता है कि पेज के किसी एक हिस्से को तुरंत ठीक करने से, एलसीपी में सुधार हो. एलसीपी को बेहतर बनाने के लिए, आपको कॉन्टेंट लोड होने की पूरी प्रोसेस को देखना होगा. साथ ही, यह पक्का करना होगा कि इस प्रोसेस के हर चरण को ऑप्टिमाइज़ किया गया हो.

एलसीपी मेट्रिक को समझना

LCP को ऑप्टिमाइज़ करने से पहले, डेवलपर को यह समझना चाहिए कि क्या उनके पास LCP से जुड़ी कोई समस्या है और अगर है, तो वह कितनी गंभीर है.

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

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

PageSpeed Insights के CrUX LCP डेटा का इस्तेमाल करना

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

PageSpeed Insights, चार अलग-अलग CrUX डेटा दिखाता है:

• इस यूआरएल के लिए मोबाइल डेटा
• इस यूआरएल के लिए डेस्कटॉप डेटा
• पूरे ऑरिजिन के लिए मोबाइल डेटा
• पूरे ऑरिजिन के लिए डेस्कटॉप डेटा

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

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

CrUX डेटा की चार अलग-अलग कैटगरी पर गौर करने से आपको यह समझने में मदद मिल सकती है कि क्या एलसीपी से जुड़ी समस्या सिर्फ़ इस पेज के लिए है या पूरी साइट के लिए सामान्य समस्या है. इसी तरह, यह सुविधा यह दिखा सकती है कि किन डिवाइस टाइप में एलसीपी से जुड़ी समस्याएं हैं.

PageSpeed Insights की CrUX की सहायक मेट्रिक का इस्तेमाल करना

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

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

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

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

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

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

PageSpeed Insights के Lighthouse डेटा का इस्तेमाल करना

PageSpeed Insights के Lighthouse सेक्शन में, एलसीपी को बेहतर बनाने के लिए कुछ दिशा-निर्देश दिए गए हैं. हालांकि, सबसे पहले आपको यह देखना चाहिए कि दिया गया एलसीपी, CrUX से मिले असल उपयोगकर्ता के डेटा से मेल खाता है या नहीं. अगर Lighthouse और CrUX के नतीजे अलग-अलग हैं, तो हो सकता है कि CrUX आपके उपयोगकर्ता अनुभव के बारे में ज़्यादा सटीक जानकारी दे. इस पर कार्रवाई करने से पहले पक्का करें कि आपका CrUX डेटा आपके पेज के लिए है, न कि पूरे ऑरिजिन के लिए.

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

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

हम इन सब-पार्ट के बारे में आगे बताएंगे.

एलसीपी ब्रेकडाउन

अगर PageSpeed Insights से आपको इस मेट्रिक को बेहतर बनाने का तरीका नहीं मिलता है, तो एलसीपी के लिए ऑप्टिमाइज़ करना ज़्यादा मुश्किल हो सकता है. मुश्किल टास्क को छोटे और मैनेज किए जा सकने वाले टास्क में बांटना और हर एक को अलग से हल करना बेहतर होता है.

इस सेक्शन में, एलसीपी को सबसे ज़रूरी सब-पार्ट्स में बांटने का तरीका बताया गया है. इसके बाद, हर हिस्से को ऑप्टिमाइज़ करने के लिए खास सुझाव और सबसे सही तरीके बताए गए हैं.

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

1. शुरुआती एचटीएमएल दस्तावेज़
2. एलसीपी संसाधन (अगर लागू हो)

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

एलसीपी संसाधन की पहचान करने के लिए, डेवलपर टूल (जैसे, पहले चर्चा किए गए PageSpeed Insights, Chrome DevTools या WebPageTest) का इस्तेमाल करके एलसीपी एलिमेंट पता किया जा सकता है. यहां से, पेज पर लोड किए गए सभी रिसॉर्स के नेटवर्क वॉटरफ़ॉल पर एलिमेंट के लोड किए गए यूआरएल (फिर से, अगर लागू हो) को मैच किया जा सकता है.

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

अच्छी तरह से ऑप्टिमाइज़ किए गए पेज के लिए, आपको एलसीपी संसाधन का अनुरोध जल्द से जल्द लोड होना चाहिए. साथ ही, एलसीपी संसाधन लोड होने के बाद, एलसीपी एलिमेंट को जल्द से जल्द रेंडर होना चाहिए. यह पता लगाने के लिए कि कोई पेज इस सिद्धांत का पालन कर रहा है या नहीं, एलसीपी के कुल समय को इन उप-भागों में बांटा जा सकता है:

टाइम टू फ़र्स्ट बाइट (TTFB)

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

संसाधन लोड होने में लगने वाला समय

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

संसाधन लोड की अवधि

एलसीपी संसाधन को लोड होने में लगने वाला समय. अगर एलसीपी एलिमेंट को रेंडर करने के लिए किसी संसाधन को लोड करने की ज़रूरत नहीं है, तो यह समय 0 होगा.

एलिमेंट के रेंडर होने में देरी

एलसीपी संसाधन के लोड होने और एलसीपी एलिमेंट के पूरी तरह से रेंडर होने के बीच का समय.

हर पेज के एलसीपी में ये चार सब-कैटगरी शामिल होती हैं. इनमें कोई गैप या ओवरलैप नहीं होता और ये कुल एलसीपी समय में जुड़ जाते हैं.

हर पेज की एलसीपी वैल्यू को इन चार उप-भागों में बांटा जा सकता है. उनके बीच कोई ओवरलैप या अंतर नहीं होता है. इन सभी को मिलाकर, एलसीपी का कुल समय मिलता है.

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

उदाहरण के लिए, पिछले नेटवर्क वॉटरफ़ॉल में, अगर आपने हमारी इमेज को ज़्यादा कंप्रेस करके या AVIF या WebP फ़ॉर्मैट में स्विच करके फ़ाइल के साइज़ को कम किया था, तो इससे संसाधन लोड होने की अवधि कम होगी. हालांकि, इससे एलसीपी में कोई सुधार नहीं होगा. ऐसा इसलिए होगा, क्योंकि समय सिर्फ़ एलिमेंट रेंडर होने में देरी वाले सब-पार्ट में बदल जाएगा:

ऐसा इसलिए होता है, क्योंकि इस पेज पर, JavaScript कोड लोड होने तक एलसीपी एलिमेंट छिपा रहता है. इसके बाद, एक साथ सारा कॉन्टेंट दिखने लगता है.

इस उदाहरण से यह पता चलता है कि एलसीपी के सबसे अच्छे नतीजे पाने के लिए, आपको इन सभी सब-पार्ट को ऑप्टिमाइज़ करना होगा.

सबसे सही समय के लिए, वीडियो के अलग-अलग हिस्सों की अवधि

एलसीपी के हर सब-पार्ट को ऑप्टिमाइज़ करने के लिए यह समझना ज़रूरी है कि बेहतर तरीके से ऑप्टिमाइज़ किए गए पेज पर इन सब-पार्ट्स का सबसे सही ब्रेकडाउन क्या है.

चार उप-भागों में से दो में "delay" शब्द है अपने नाम में शामिल किया है. यह एक संकेत है कि आपको इन समय को शून्य के करीब लाना है. बाकी के दो हिस्सों में नेटवर्क के अनुरोध शामिल होते हैं. आम तौर पर, इन अनुरोधों में समय लगता है.

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

एलसीपी समय के ब्रेकडाउन को समझने का एक अच्छा तरीका यह है:

• एलसीपी का ज़्यादा से ज़्यादा समय, एचटीएमएल दस्तावेज़ और एलसीपी सोर्स को लोड करने में खर्च होना चाहिए.
• एलसीपी से पहले जब इन दोनों में से कोई एक संसाधन लोड नहीं हो रहा हो, तो इसे बेहतर बनाने का मौका मिलता है.

हर हिस्से को ऑप्टिमाइज़ करने का तरीका

अब आपने यह समझ लिया है कि अच्छी तरह से ऑप्टिमाइज़ किए गए पेज पर, एलसीपी के हर सब-पार्ट का समय कैसे बांटा जाना चाहिए. अब अपने पेजों को ऑप्टिमाइज़ करना शुरू किया जा सकता है.

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

1. संसाधन लोड होने में लगने वाले समय को कम करना

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

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

आम तौर पर, एलसीपी संसाधन कितनी तेज़ी से लोड हो सकते हैं, यह इन दो बातों पर निर्भर करता है:

• संसाधन मिलने पर.
• संसाधन को किस प्राथमिकता दी जाती है.

संसाधन का पता चलने पर उसे ऑप्टिमाइज़ करना

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

• एलसीपी एलिमेंट एक <img> एलिमेंट है और इसके src या srcset एट्रिब्यूट, शुरुआती एचटीएमएल मार्कअप में मौजूद होते हैं.
• एलसीपी एलिमेंट के लिए सीएसएस बैकग्राउंड इमेज की ज़रूरत होती है, लेकिन उस इमेज को एचटीएमएल मार्कअप में <link rel="preload"> का इस्तेमाल करके (या Link हेडर का इस्तेमाल करके) पहले से लोड किया गया है.
• एलसीपी एलिमेंट एक टेक्स्ट नोड है. इसे रेंडर करने के लिए, वेब फ़ॉन्ट की ज़रूरत होती है. यह फ़ॉन्ट, एचटीएमएल मार्कअप में <link rel="preload"> का इस्तेमाल करके (या Link हेडर का इस्तेमाल करके) लोड किया जाता है.

यहां कुछ ऐसे उदाहरण दिए गए हैं जिनमें एचटीएमएल दस्तावेज़ के रिस्पॉन्स को स्कैन करके, एलसीपी संसाधन का पता नहीं लगाया जा सकता:

• एलसीपी एलिमेंट एक <img> है, जिसे JavaScript का इस्तेमाल करके, पेज में डाइनैमिक तरीके से जोड़ा जाता है.
• एलसीपी एलिमेंट को लेज़ी तरीके से ऐसी JavaScript लाइब्रेरी के साथ लोड किया गया है जो अपने src या srcset एट्रिब्यूट (अक्सर data-src या data-srcset) को छिपा देती है.
• एलसीपी एलिमेंट के लिए, सीएसएस बैकग्राउंड इमेज ज़रूरी है.

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

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

<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">

<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">

रिसॉर्स को दी गई प्राथमिकता को ऑप्टिमाइज़ करना

भले ही, एचटीएमएल मार्कअप से एलसीपी रिसॉर्स को ढूंढा जा सकता हो, लेकिन हो सकता है कि वह पहले रिसॉर्स के तौर पर लोड न हो. ऐसा तब हो सकता है, जब ब्राउज़र प्रीलोड स्कैनर की प्राथमिकता के हेयुरिस्टिक्स यह न पहचान पाएं कि रिसॉर्स ज़रूरी है या जब यह तय हो कि दूसरे रिसॉर्स ज़्यादा ज़रूरी हैं.

उदाहरण के लिए, अगर आपने <img> एलिमेंट पर loading="lazy" को सेट किया है, तो एचटीएमएल का इस्तेमाल करके एलसीपी इमेज को देर से सेट किया जा सकता है. लेज़ी लोडिंग का इस्तेमाल करने का मतलब है कि रिसॉर्स तब तक लोड नहीं होगा, जब तक लेआउट यह पुष्टि नहीं कर लेता कि इमेज व्यूपोर्ट में है. इसलिए, यह सामान्य लोडिंग की तुलना में बाद में लोड हो सकता है.

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

<img fetchpriority="high" src="/path/to/hero-image.webp">

अगर आपको लगता है कि यह आपके पेज का एलसीपी एलिमेंट हो सकता है, तो <img> एलिमेंट पर fetchpriority="high" सेट करना एक अच्छा आइडिया है. हालांकि, एक या दो से ज़्यादा इमेज के लिए ज़्यादा प्राथमिकता सेट करने से, एलसीपी को कम करने में मदद नहीं मिलती.

उन इमेज को भी प्राथमिकता दी जा सकती है जो दस्तावेज़ के जवाब में शुरुआती दौर में हैं, लेकिन स्टाइल की वजह से नहीं दिख रही हैं. जैसे: कैरसेल स्लाइड में मौजूद ऐसी इमेज जो ब्राउज़र खुलने के समय नहीं दिखतीं:

<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">

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

एलसीपी रिसॉर्स की प्राथमिकता और उसे खोजने के समय को ऑप्टिमाइज़ करने के बाद, आपके नेटवर्क का वॉटरफ़ॉल कुछ ऐसा दिखना चाहिए. पहले रिसॉर्स के साथ एलसीपी रिसॉर्स एक ही समय पर शुरू होता है:

2. एलिमेंट रेंडर होने में देरी को हटाएं

इस चरण का मकसद यह पक्का करना है कि एलसीपी एलिमेंट, रिसॉर्स लोड होने के तुरंत बाद रेंडर हो सके, भले ही ऐसा होता हो.

एलसीपी एलिमेंट के लोड न हो पाने की मुख्य वजह यह है कि अगर रेंडरिंग को किसी दूसरी वजह से ब्लॉक किया गया है, तो:

• <head> में मौजूद स्टाइलशीट या सिंक्रोनस स्क्रिप्ट की वजह से, पूरे पेज को रेंडर करने की प्रोसेस ब्लॉक हो गई है. ये स्क्रिप्ट अब भी लोड हो रही हैं.
• एलसीपी रिसॉर्स लोड हो गया है, लेकिन एलसीपी एलिमेंट को अब तक डीओएम में नहीं जोड़ा गया है. यह कुछ JavaScript कोड के लोड होने का इंतज़ार कर रहा है.
• A/B टेस्टिंग लाइब्रेरी जैसे किसी अन्य कोड की वजह से एलिमेंट को छिपाया जा रहा है. इससे यह तय किया जा रहा है कि उपयोगकर्ता को किस एक्सपेरिमेंट में करना चाहिए.
• लंबे टास्क की वजह से मुख्य थ्रेड को ब्लॉक किया गया है. साथ ही, रेंडरिंग के काम को तब तक इंतज़ार करना होगा, जब तक वे लंबे टास्क पूरे नहीं हो जाते.

नीचे दिए सेक्शन में, एलिमेंट के रेंडर होने में ग़ैर-ज़रूरी देरी की सबसे आम वजहों को हल करने का तरीका बताया गया है.

विज्ञापन दिखाने पर रोक लगाने वाली स्टाइलशीट को कम करना या इनलाइन करना

एचटीएमएल मार्कअप से लोड की गई स्टाइल शीट, उनसे बाद के सभी कॉन्टेंट को रेंडर करने से रोक देंगी. यह अच्छा है, क्योंकि आम तौर पर आपको स्टाइल न किए गए एचटीएमएल को रेंडर नहीं करना होता. हालांकि, अगर स्टाइल शीट इतनी बड़ी है कि उसे एलसीपी रिसॉर्स से ज़्यादा समय लगता है, तो यह एलसीपी एलिमेंट को रेंडर होने से रोक देगी. ऐसा तब भी होगा, जब उसका रिसॉर्स लोड हो चुका हो. इस उदाहरण में इसकी जानकारी दी गई है:

इसे ठीक करने के लिए, आपके पास दो विकल्प हैं:

• अतिरिक्त नेटवर्क अनुरोध से बचने के लिए, स्टाइल शीट को एचटीएमएल में इनलाइन करें; या
• स्टाइल शीट का साइज़ कम करें.

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

ज़्यादातर मामलों में, स्टाइल शीट का साइज़ कम करके यह पक्का किया जा सकता है कि वह एलसीपी एलिमेंट के रेंडर होने में रुकावट न डाले. ऐसा करने से, स्टाइल शीट का साइज़ एलसीपी रिसॉर्स से छोटा हो जाता है. इससे यह पक्का किया जा सकता है कि ज़्यादातर विज़िट के लिए, यह कोई समस्या न हो.

स्टाइल शीट का साइज़ कम करने के लिए, यहां कुछ सुझाव दिए गए हैं:

• इस्तेमाल नहीं किए गए सीएसएस हटाएं: Chrome DevTools का इस्तेमाल करके, ऐसे सीएसएस नियम खोजें जिनका इस्तेमाल नहीं किया जा रहा है. साथ ही, जिन्हें हटाया या रोका जा सकता है.
• गैर-ज़रूरी सीएसएस को हटाएं: अपनी स्टाइल शीट को उन स्टाइल में बांटें जो शुरुआती पेज लोड के लिए ज़रूरी हैं. इसके बाद, उन स्टाइल को बांटें जिन्हें लेज़ी तरीके से लोड किया जा सकता है.
• सीएसएस को छोटा और कंप्रेस करें: ज़रूरी स्टाइल के लिए, पक्का करें कि आप उनके ट्रांसफ़र साइज़ को ज़्यादा से ज़्यादा कम कर रहे हों.

रेंडर रोकने वाली JavaScript को रोकें या इनलाइन करें

अपने पेजों के <head> में सिंक्रोनस स्क्रिप्ट (async या defer एट्रिब्यूट के बिना स्क्रिप्ट) जोड़ना ज़रूरी नहीं होता. ऐसा करने से, परफ़ॉर्मेंस पर हमेशा बुरा असर पड़ता है.

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

<head>
  <script src="/path/to/main.js"></script>
</head>

<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

सर्वर साइड रेंडरिंग का इस्तेमाल करना

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

एलसीपी को ऑप्टिमाइज़ करने के हिसाब से, एसएसआर के दो मुख्य फ़ायदे हैं:

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

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

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

लंबे टास्क को छोटे-छोटे हिस्सों में बांटना

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

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

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

3. संसाधन लोड होने में लगने वाला समय कम करना

इस चरण का मकसद उपयोगकर्ता के डिवाइस पर, नेटवर्क से रिसॉर्स के बाइट ट्रांसफ़र करने में लगने वाले समय को कम करना है. आम तौर पर, ऐसा करने के तीन तरीके हैं:

• संसाधन का साइज़ कम करें.
• संसाधन से तय की गई दूरी को कम करें.
• नेटवर्क बैंडविड्थ के लिए विवाद कम करें.
• नेटवर्क के लिए लगने वाले समय को पूरी तरह से हटा दें.

संसाधन का साइज़ कम करना

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

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

संसाधन को तय की गई दूरी तय करने में लगने वाले समय को कम करना

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

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

नेटवर्क बैंडविड्थ के लिए विवाद कम करें

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

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

नेटवर्क समय को पूरी तरह से खत्म करें

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

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

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

4. टाइम टू फ़र्स्ट बाइट कम करना

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

तेज़ी से लोड होने वाली साइट के धीमे टीटीएफ़बी की एक आम वजह यह है कि वेबसाइट पर आने वाले लोग कई रीडायरेक्ट के ज़रिए पहुंचते हैं, जैसे कि विज्ञापन या छोटे लिंक. रीडायरेक्ट की संख्या कम से कम रखें, ताकि वेबसाइट पर आने वाले को इंतज़ार करना पड़े.

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

टीटीएफ़बी को ऑप्टिमाइज़ करने के बारे में खास जानकारी पाने के लिए, टीटीएफ़बी को ऑप्टिमाइज़ करने के बारे में गाइड देखें.

JavaScript में एलसीपी के ब्रेकडाउन को मॉनिटर करना

ऊपर बताए गए सभी एलसीपी सब-पार्ट के समय की जानकारी, आपके लिए JavaScript में उपलब्ध है. इसके लिए, यहां दिए गए परफ़ॉर्मेंस एपीआई के कॉम्बिनेशन का इस्तेमाल किया जा सकता है:

• सबसे बड़ा कॉन्टेंटफ़ुल पेंट एपीआई
• नेविगेशन टाइमिंग एपीआई
• Resource Timing API

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

उदाहरण के लिए, इस स्क्रीनशॉट में User Timing API के performance.measure() तरीके का इस्तेमाल करके, Chrome DevTools के परफ़ॉर्मेंस पैनल के टाइमिंग ट्रैक में बार जोड़े गए हैं.

समय ट्रैक में विज़ुअलाइज़ेशन, खास तौर पर नेटवर्क और मुख्य थ्रेड ट्रैक के साथ देखने पर मददगार होते हैं. इसकी वजह यह है कि इन समयावधि के दौरान, पेज पर क्या-क्या हो रहा है, यह एक नज़र में देखा जा सकता है.

टाइमिंग ट्रैक में एलसीपी के सब-पार्ट को विज़ुअलाइज़ करने के अलावा, JavaScript का इस्तेमाल करके यह भी पता लगाया जा सकता है कि एलसीपी के कुल समय में हर सब-पार्ट का प्रतिशत कितना है. इस जानकारी की मदद से यह तय किया जा सकता है कि आपके पेज, ऊपर बताए गए प्रतिशत के सुझावों के हिसाब से हैं या नहीं.

इस स्क्रीनशॉट में एक उदाहरण दिया गया है, जिसमें हर एलसीपी सब-पार्ट का कुल समय लॉग किया गया है. साथ ही, कंसोल में एलसीपी के कुल समय का प्रतिशत भी दिखाया गया है.

ये दोनों विज़ुअलाइज़ेशन इस कोड का इस्तेमाल करके बनाए गए हैं:

const LCP_SUB_PARTS = [
  'Time to first byte',
  'Resource load delay',
  'Resource load duration',
  'Element render delay',
];

new PerformanceObserver((list) => {
  const lcpEntry = list.getEntries().at(-1);
  const navEntry = performance.getEntriesByType('navigation')[0];
  const lcpResEntry = performance
    .getEntriesByType('resource')
    .filter((e) => e.name === lcpEntry.url)[0];

  // Ignore LCP entries that aren't images to reduce DevTools noise.
  // Comment this line out if you want to include text entries.
  if (!lcpEntry.url) return;

  // Compute the start and end times of each LCP sub-part.
  // WARNING! If your LCP resource is loaded cross-origin, make sure to add
  // the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
  const ttfb = navEntry.responseStart;
  const lcpRequestStart = Math.max(
    ttfb,
    // Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
    lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
  );
  const lcpResponseEnd = Math.max(
    lcpRequestStart,
    lcpResEntry ? lcpResEntry.responseEnd : 0
  );
  const lcpRenderTime = Math.max(
    lcpResponseEnd,
    // Use LCP startTime (the final LCP time) because there are sometimes
    // slight differences between loadTime/renderTime and startTime
    // due to rounding precision.
    lcpEntry ? lcpEntry.startTime : 0
  );

  // Clear previous measures before making new ones.
  // Note: due to a bug, this doesn't work in Chrome DevTools.
  LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));

  // Create measures for each LCP sub-part for easier
  // visualization in the Chrome DevTools Performance panel.
  const lcpSubPartMeasures = [
    performance.measure(LCP_SUB_PARTS[0], {
      start: 0,
      end: ttfb,
    }),
    performance.measure(LCP_SUB_PARTS[1], {
      start: ttfb,
      end: lcpRequestStart,
    }),
    performance.measure(LCP_SUB_PARTS[2], {
      start: lcpRequestStart,
      end: lcpResponseEnd,
    }),
    performance.measure(LCP_SUB_PARTS[3], {
      start: lcpResponseEnd,
      end: lcpRenderTime,
    }),
  ];

  // Log helpful debug information to the console.
  console.log('LCP value: ', lcpRenderTime);
  console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  console.table(
    lcpSubPartMeasures.map((measure) => ({
      'LCP sub-part': measure.name,
      'Time (ms)': measure.duration,
      '% of LCP': `${
        Math.round((1000 * measure.duration) / lcpRenderTime) / 10
      }%`,
    }))
  );
}).observe({type: 'largest-contentful-paint', buffered: true});

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

Chrome DevTools की मदद से एलसीपी के ब्रेकडाउन को मॉनिटर करें

Chrome DevTools, एलसीपी के समय, एलसीपी एलिमेंट, और इन चार सब-पार्ट को रीयल टाइम में लॉग करेगा, ताकि आपको यह ब्रेकडाउन देखने में मदद मिल सके.

खास जानकारी

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

एलसीपी को ऑप्टिमाइज़ करने के लिए, चार चरणों का पालन किया जा सकता है:

1. पक्का करें कि एलसीपी संसाधन जल्द से जल्द लोड हों.
2. पक्का करें कि एलसीपी एलिमेंट का रिसॉर्स लोड होने के तुरंत बाद, वह रेंडर हो जाए.
3. एलसीपी संसाधन के लोड होने में लगने वाले समय को जितना हो सके उतना कम करें. क्वालिटी से समझौता किए बिना ऐसा किया जा सकता है.
4. मूल एचटीएमएल दस्तावेज़ को जल्द से जल्द डिलीवर करें.

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