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

एलसीपी को छोटे-छोटे हिस्सों में बांटने और सुधार की ज़रूरी चीज़ों की पहचान करने के लिए सिलसिलेवार निर्देश.

Philip Walton

Barry Pollard

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

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

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

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

एलसीपी मेट्रिक के बारे में जानकारी

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

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

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

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

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

PageSpeed Insights की मदद से, ज़्यादा से ज़्यादा चार अलग-अलग CrUX डेटा देखा जा सकता है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हम आगे इन सब-हिस्सों पर विस्तार से बात करेंगे.

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

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

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

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

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

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

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

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

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

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

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

संसाधन लोड होने में देरी

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

रिसॉर्स लोड होने की अवधि

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

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

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

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

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

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

उदाहरण के लिए, पुराने नेटवर्क वॉटरफ़ॉल में, अगर इमेज के फ़ाइल साइज़ को ज़्यादा कंप्रेस करके कम किया जाता था या 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">

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

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

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

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

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

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

JavaScript में एलसीपी ब्रेकडाउन पर नज़र रखें

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

• सबसे बड़ा कॉन्टेंटफ़ुल पेंट एपीआई
• नेविगेशन टाइमिंग एपीआई
• 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. शुरुआती एचटीएमएल दस्तावेज़ जल्द से जल्द डिलीवर करें.

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