किसी पेज के सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) को बेहतर बनाना मुश्किल हो सकता है. इसमें अक्सर कई मूविंग पार्ट और ट्रेड-ऑफ़ शामिल होते हैं. यह पोस्ट, वेब पर मौजूद असल पेज लोड से जुड़े फ़ील्ड डेटा के बारे में बताती है. इससे यह तय करने में मदद मिलती है कि डेवलपर को ऑप्टिमाइज़ेशन की अपनी कोशिशों को कहां फ़ोकस करना चाहिए.
एलसीपी से जुड़ी क्लासिक सलाह: अपनी इमेज का साइज़ कम करें!
वेब पर मौजूद ज़्यादातर पेजों के लिए, एलसीपी एलिमेंट एक इमेज होता है. इसलिए, यह मान लेना आम बात है कि एलसीपी को बेहतर बनाने का सबसे अच्छा तरीका, अपनी एलसीपी इमेज को ऑप्टिमाइज़ करना है.
एलसीपी के लॉन्च होने के करीब पांच साल बाद, पब्लिशरों के लिए हमेशा हेडलाइन से जुड़ी सलाह ही अहम रही है. पक्का करें कि आपकी इमेज का साइज़ सही है. साथ ही, उन्हें ज़रूरत के मुताबिक कंप्रेस किया गया है. जब आप वहां हों, तब 21वीं सदी के इमेज फ़ॉर्मैट का इस्तेमाल करें. यहां तक कि लाइटहाउस में ऐसे तीन अलग-अलग ऑडिट भी मौजूद हैं, जो इन सुझावों को लागू करते हैं.
इसकी एक सामान्य वजह यह है कि अतिरिक्त बाइट को मापना आसान होता है और इमेज कंप्रेस करने वाले टूल का सुझाव देना आसान होता है. आपके बिल्ड और डिप्लॉयमेंट पाइपलाइन के आधार पर, इन्हें लागू करना भी आसान हो सकता है.
अगर हां, तो ऐसा करें! अपने उपयोगकर्ताओं को कम बाइट भेजना करीब-करीब हमेशा फ़ायदेमंद होता है. वेब पर ऐसी कई साइटें हैं जो अब भी ग़ैर-ज़रूरी बड़ी इमेज दिखा रही हैं. इन्हें बुनियादी तौर पर कंप्रेस करने से भी समस्या ठीक हो जाएगी.
हालांकि, जब हमने Chrome में उपयोगकर्ताओं के लिए फ़ील्ड परफ़ॉर्मेंस के डेटा को देखना शुरू किया, ताकि यह देखा जा सके कि एलसीपी में लगने वाला समय आम तौर पर कहां खर्च हो रहा है, तो हमने पाया कि इमेज डाउनलोड होने में लगने वाला समय बहुत ज़्यादा नहीं होता है.
इसके बजाय, एलसीपी के दूसरे हिस्से एक बड़ी समस्या है.
एलसीपी सब-पार्ट का ब्रेकडाउन
यह समझने के लिए कि एलसीपी को बेहतर बनाने के सबसे बड़े मौके कौनसे थे, हमने एलसीपी के सब-पार्ट्स पर गौर किया. इस बारे में एलसीपी ऑप्टिमाइज़ करें सेक्शन में बताया गया है.
हर पेज और हर फ़्रेमवर्क के लोड होने और उसे दिखाने के लिए, अलग तरीका अपनाया जा सकता है. इससे, पेज का एलसीपी एलिमेंट बन जाता है. हालांकि, हर पेज को इन सब-पार्ट्स में बांटा जा सकता है:
उस लेख के कोट में, इसके सब-पार्ट्स हैं:
- टाइम टू फ़र्स्ट बाइट (TTFB)
- उपयोगकर्ता के पेज लोड करना शुरू करने से लेकर ब्राउज़र के लोड होने तक का समय एचटीएमएल दस्तावेज़ के रिस्पॉन्स का पहला बाइट मिलता है.
- संसाधन लोड होने में देरी
- टीटीएफ़बी और ब्राउज़र के एलसीपी संसाधन लोड होना शुरू होने के बीच का समय. अगर आपने
एलसीपी एलिमेंट को रेंडर करने के लिए, रिसॉर्स लोड की ज़रूरत नहीं होती. फ़िलहाल,
0है. - संसाधन लोड की अवधि
- एलसीपी संसाधन को लोड होने में लगने वाला समय. अगर एलसीपी
एलिमेंट को रेंडर करने के लिए संसाधन लोड की ज़रूरत नहीं होती, यह समय
0है. - एलिमेंट के रेंडर होने में देरी
- एलसीपी संसाधन के लोड होने और एलसीपी एलिमेंट के लोड होने के बीच का समय पूरी तरह रेंडर हो जाएगा.
नेविगेशन का रीयल परफ़ॉर्मेंस डेटा
| एलसीपी रेटिंग | TTFB (मिलीसेकंड) | इमेज लोड होने में देरी (मि॰से॰) | इमेज लोड होने की अवधि (मि॰से॰) | रेंडर होने में लगा समय (मि॰से॰) |
|---|---|---|---|---|
| अच्छा | 600 | 350 | 160 | 230 |
| सुधार की ज़रूरत है | 1,360 | 720 | 270 | 310 |
| खराब | 2,270 | 1,290 | 350 | 360 |
इस पोस्ट के लिए, हमने Chrome में सबरिसॉर्स इमेज एलसीपी के साथ पेज नेविगेशन के डेटा का इस्तेमाल किया है, ताकि एलसीपी सब-पार्ट पर नज़र डाली जा सके. हमने इस तरह के डेटा पर पहले भी ध्यान दिया है. हालांकि, फ़ील्ड डेटा की मदद से यह कभी नहीं देखा कि पेज के एलसीपी के लिए इंतज़ार करते हुए, उपयोगकर्ता अपना समय कहां खर्च कर रहे हैं.
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट की तरह ही, हमने CrUX डेटासेट में हर ऑरिजिन के लिए, हर एलसीपी सब-पार्ट का 75वां पर्सेंटाइल (p75) लिया. इस वजह से, p75 वैल्यू को चार डिस्ट्रिब्यूशन किया गया (हर सब-पार्ट के लिए एक). इन डिस्ट्रिब्यूशन की खास जानकारी देने के लिए, हमने चार एलसीपी सब-पार्ट में से हर एक के लिए, सभी ऑरिजिन में उन वैल्यू के मीडियन का इस्तेमाल किया.
आखिर में, हम ऑरिजिन को इस आधार पर बकेट में बांटते हैं कि उनमें "अच्छा", "सुधार की ज़रूरत है" या "खराब" है एलसीपी 75वें पर्सेंटाइल पर है. इससे यह पता चलता है कि अच्छे एलसीपी वाले ऑरिजिन और खराब एलसीपी वाले ऑरिजिन में क्या अंतर है.
क्या आपको एलसीपी इमेज का साइज़ कम करना है? इस बार डेटा के साथ
लोड होने की अवधि से यह पता चलता है कि एलसीपी संसाधन को फ़ेच करने में कितना समय लगता है. उदाहरण के लिए, एक इमेज. आम तौर पर, यह समय इमेज में मौजूद बाइट की संख्या के अनुपात में होता है. इसलिए, बाइट की उस संख्या को कम करने के लिए परफ़ॉर्मेंस से जुड़ी सभी सलाह.
ऊपर दिए गए ग्राफ़ में, समय कहां बीत रहा है, इस बात पर गौर करते समय एक बात सबसे अलग लग सकती है कि इमेज लोड होने में ज़्यादा समय नहीं लग रहा है. असल में, यह सभी एलसीपी बकेट में सबसे छोटा एलसीपी सब-पार्ट है. अच्छे-एलसीपी वाले ऑरिजिन के मुकाबले खराब एलसीपी ऑरिजिन के लिए, लोड होने में लगने वाला समय ज़्यादा होता है. हालांकि, लोड होने में अब भी उस जगह पर जाने में ज़्यादा समय नहीं लग रहा है.
खराब एलसीपी वाले ज़्यादातर ऑरिजिन, अपने p75 एलसीपी समय का 10% से कम समय, एलसीपी इमेज को डाउनलोड करने में खर्च करते हैं.
हां, आपको यह पक्का करना चाहिए कि आपकी इमेज ऑप्टिमाइज़ की गई हों. हालांकि, यह एलसीपी को बेहतर बनाने का सिर्फ़ एक हिस्सा है. साथ ही, इस डेटा से साफ़ है कि वेब पर सामान्य ऑरिजिन के लिए, एलसीपी को मिलीसेकंड में मिलने वाला संभावित फ़ायदा बहुत कम होता है, भले ही कंप्रेशन स्कीम कितनी भी बेहतरीन हो.
एक और अहम बात: एक समय पर लोड होने की धीमी अवधि के लिए, आम तौर पर मोबाइल डिवाइस और मोबाइल नेटवर्क की क्वालिटी को ज़िम्मेदार माना जाता था. एक समय था, जब हमें लगता था कि किसी सामान्य फ़ोन को वायर वाले कनेक्शन पर उसी इमेज को डेस्कटॉप मशीन पर डाउनलोड करने में कई बार ज़्यादा समय लगेगा. डेटा से पता चलता है कि अब ऐसा नहीं है. खराब एलसीपी वाले ऑरिजिन के लिए, डेस्कटॉप की तुलना में मोबाइल पर p75 इमेज लोड होने की मीडियन अवधि सिर्फ़ 20% धीमी होती है.
टाइम टू फ़र्स्ट बाइट (TTFB)
नेटवर्क का अनुरोध करने वाले नेविगेशन के लिए, TTFB को हमेशा कुछ समय लगेगा. डीएनएस लुकअप और कनेक्शन को शुरू करने में समय लगता है. और आप भौतिकी से आगे नहीं बढ़ सकते: किसी सर्वर तक पहुंचने के लिए तारों और ऑप्टिकल केबल के ज़रिए वास्तविक दुनिया का सफ़र करना होता है, उसके बाद प्रतिक्रिया के चलते आपको वापस जाना पड़ता है. यहां तक कि अच्छे एलसीपी वाला मीडियन ऑरिजिन, अपने 75वें पर्सेंटाइल पर टीटीएफ़बी पर आधे सेकंड से ज़्यादा खर्च करता है.
हालांकि, अच्छे और खराब एलसीपी ऑरिजिन के बीच टीटीएफ़बी में अंतर होने से, इसमें सुधार हो सकता है. खराब एलसीपी वाले कम से कम आधे ऑरिजिन के लिए, 2,270 मिलीसेकंड वाला p75 TTFB अकेले इस बात की गारंटी देता है कि p75 एलसीपी, 2.5 सेकंड "अच्छा" से ज़्यादा तेज़ नहीं हो सकता. थ्रेशोल्ड. इस दौरान थोड़ा-बहुत भी छोटा सा प्रतिशत कम होने पर भी एलसीपी में काफ़ी सुधार होगा.
भले ही, आप भौतिक विज्ञान को पीछे न छोड़ पाएं, लेकिन कुछ ऐसे हैं जो किए जा सकते हैं. उदाहरण के लिए, अगर आपके उपयोगकर्ता अक्सर आपके सर्वर से अलग जगह पर रहते हैं, तो सीडीएन से आपका कॉन्टेंट उनके और करीब आ सकता है.
ज़्यादा जानकारी के लिए, टीटीएफ़बी को ऑप्टिमाइज़ करने से जुड़ी गाइड देखें.
संसाधन लोड में देरी, अनदेखी की गई धीमी एलसीपी समस्या
अगर TTFB को बेहतर बनाया जा सकता है, लेकिन कोई भी सुधार भौतिकी पर निर्भर करता है, तो संसाधन लोड होने में देरी हो सकती है, जो केवल आपके सर्विंग आर्किटेक्चर के आधार पर होती है.
यह सब-पार्ट, एचटीएमएल रिस्पॉन्स (टीटीएफ़बी) के पहले बाइट के आने से लेकर, ब्राउज़र के एलसीपी इमेज के लिए अनुरोध शुरू करने तक के समय को मापता है. हम कई सालों से इस बात पर ध्यान दे रहे हैं कि एलसीपी इमेज को डाउनलोड होने में कितना समय लगता है. हालांकि, हमने अक्सर ब्राउज़र से डाउनलोड शुरू करने से पहले ही बर्बाद हो चुके समय को अनदेखा कर दिया है.
खराब एलसीपी वाली मीडियन साइट, एलसीपी इमेज को डाउनलोड होने में करीब चार गुना खर्च करती है, जबकि एलसीपी इमेज डाउनलोड होने के लिए इंतज़ार करती है. टीटीएफ़बी और इमेज अनुरोध के बीच 1.3 सेकंड का इंतज़ार करना पड़ता है. यह एक सब-पार्ट में खर्च किए गए 2.5 सेकंड के एलसीपी बजट का आधे से ज़्यादा हिस्सा है.
आम तौर पर, डिपेंडेंसी चेन की वजह से लोड होने में ज़्यादा समय लगता है. सबसे आसान जगह पर एक स्टाइल शीट लोड होती है, जो ब्राउज़र के लेआउट करने के बाद एक बैकग्राउंड इमेज सेट करती है, जो एलसीपी बन जाएगी. ये सभी चरण, ब्राउज़र को एलसीपी इमेज डाउनलोड करने से पहले ही पूरे होने चाहिए.
एचटीटीपी संग्रह का सार्वजनिक क्रॉल डेटा इस्तेमाल करना, जो "शुरू करने वाले" को रिकॉर्ड करता है एचटीएमएल दस्तावेज़ से लेकर एलसीपी इमेज के नेटवर्क अनुरोधों की चेन को साफ़ तौर पर देखा जा सकता है. अनुरोध चेन की लंबाई के साथ धीमी एलसीपी इमेज के बीच का संबंध साफ़ तौर पर देखा जा सकता है.
सबसे ज़रूरी है कि ब्राउज़र को जल्द से जल्द यह जानकारी दी जाए कि एलसीपी क्या होगा, ताकि पेज के लेआउट में जगह उपलब्ध होने से पहले ही यह उसे लोड करना शुरू कर सके. इसके लिए कुछ टूल उपलब्ध हैं, जैसे कि एचटीएमएल में क्लासिक <img> टैग. इससे प्रीलोड स्कैनर, इसे तुरंत ढूंढ सकता है और इसे डाउनलोड करना शुरू कर सकता है. इसके अलावा, यह उन इमेज के लिए <link rel="preload"> टैग (या एचटीटीपी हेडर) भी उपलब्ध कराता है जो <img> नहीं होंगे.
ब्राउज़र को यह तय करने में मदद करना भी ज़रूरी है कि किन संसाधनों को प्राथमिकता देनी है. खास तौर पर, ऐसा तब होता है, जब आपका पेज, पेज लोड होने के दौरान कई अनुरोध कर रहा हो. इसकी वजह यह है कि ब्राउज़र को अक्सर यह पता नहीं चलता कि उनमें से कई रिसॉर्स लोड होने और लेआउट होने के बाद, एलसीपी एलिमेंट क्या होगा. fetchpriority="high" एट्रिब्यूट के साथ संभावित एलसीपी एलिमेंट की जानकारी देने और loading="lazy" से बचने का ध्यान रखने से, ब्राउज़र को यह समझने में मदद मिलती है कि रिसॉर्स तुरंत लोड हो रहा है.
लोड में देरी को ऑप्टिमाइज़ करने के बारे में ज़्यादा सलाह पढ़ें.
रेंडर होने में देरी
रेंडर होने में लगने वाले समय से यह पता चलता है कि ब्राउज़र पर एलसीपी इमेज लोड होने और उसके तैयार होने के बाद से कितने समय में, इमेज के रेंडर होने में लगने वाला समय कम हो जाता है. हालांकि, किसी वजह से इसे स्क्रीन पर दिखने में थोड़ा समय लग सकता है. कभी-कभी इमेज तैयार होने पर, यह एक लंबा टास्क होता है, जो मुख्य थ्रेड को ब्लॉक कर देता है. अन्य मामलों में, यह यूज़र इंटरफ़ेस (यूआई) का विकल्प हो सकता है, जिसमें छिपे हुए एलिमेंट को देखने का विकल्प होता है.
वेब पर आम तौर पर ऑरिजिन के लिए, रेंडर होने में ज़्यादा समय नहीं लगता. हालांकि, ऑप्टिमाइज़ेशन के दौरान, कभी-कभी अन्य सब-पार्ट में बिताए गए समय की वजह से रेंडर होने में देरी हो सकती है. उदाहरण के लिए, अगर कोई पेज जल्दी से उपलब्ध होने के लिए एलसीपी इमेज को पहले से लोड करना शुरू करता है, तो लोड होने में ज़्यादा समय नहीं लगेगा. हालांकि, अगर पेज इमेज दिखाने के लिए तैयार नहीं है, जैसे कि रेंडर ब्लॉक करने वाली किसी बड़ी स्टाइल शीट या क्लाइंट-साइड रेंडरिंग ऐप्लिकेशन से, जिसे किसी भी चीज़ के दिखने से पहले सभी JavaScript को लोड करना पड़ता है, तो एलसीपी को रेंडर होने में लगने वाला समय से ज़्यादा समय लगेगा. यही वजह है कि एलसीपी के मामले में, सर्वर साइड रेंडरिंग या स्टैटिक एचटीएमएल का अक्सर फ़ायदा होता है.
अगर आपके कॉन्टेंट पर असर पड़ा है, तो रेंडर में देरी को ऑप्टिमाइज़ करने के बारे में ज़्यादा सलाह पढ़ें.
उन सभी उप-भागों की जाँच करें
यह साफ़ है कि एलसीपी को असरदार तरीके से ऑप्टिमाइज़ करने के लिए, डेवलपर को पेज लोड होने का पूरा ध्यान रखना होगा, न कि सिर्फ़ इमेज को ऑप्टिमाइज़ करने पर. एलसीपी को ध्यान में रखते हुए समय-समय पर जांच करें, क्योंकि इसमें सुधार करने के काफ़ी मौके हो सकते हैं.
फ़ील्ड में इस डेटा को इकट्ठा करने के लिए, वेब-वाइटल लाइब्रेरी के एट्रिब्यूशन बिल्ड में, एलसीपी सब-पार्ट के समय की जानकारी शामिल होती है. Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट (CrUX) में अभी यह पूरा डेटा शामिल नहीं है. हालांकि, इसमें TTFB और एलसीपी के लिए एंट्री मौजूद हैं. इसलिए, यह एक शुरुआत है. हमें उम्मीद है कि हम आने वाले समय में, CrUX में इस पोस्ट के लिए इस्तेमाल किया गया डेटा शामिल कर पाएंगे. इस बारे में ज़्यादा खबरें पाने के लिए हमारे साथ बने रहें.
एलसीपी सब-पार्ट्स की स्थानीय तौर पर जांच करने के लिए, वेब की परफ़ॉर्मेंस की अहम जानकारी देने वाले एक्सटेंशन या इस लेख में दिए गए JavaScript स्निपेट का इस्तेमाल करें. लाइटहाउस "सबसे बड़े कॉन्टेंटफ़ुल पेंट एलिमेंट" में ब्रेकडाउन भी शामिल है ऑडिट. DevTools के परफ़ॉर्मेंस पैनल में, एलसीपी सब-पार्ट की सलाह देखें. यह सुविधा जल्द ही उपलब्ध होगी.