Largest Contentful Paint (LCP)

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

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

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

एलसीपी क्या है?

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

अच्छा एलसीपी स्कोर क्या होता है?

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

किन एलिमेंट को माना जाता है?

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

• <img> एलिमेंट (पहले फ़्रेम के प्रज़ेंटेशन के समय का इस्तेमाल, ऐनिमेशन वाले कॉन्टेंट के लिए किया जाता है, जैसे कि GIF या ऐनिमेशन वाले PNG)
• <svg> एलिमेंट में <image> एलिमेंट
• <video> एलिमेंट (पोस्टर इमेज लोड होने में लगने वाले समय या वीडियो को पहले फ़्रेम को दिखाने के समय का इस्तेमाल किया जाता है—इनमें से जो भी पहले हो)
• बैकग्राउंड इमेज वाला कोई एलिमेंट, जिसे सीएसएस ग्रेडिएंट के उलट url() फ़ंक्शन का इस्तेमाल करके लोड किया गया है
• ब्लॉक-लेवल के एलिमेंट, जिनमें टेक्स्ट नोड या अन्य इनलाइन-लेवल टेक्स्ट एलिमेंट चाइल्ड शामिल हैं.

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

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

• ऐसे एलिमेंट जिनकी ओपैसिटी 0 है, जो उपयोगकर्ता को नहीं दिखती है
• पूरे व्यूपोर्ट को कवर करने वाले एलिमेंट, जिन्हें कॉन्टेंट के बजाय बैकग्राउंड माना जा सकता है
• प्लेसहोल्डर इमेज या लो एंट्रॉपी वाली अन्य इमेज, जो पेज का सही कॉन्टेंट नहीं दिखाती हैं

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

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

एलिमेंट का साइज़ कैसे तय किया जाता है?

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

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

टेक्स्ट एलिमेंट के लिए, एलसीपी सबसे छोटे रेक्टैंगल के हिसाब से काम करता है, जिसमें सभी टेक्स्ट नोड शामिल हो सकते हैं.

एलसीपी, सभी एलिमेंट के लिए लागू किए गए मार्जिन, पैडिंग या बॉर्डर को सीएसएस का इस्तेमाल करके लागू नहीं करता.

एलसीपी को कब रिपोर्ट किया जाता है?

वेब पेज अक्सर अलग-अलग चरणों में लोड होते हैं. इस वजह से, पेज का सबसे बड़ा एलिमेंट भी बदल सकता है.

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

उदाहरण के लिए, टेक्स्ट और हीरो इमेज वाले पेज पर ब्राउज़र शुरुआत में सिर्फ़ टेक्स्ट को रेंडर कर सकता है. इसके बाद, ब्राउज़र ऐसी largest-contentful-paint एंट्री भेजेगा जिसकी element प्रॉपर्टी किसी <p> या <h1> का रेफ़रंस दे सकती है. बाद में, हीरो इमेज लोड होने के बाद, largest-contentful-paint की दूसरी एंट्री भेजी जाएगी और इसकी element प्रॉपर्टी <img> का रेफ़रंस देगी.

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

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

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

जैसे ही उपयोगकर्ता, पेज के साथ इंटरैक्ट (टैप, स्क्रोल करके या बटन दबाने के ज़रिए) करता है, तो ब्राउज़र नई एंट्री की रिपोर्ट करना बंद कर देता है. इसकी वजह यह है कि उपयोगकर्ता के इंटरैक्शन से अक्सर ऐसी चीज़ें बदल जाती हैं जो उपयोगकर्ता को दिखती हैं. ऐसा खास तौर पर, स्क्रोल करने के दौरान होता है.

विश्लेषण के लिए, आपको आंकड़ों की सेवा देने वाली सिर्फ़ कंपनी को, हाल ही में भेजी गई PerformanceEntry की जानकारी देनी चाहिए.

कॉन्टेंट लोड होने में लगने वाले समय और रेंडर होने में लगने वाले समय की तुलना में अंतर

सुरक्षा की वजहों से, उन क्रॉस-ऑरिजिन इमेज के रेंडर टाइमस्टैंप को नहीं दिखाया जाता जिनमें Timing-Allow-Origin हेडर नहीं होता. इसके बजाय, केवल उनका लोड समय दिखाया जाता है (क्योंकि यह पहले ही कई अन्य वेब API के माध्यम से प्रदर्शित हो जाता है).

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

हमारा सुझाव है कि जब भी संभव हो, आप हमेशा Timing-Allow-Origin हेडर सेट करें, ताकि आपकी मेट्रिक ज़्यादा सटीक हो.

एलिमेंट लेआउट और साइज़ में किए गए बदलावों को कैसे मैनेज किया जाता है?

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

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

उदाहरण

सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय, कुछ लोकप्रिय वेबसाइटों पर कब दिखता है, इसके कुछ उदाहरण यहां दिए गए हैं:

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

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

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

एलसीपी को मापने का तरीका

एलसीपी को लैब या फ़ील्ड में मापा जा सकता है. यह इन टूल में उपलब्ध है:

फ़ील्ड टूल

• Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट
• PageSpeed Insights
• Search Console (वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली रिपोर्ट)
• web-vitals JavaScript लाइब्रेरी

लैब टूल

• Chrome DevTools
• लाइटहाउस
• PageSpeed Insights
• WebPageTest

JavaScript में एलसीपी को मापें

JavaScript में एलसीपी को मापने के लिए, सबसे बड़े कॉन्टेंटफ़ुल पेंट एपीआई का इस्तेमाल किया जा सकता है. इस उदाहरण में, ऐसा PerformanceObserver बनाने का तरीका बताया गया है जो largest-contentful-paint एंट्री सुनता है और उन्हें कंसोल में लॉग करता है.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

ऊपर दिए गए उदाहरण में, लॉग की गई हर largest-contentful-paint एंट्री, मौजूदा एलसीपी उम्मीदवार की जानकारी देती है. आम तौर पर, आखिरी एंट्री की startTime वैल्यू, एलसीपी वैल्यू होती है. हालांकि, हमेशा ऐसा नहीं होता. एलसीपी को मेज़र करने के लिए, सभी largest-contentful-paint एंट्री मान्य नहीं हैं.

नीचे दिए गए सेक्शन में, एपीआई की रिपोर्ट और मेट्रिक की गिनती करने के तरीके के बीच के अंतर के बारे में बताया गया है.

मेट्रिक और एपीआई के बीच अंतर

• एपीआई, बैकग्राउंड टैब में लोड किए गए पेजों के लिए largest-contentful-paint एंट्री भेजेगा. हालांकि, एलसीपी का हिसाब लगाते समय उन पेजों को अनदेखा किया जाना चाहिए.
• किसी पेज को बैकग्राउंड में चलाने के बाद, एपीआई largest-contentful-paint एंट्री भेजता रहेगा. हालांकि, एलसीपी का हिसाब लगाते समय उन एंट्री को अनदेखा किया जाना चाहिए. एलिमेंट को सिर्फ़ तब माना जा सकता है, जब पेज पूरे समय फ़ोरग्राउंड में हो.
• पेज को बैक/फ़ॉरवर्ड कैश मेमोरी से वापस लाने पर, एपीआई largest-contentful-paint एंट्री को रिपोर्ट नहीं करता. हालांकि, इन मामलों में एलसीपी को मापा जाना चाहिए, क्योंकि उपयोगकर्ताओं को अलग-अलग पेज विज़िट का अनुभव मिलता है.
• एपीआई, iframes में मौजूद एलिमेंट को शामिल नहीं करता. हालांकि, मेट्रिक ऐसा इसलिए करती है, क्योंकि वे पेज के उपयोगकर्ता अनुभव का हिस्सा होती हैं. iframe में एलसीपी वाले पेज—उदाहरण के लिए, एम्बेड किए गए वीडियो पर पोस्टर इमेज होने पर—यह CrUX और RUM के बीच अंतर के तौर पर दिखेगा. एलसीपी को सही तरीके से मापने के लिए, आपको इन पर ध्यान देना चाहिए. सब-फ़्रेम, एग्रीगेशन के लिए पैरंट फ़्रेम को अपनी largest-contentful-paint एंट्री रिपोर्ट करने के लिए, एपीआई का इस्तेमाल कर सकते हैं.
• नेविगेशन शुरू होने के समय से, एपीआई, एलसीपी को मापता है. हालांकि, पहले से रेंडर किए गए पेजों के लिए, एलसीपी को activationStart से मापा जाना चाहिए. ऐसा इसलिए, क्योंकि यह उपयोगकर्ता के अनुभव के हिसाब से एलसीपी से जुड़ा समय होता है.

इन सभी छोटे-मोटे अंतर को याद रखने के बजाय, डेवलपर एलसीपी को मापने के लिए web-vitals JavaScript लाइब्रेरी का इस्तेमाल कर सकते हैं. यह आपके लिए इन अंतरों को हैंडल करती है (जहां मुमकिन हो—ध्यान दें कि iframe की समस्या इसमें शामिल नहीं है):

import {onLCP} from 'web-vitals';

// Measure and log LCP as soon as it's available.
onLCP(console.log);

JavaScript में एलसीपी को मापने के तरीके के बारे में ज़्यादा जानने के लिए, onLCP() का सोर्स कोड देखें.

अगर सबसे बड़ा एलिमेंट सबसे ज़रूरी नहीं है, तो क्या होगा?

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

एलसीपी को बेहतर बनाने का तरीका

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

अन्य संसाधन

• साल 2019 में, performance.now() में ऐनी सुलिवन ने Chrome में परफ़ॉर्मेंस को मॉनिटर करने की प्रक्रिया से सीखे सबक

बदलावों का लॉग

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

इन्हें मैनेज करने में आपकी मदद के लिए, इन मेट्रिक को लागू करने या इनकी परिभाषा में होने वाले सभी बदलाव, इस बदलाव लॉग में दिखाए जाएंगे.

अगर आपके पास इन मेट्रिक के बारे में कोई सुझाव है, तो वेब-वाइट्स-फ़ीडबैक Google ग्रुप में दिया जा सकता है.