पुराने समय में, वेब डेवलपर के लिए यह देखना चुनौती भरा रहा था कि किसी वेब पेज का मुख्य कॉन्टेंट कितनी जल्दी लोड होता है और उपयोगकर्ताओं को दिखता है. load या DOMContentLoaded जैसी पुरानी मेट्रिक ठीक से काम नहीं करतीं, क्योंकि ये ज़रूरी नहीं है कि वे उपयोगकर्ता को स्क्रीन पर दिखने वाली जानकारी से मेल खाएं. साथ ही, फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) जैसी नई, उपयोगकर्ता के हिसाब से बनाई गई परफ़ॉर्मेंस मेट्रिक, सिर्फ़ पेज लोड होने की शुरुआती प्रक्रिया को कैप्चर करती हैं. अगर कोई पेज स्प्लैश स्क्रीन दिखाता है या लोड होने का इंंडिकेटर दिखाता है, तो यह पल उपयोगकर्ता के लिए ज़्यादा सही नहीं है.
पहले, हमने फ़र्स्ट मीनिंगफ़ुल पेंट (एफ़एमपी) और स्पीड इंडेक्स (एसआई) जैसी परफ़ॉर्मेंस मेट्रिक के सुझाव दिए थे, ताकि शुरुआती पेंट होने के बाद लोड होने के अनुभव को बेहतर बनाया जा सके. हालांकि, ये मेट्रिक जटिल होती हैं, इन्हें समझाना मुश्किल होता है और अक्सर गलत होते हैं. इसका मतलब है कि ये अब भी पेज का मुख्य कॉन्टेंट लोड होने के बाद इसका पता नहीं लगा पाते हैं.
W3C वेब परफ़ॉर्मेंस वर्किंग ग्रुप की बातचीत और Google की ओर से की गई रिसर्च के आधार पर, हमें पता चला है कि किसी पेज का मुख्य कॉन्टेंट कब लोड होता है, यह मेज़र करने का सबसे सटीक तरीका यह देखना है कि सबसे बड़ा एलिमेंट कब रेंडर होता है.
एलसीपी क्या है?
एलसीपी, व्यूपोर्ट में दिखने वाले सबसे बड़े इमेज, टेक्स्ट ब्लॉक या वीडियो को रेंडर होने में लगने वाले समय की जानकारी देता है. यह इस बात से तय होता है कि उपयोगकर्ता ने पहली बार पेज पर कब नेविगेट किया था.
अच्छा एलसीपी स्कोर क्या होता है?
उपयोगकर्ताओं को अच्छा अनुभव देने के लिए, साइटों को 2.5 सेकंड या उससे कम के सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय होना चाहिए. यह पक्का करने के लिए कि आपके ज़्यादातर उपयोगकर्ताओं के लिए यह टारगेट पूरा हो रहा है, पेज लोड के 75वें प्रतिशत को मेज़र करना एक अच्छा थ्रेशोल्ड है. इसे मोबाइल और डेस्कटॉप डिवाइसों के हिसाब से सेगमेंट किया जाता है.
किन एलिमेंट को ध्यान में रखा जाता है?
फ़िलहाल, सबसे बड़े कॉन्टेंटफ़ुल पेंट एपीआई में बताए गए एलिमेंट के टाइप, सबसे बड़े कॉन्टेंटफ़ुल पेंट के लिए इस्तेमाल किए जाते हैं:
<img>
एलिमेंट (पहले फ़्रेम के प्रज़ेंटेशन में लगने वाले समय का इस्तेमाल, GIF या ऐनिमेशन वाले PNG जैसे ऐनिमेशन वाले कॉन्टेंट के लिए किया जाता है)<svg>
एलिमेंट में<image>
एलिमेंट<video>
एलिमेंट (वीडियो के लिए पोस्टर इमेज लोड होने में लगने वाले समय या पहले फ़्रेम के प्रज़ेंटेशन में लगने वाले समय का इस्तेमाल किया गया हो—इनमें से जो भी पहले हो)url()
फ़ंक्शन का इस्तेमाल करके लोड की गई बैकग्राउंड इमेज वाला एलिमेंट. यह सीएसएस ग्रेडिएंट के बजाय होता है- ब्लॉक-लेवल एलिमेंट, जिनमें टेक्स्ट नोड या इनलाइन-लेवल के अन्य टेक्स्ट एलिमेंट के चाइल्ड शामिल होते हैं.
ध्यान दें कि शुरुआत में चीज़ों को आसान रखने के लिए, एलिमेंट को इस सीमित सेट में सीमित रखा गया था. आने वाले समय में, इस बारे में रिसर्च की जाएगी कि इसमें ज़्यादा जानकारी जोड़ी जा सकती है. जैसे, <svg>
से जुड़ी पूरी सहायता.
एलसीपी मेज़रमेंट में कुछ एलिमेंट को ही शामिल किया जाता है. साथ ही, कुछ एलिमेंट को बाहर रखने के लिए, हेयुरिस्टिक्स का इस्तेमाल किया जाता है. ऐसा इसलिए किया जाता है, ताकि उपयोगकर्ताओं को "कॉन्टेंट नहीं" के तौर पर न दिखे. Chromium पर आधारित ब्राउज़र के लिए, इनमें ये शामिल हैं:
- ऐसे एलिमेंट जिनकी ओपैसिटी 0 है और जो उपयोगकर्ता को नहीं दिखते
- ऐसे एलिमेंट जो पूरे व्यूपोर्ट को कवर करते हैं और जिन्हें कॉन्टेंट के बजाय बैकग्राउंड माना जाता है
- प्लेसहोल्डर इमेज या ऐसी अन्य इमेज जिनका एन्ट्रापी कम है और जो शायद पेज के असली कॉन्टेंट को नहीं दिखाती हैं
ब्राउज़र इस अनुमान को बेहतर बनाते रहेंगे, ताकि हम उपयोगकर्ता की उस उम्मीद को पूरा कर सकें जो सबसे बड़े कॉन्टेंटफ़ुल एलिमेंट के बारे में है.
"कॉन्टेंटफ़ुल" के ये अनुभव, फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) की तकनीक से अलग हो सकते हैं, जिसमें प्लेसहोल्डर इमेज या पूरे व्यूपोर्ट की इमेज जैसे एलिमेंट शामिल हो सकते हैं. भले ही, वे एलसीपी उम्मीदवार होने की ज़रूरी शर्तें पूरी न करते हों. दोनों मेट्रिक के नाम में "contentful" का इस्तेमाल होने के बावजूद, इनका मकसद अलग-अलग है. एफ़सीपी, स्क्रीन पर कोई भी कॉन्टेंट पेंट होने पर और एलसीपी, मुख्य कॉन्टेंट पेंट होने पर मेज़र किया जाता है. इसलिए, एलसीपी को ज़्यादा चुनिंदा बनाया जाता है.
एलिमेंट का साइज़ कैसे तय किया जाता है?
आम तौर पर, एलसीपी के लिए रिपोर्ट किए गए एलिमेंट का साइज़, व्यूपोर्ट में उपयोगकर्ता को दिखने वाला साइज़ होता है. अगर एलिमेंट, व्यूपोर्ट के बाहर तक फैला हुआ है या किसी एलिमेंट को क्लिप किया गया है या उसमें दिखने वाला ओवरफ़्लो नहीं है, तो उन हिस्सों को एलिमेंट के साइज़ में नहीं गिना जाता.
जिन इमेज एलिमेंट का साइज़ उनके इंटिग्रल साइज़ से बदला गया है उनके लिए, दिखने वाला साइज़ या इंटिग्रल साइज़, दोनों में से जो भी साइज़ छोटा होगा उसे रिपोर्ट किया जाएगा.
टेक्स्ट एलिमेंट के लिए, एलसीपी सिर्फ़ उस सबसे छोटे रेक्टैंगल को ध्यान में रखता है जिसमें सभी टेक्स्ट नोड शामिल हो सकते हैं.
सभी एलिमेंट के लिए, एलसीपी में सीएसएस का इस्तेमाल करके लागू किए गए मार्जिन, पैडिंग या बॉर्डर को शामिल नहीं किया जाता.
एलसीपी की रिपोर्ट कब की जाती है?
वेब पेज अक्सर चरणों में लोड होते हैं. इस वजह से, हो सकता है कि पेज का सबसे बड़ा एलिमेंट बदल जाए.
इस संभावित बदलाव को मैनेज करने के लिए, ब्राउज़र पहले फ़्रेम को पेंट करने के तुरंत बाद, largest-contentful-paint
टाइप का PerformanceEntry
भेजता है. इससे, सबसे बड़े कॉन्टेंटफ़ुल एलिमेंट की पहचान की जाती है. हालांकि, इसके बाद, अगले फ़्रेम को रेंडर करने के बाद, जब भी सबसे बड़े कॉन्टेंट वाले एलिमेंट में बदलाव होगा, तब यह एक और PerformanceEntry
भेजेगा.
उदाहरण के लिए, टेक्स्ट और हीरो इमेज वाले पेज पर, ब्राउज़र शुरू में सिर्फ़ टेक्स्ट को रेंडर कर सकता है. इस दौरान, ब्राउज़र एक largest-contentful-paint
एंट्री भेजेगा, जिसकी element
प्रॉपर्टी से <p>
या <h1>
का रेफ़रंस मिल सकता है. बाद में, हीरो इमेज लोड होने के बाद, दूसरी largest-contentful-paint
एंट्री डिस्पैच की जाएगी और उसकी element
प्रॉपर्टी, <img>
का रेफ़रंस देगी.
किसी एलिमेंट को सबसे बड़े कॉन्टेंटफ़ुल एलिमेंट के तौर पर तब ही माना जा सकता है, जब वह रेंडर हो गया हो और उपयोगकर्ता को दिख रहा हो. जो इमेज अभी तक लोड नहीं हुई हैं उन्हें "रेंडर की गई" नहीं माना जाता. फ़ॉन्ट ब्लॉक की अवधि के दौरान, टेक्स्ट नोड भी वेब फ़ॉन्ट का इस्तेमाल नहीं कर रहे हैं. ऐसे मामलों में, किसी छोटे एलिमेंट को सबसे बड़े कॉन्टेंटफ़ुल एलिमेंट के तौर पर रिपोर्ट किया जा सकता है. हालांकि, बड़े एलिमेंट के रेंडर होने के बाद, एक और PerformanceEntry
बन जाता है.
देर से लोड होने वाली इमेज और फ़ॉन्ट के अलावा, नया कॉन्टेंट उपलब्ध होने पर, पेज में डीओएम में नए एलिमेंट जोड़े जा सकते हैं. अगर इनमें से कोई भी नया एलिमेंट, कॉन्टेंट वाले सबसे बड़े पुराने एलिमेंट से बड़ा है, तो एक नया PerformanceEntry
भी रिपोर्ट किया जाएगा.
अगर सबसे बड़े कॉन्टेंट वाले एलिमेंट को व्यूपोर्ट या डीओएम से हटा दिया जाता है, तो वह तब तक सबसे बड़ा कॉन्टेंट वाला एलिमेंट बना रहता है, जब तक कोई बड़ा एलिमेंट रेंडर नहीं किया जाता.
उपयोगकर्ता के पेज से इंटरैक्ट करने (टैप, स्क्रोल या बटन दबाने के ज़रिए) के तुरंत बाद, ब्राउज़र नई एंट्री की रिपोर्टिंग बंद कर देगा. ऐसा इसलिए होता है, क्योंकि उपयोगकर्ता के इंटरैक्ट करने से अक्सर पेज पर दिखने वाली चीज़ें बदल जाती हैं. यह बात खास तौर पर स्क्रोल करने पर ज़्यादा सच होती है.
विश्लेषण के लिए, आपको आंकड़ों की सेवा देने वाली कंपनी को सिर्फ़ हाल ही में भेजे गए PerformanceEntry
की जानकारी देनी चाहिए.
लोड होने में लगने वाला समय बनाम रेंडर होने में लगने वाला समय
सुरक्षा से जुड़ी वजहों से, क्रॉस-ऑरिजिन इमेज के लिए इमेज के रेंडर होने का टाइमस्टैंप नहीं दिखाया जाता. ऐसा उन इमेज के लिए किया जाता है जिनमें Timing-Allow-Origin
हेडर मौजूद नहीं होता. इसके बजाय, सिर्फ़ उनके लोड होने में लगने वाला समय दिखाया जाता है. ऐसा इसलिए किया जाता है, क्योंकि यह जानकारी कई अन्य वेब एपीआई से पहले से ही मिल जाती है.
इससे ऐसा हो सकता है कि वेब एपीआई, एफ़सीपी से पहले ही एलसीपी की रिपोर्ट कर दें. ऐसा नहीं है. यह सिर्फ़ सुरक्षा से जुड़ी पाबंदी की वजह से ऐसा दिखता है.
हमारा सुझाव है कि जहां भी हो सके वहां Timing-Allow-Origin
हेडर को सेट करें. इससे आपकी मेट्रिक ज़्यादा सटीक होंगी.
एलिमेंट के लेआउट और साइज़ में बदलाव कैसे मैनेज किए जाते हैं?
नई परफ़ॉर्मेंस एंट्री का हिसाब लगाने और उन्हें भेजने के परफ़ॉर्मेंस ओवरहेड को कम रखने के लिए, किसी एलिमेंट के साइज़ या पोज़िशन में बदलाव करने पर, एलसीपी के नए विकल्प जनरेट नहीं होते. व्यूपोर्ट में एलिमेंट के शुरुआती साइज़ और पोज़िशन को ही ध्यान में रखा जाता है.
इसका मतलब है कि शुरुआत में ऑफ़-स्क्रीन रेंडर की गई और फिर स्क्रीन पर ट्रांज़िशन की गई इमेज की रिपोर्ट नहीं की जा सकती. इसका यह भी मतलब है कि शुरुआत में व्यूपोर्ट में रेंडर किए गए ऐसे एलिमेंट जो बाद में नीचे की ओर धकेल दिए जाते हैं और व्यू से बाहर हो जाते हैं, वे अब भी अपने शुरुआती व्यूपोर्ट साइज़ को रिपोर्ट करेंगे.
उदाहरण
यहां कुछ लोकप्रिय वेबसाइटों पर सबसे बड़े एलिमेंट को रेंडर करने में लगने वाले समय के कुछ उदाहरण दिए गए हैं:
ऊपर दी गई दोनों टाइमलाइन में, कॉन्टेंट लोड होने पर सबसे बड़ा एलिमेंट बदल जाता है. पहले उदाहरण में, DOM में नया कॉन्टेंट जोड़ा गया है. इससे, सबसे बड़ा एलिमेंट बदल जाता है. दूसरे उदाहरण में, लेआउट में बदलाव हो गया है और जो कॉन्टेंट पहले सबसे बड़ा था उसे व्यूपोर्ट से हटा दिया जाता है.
हालांकि, अक्सर ऐसा होता है कि पेज पर पहले से मौजूद कॉन्टेंट की तुलना में, देरी से लोड होने वाला कॉन्टेंट ज़्यादा होता है, लेकिन ज़रूरी नहीं है कि ऐसा हो. अगले दो उदाहरणों में, पेज के पूरी तरह से लोड होने से पहले होने वाले एलसीपी को दिखाया गया है.
पहले उदाहरण में, Instagram का लोगो अपेक्षाकृत जल्दी लोड होता है और अन्य कॉन्टेंट के धीरे-धीरे दिखने के बावजूद, यह सबसे बड़ा एलिमेंट बना रहता है. Google Search के नतीजों वाले पेज के उदाहरण में, सबसे बड़ा एलिमेंट टेक्स्ट का पैराग्राफ़ है. यह किसी भी इमेज या लोगो के लोड होने से पहले दिखता है. सभी अलग-अलग इमेज इस पैराग्राफ़ से छोटी हैं, इसलिए लोड होने की पूरी प्रोसेस के दौरान यह सबसे बड़ा एलिमेंट रहेगा.
एलसीपी को मेज़र करने का तरीका
एलसीपी को लैब में या फ़ील्ड में मेज़र किया जा सकता है. यह इन टूल में उपलब्ध है:
फ़ील्ड टूल
- Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट
- PageSpeed Insights
- Search Console (वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट)
web-vitals
JavaScript लाइब्रेरी
लैब टूल
JavaScript में एलसीपी मेज़र करना
JavaScript में एलसीपी मेज़र करने के लिए, Largest Contentful Paint API का इस्तेमाल किया जा सकता है. नीचे दिए गए उदाहरण में, एक ऐसा 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
वैल्यू, LCP वैल्यू होती है. हालांकि, ऐसा हमेशा नहीं होता. एलसीपी को मेज़र करने के लिए, सभी largest-contentful-paint
एंट्री मान्य नहीं हैं.
नीचे दिए गए सेक्शन में, एपीआई रिपोर्ट और मेट्रिक की गिनती के तरीके के बीच अंतर बताया गया है.
मेट्रिक और एपीआई के बीच अंतर
- एपीआई, बैकग्राउंड टैब में लोड किए गए पेजों के लिए
largest-contentful-paint
एंट्री भेजेगा. हालांकि, एलसीपी का हिसाब लगाते समय उन पेजों को अनदेखा किया जाना चाहिए. - किसी पेज के बैकग्राउंड में चलने के बाद, एपीआई
largest-contentful-paint
एंट्री को भेजना जारी रखेगा. हालांकि, एलसीपी को कैलकुलेट करते समय इन एंट्री को अनदेखा किया जाना चाहिए. एलिमेंट को सिर्फ़ तब माना जा सकता है, जब पेज पूरे समय फ़ोरग्राउंड में रहा हो. - जब पेज को बैक/फ़ॉरवर्ड कैश से वापस लाया जाता है, तो एपीआई
largest-contentful-paint
एंट्री की रिपोर्ट नहीं करता. हालांकि, इन मामलों में एलसीपी को मेज़र किया जाना चाहिए, क्योंकि उपयोगकर्ताओं को इन पेजों पर आने का अनुभव अलग-अलग पेज पर आने जैसा लगता है. - एपीआई, iframe में मौजूद एलिमेंट को शामिल नहीं करता. हालांकि, मेट्रिक में इन एलिमेंट को शामिल किया जाता है, क्योंकि ये पेज के उपयोगकर्ता अनुभव का हिस्सा होते हैं. अगर किसी पेज पर iframe में LCP है, तो यह 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()
के सोर्स कोड को देखें.
अगर सबसे बड़ा एलिमेंट सबसे ज़रूरी नहीं है, तो क्या करना चाहिए?
कुछ मामलों में, पेज पर सबसे ज़्यादा अहम एलिमेंट (या एलिमेंट), सबसे बड़े एलिमेंट से अलग होता है. ऐसे में, हो सकता है कि डेवलपर इन दूसरे एलिमेंट के रेंडर होने में लगने वाले समय को मेज़र करने में ज़्यादा दिलचस्पी रखें. कस्टम मेट्रिक से जुड़े लेख में बताए गए तरीके से, Element Timing API का इस्तेमाल करके ऐसा किया जा सकता है.
एलसीपी को बेहतर बनाने का तरीका
एलसीपी को ऑप्टिमाइज़ करने के बारे में पूरी गाइड उपलब्ध है. इसमें, फ़ील्ड में एलसीपी टाइम की पहचान करने और ड्रिल-डाउन करने और उन्हें ऑप्टिमाइज़ करने के लिए लैब डेटा का इस्तेमाल करने का तरीका बताया गया है.
अन्य संसाधन
- Chrome में परफ़ॉर्मेंस मॉनिटरिंग से मिले सबक. इसे performance.now() पर ऐनी सलिवन ने 2019 में लिखा था
बदलावों का लॉग
कभी-कभी, मेट्रिक को मेज़र करने के लिए इस्तेमाल किए जाने वाले एपीआई में गड़बड़ियां मिलती हैं. साथ ही, कभी-कभी मेट्रिक की परिभाषाओं में भी गड़बड़ियां मिलती हैं. इस वजह से, कभी-कभी बदलाव करने ज़रूरी होते हैं. ये बदलाव आपकी इंटरनल रिपोर्ट और डैशबोर्ड में सुधार या रिग्रेशन के तौर पर दिख सकते हैं.
इसे मैनेज करने में आपकी मदद करने के लिए, इन मेट्रिक को लागू करने या उनकी परिभाषा में किए गए सभी बदलाव, इस बदलावों की सूची में दिखाए जाएंगे.
अगर आपको इन मेट्रिक के बारे में कोई सुझाव, शिकायत या राय देनी है, तो web-vitals-feedback Google ग्रुप में जाकर ऐसा किया जा सकता है.