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

एलसीपी को अलग-अलग हिस्सों में बांटने और सुधार के लिए ज़रूरी चीज़ों की पहचान करने का तरीका बताने वाली गाइड.

Philip Walton

Barry Pollard

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

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

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

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

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

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

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

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

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

Chrome DevTools में CrUX के एलसीपी डेटा का इस्तेमाल करना

Chrome DevTools का परफ़ॉर्मेंस पैनल, लाइव मेट्रिक व्यू में पेज या ऑरिजिन के CrUX एलसीपी के बगल में, आपका स्थानीय एलसीपी अनुभव दिखाता है.

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

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 डेटा का इस्तेमाल करने से पहले, पक्का करें कि यह आपके पेज का डेटा हो, न कि पूरे ऑरिजिन का.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

रिसॉर्स लोड होने में लगने वाला समय

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

एलिमेंट के रेंडर होने में लगने वाला समय

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

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

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

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

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

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

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

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

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

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

ध्यान दें कि ये समय के बंटवारे के दिशा-निर्देश हैं, न कि सख्त नियम. अगर आपके पेजों पर एलसीपी का समय लगातार 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> में मौजूद स्टाइलशीट या सिंक्रोनस स्क्रिप्ट की वजह से, पूरे पेज को रेंडर करने की प्रोसेस ब्लॉक हो गई है. ये स्क्रिप्ट अब भी लोड हो रही हैं.
• LCP रिसॉर्स लोड हो गया है, लेकिन LCP एलिमेंट अब तक DOM में नहीं जोड़ा गया है. यह किसी 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 में उपलब्ध है. यह जानकारी, परफ़ॉर्मेंस एपीआई के कॉम्बिनेशन से मिलती है:

• सबसे बड़ा Contentful Paint API
• नेविगेशन टाइमिंग एपीआई
• Resource Timing API

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

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

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

टाइमिंग ट्रैक में एलसीपी के सब-पार्ट को विज़ुअलाइज़ करने के अलावा, 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});

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

खास जानकारी

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

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

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

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