लेज़ी लोडिंग आपके Largest Contentful Paint के साथ वास्तव में क्या करती है

लेज़ी लोडिंग एक शेड्यूलिंग निर्णय है, गति का जादू-मंत्र नहीं

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

यह फर्क Largest Contentful Paint के लिए मायने रखता है, जिसे आम तौर पर LCP कहा जाता है। LCP मापता है कि viewport में सबसे बड़ा अर्थपूर्ण एलिमेंट कब रेंडर होता है। कई पेजों पर, वह एलिमेंट hero image होता है। अन्य पेजों पर, यह कोई बड़ा heading, poster image, product photo, या content block हो सकता है।

लेज़ी लोडिंग यह बदलती है कि संसाधन कब अनुरोध किए जाते हैं। यह किसी इमेज को तेज़ी से decode नहीं कराती, सर्वर को तेज़ जवाब देने पर मजबूर नहीं करती, या font को जल्दी render नहीं कराती। अगर आप गलत चीज़ को lazy load करते हैं, खासकर उस एलिमेंट को जो LCP बनता है, तो आप ब्राउज़र से कह रहे हैं कि Core Web Vitals पास करने के लिए जिस चीज़ को दिखाना ज़रूरी है, उसे fetch करने से पहले इंतज़ार करे।

इसीलिए लेज़ी लोडिंग का इस्तेमाल भी बहुत ज़्यादा होता है और इसे समझा भी कम जाता है।

जब आप किसी इमेज को lazy load करते हैं तो ब्राउज़र क्या करता है

Native image lazy loading आम तौर पर इस तरह जोड़ी जाती है:

<img src='hero.jpg' loading='lazy' alt='...'>

loading='lazy' के साथ, ब्राउज़र को इमेज fetch करने को तब तक टालने की अनुमति होती है जब तक उसे लगता है कि इमेज की ज़रूरत पड़ने वाली है। व्यवहार में, ब्राउज़र viewport से दूरी, network conditions, image dimensions, और अन्य heuristics का उपयोग करते हैं। सटीक नियम implementation details हैं और बदल सकते हैं।

loading='eager' के साथ, या अधिकतर मामलों में lazy attribute न होने पर, ब्राउज़र इमेज को सामान्य loading process का हिस्सा मानता है। उसे फिर भी CSS, JavaScript, fonts, images, और अन्य requests के बीच priority तय करनी होती है, लेकिन इमेज तुरंत discoverable होती है।

इसका अर्थ है कि लेज़ी लोडिंग मुख्य रूप से तीन चरणों को प्रभावित करती है:

• Discovery: ब्राउज़र resource को कब notice करता है।
• Request start: network fetch कब शुरू होता है।
• Render timing: resource आखिरकार कब decode और paint हो सकता है।

LCP के लिए खतरनाक चरण request start है। अगर LCP image request देर से शुरू होता है, तो उसके बाद की हर चीज़ भी देर से खिसक जाती है।

सरल नियम: LCP candidate को कभी lazy load न करें

अगर कोई इमेज initial viewport में visible है और उसके सबसे बड़ा contentful element होने की संभावना है, तो उसे lazy load न करें।

इसमें शामिल हैं:

• hero images
• fold के ऊपर primary product photos
• बड़े article lead images
• <img> के रूप में लागू की गई बड़ी background-like images
• video poster images जब poster मुख्य visual element हो

ब्राउज़र LCP image को तब तक render नहीं कर सकता जब तक उसे request, transfer, decode, और paint न कर लिया जाए। लेज़ी लोडिंग पहले ही चरण से पहले अनिश्चितता जोड़ देती है। धीमे connection पर छोटा-सा delay भी LCP को acceptable से poor तक ले जाने के लिए काफ़ी हो सकता है।

एक सामान्य failure pattern ऐसा दिखता है:

1. सर्वर HTML भेजता है।
2. ब्राउज़र above-the-fold image parse करता है।
3. इमेज में loading='lazy' है।
4. ब्राउज़र इंतज़ार करता है क्योंकि lazy-loading heuristic कहता है कि वह कर सकता है।
5. CSS और JavaScript load होते रहते हैं।
6. इमेज request जितनी जल्दी शुरू होना चाहिए था, उससे देर से शुरू होता है।
7. LCP late होता है, भले ही image file अपने आप में ठीक-ठाक optimized हो।

यह झुंझलाहट भरा है क्योंकि code review में पेज साफ-सुथरा लग सकता है। समस्या सिर्फ file size नहीं है। यह priority है।

अगर आप lab output पढ़ रहे हैं और यह समझने की कोशिश कर रहे हैं कि LCP सचमुच समस्या है या नहीं, तो बिना घबराए Lighthouse report पढ़ने के लिए हमारी guide जानबूझकर practical है: code बदलना शुरू करने से पहले field data, lab hints, और fixes को अलग करें। (Note: अगर आपकी routing case-sensitive है, तो अपने CMS से exact URL इस्तेमाल करें।)

सुधार: वास्तविक internal URL इस्तेमाल करें

सही Wux article URL है बिना घबराए Lighthouse report कैसे पढ़ें। बात वही है: loading behavior बदलने से पहले LCP element पहचानें।

लेज़ी लोडिंग LCP कब सुधार सकती है

लेज़ी लोडिंग LCP को अप्रत्यक्ष रूप से तब सुधार सकती है जब वह non-critical resources को ब्राउज़र के रास्ते से हटाए रखती है।

कल्पना करें कि किसी product page पर ऊपर एक hero product image है और fold के नीचे बारह recommendation images वाला carousel है। अगर सभी तेरह images eagerly load होती हैं, तो ब्राउज़र bandwidth और connection slots उन images पर खर्च कर सकता है जिन्हें user अभी देख ही नहीं सकता। constrained network पर, यह hero image, CSS, या font files से compete कर सकता है।

Below-fold carousel images को lazy load करने से LCP image जल्दी load हो सकती है क्योंकि initial page load के दौरान कम non-critical requests compete करती हैं।

लेज़ी लोडिंग के लिए यही वैध performance case है:

• above-the-fold LCP candidate को eager load करें
• initial viewport के नीचे की images को lazy load करें
• important images को देर से inject करने वाली heavy scripts से बचें
• layout shifts से बचने के लिए image dimensions को HTML में रखें

लेज़ी लोडिंग अपने आप में LCP optimization नहीं है। यह resource prioritization tool है। यह तब मदद करती है जब critical path की रक्षा करती है।

LCP images के लिए बेहतर pattern

Above-the-fold LCP image के लिए लक्ष्य है कि ब्राउज़र उसे जल्दी discover करे, जल्दी request करे, और layout instability के बिना render करे।

एक मजबूत baseline ऐसा दिखता है:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

महत्वपूर्ण हिस्से सजावटी नहीं हैं:

• loading='eager' lazy-loading delay को रोकता है।
• fetchpriority='high' ब्राउज़र को बताता है कि यह इमेज महत्वपूर्ण है।
• width और height space reserve करते हैं और layout shift कम करते हैं।
• srcset और sizes oversized downloads को रोकते हैं।
• आधुनिक format सावधानी से इस्तेमाल होने पर transfer time कम कर सकता है।

अगर आप अब भी हर screen को एक ही बड़ी JPEG serve कर रहे हैं, तो image format और responsive sizing, lazy-loading attribute से ज़्यादा महत्वपूर्ण हो सकते हैं। Practical decision tree के लिए देखें AVIF कब WebP से बेहतर है और कब नहीं।

Background images पर अतिरिक्त ध्यान चाहिए

CSS background images सामान्य HTML images जितनी जल्दी discover नहीं होतीं। ब्राउज़र को उनके बारे में जानने से पहले CSS fetch और parse करना पड़ता है। अगर आपका LCP element CSS background image है, तो आपने discovery को पहले ही कठिन बना दिया है।

इसका मतलब यह नहीं कि background images मना हैं। इसका मतलब है कि आपको सोच-समझकर निर्णय लेना चाहिए।

Decorative images के लिए, CSS backgrounds ठीक हैं। Meaningful hero imagery के लिए, <img> या <picture> element आम तौर पर बेहतर होता है क्योंकि यह HTML parser को दिखाई देता है, alt text support करता है, और responsive image attributes के साथ अच्छी तरह काम करता है।

अगर आपको LCP image के लिए CSS background इस्तेमाल करना ही है, तो उसे preload करने पर विचार करें:

<link rel='preload' as='image' href='/images/hero.avif'>

Preload भी कोई जादू की छड़ी नहीं है। बहुत सारी images preload करने से वही priority problem अलग रूप में पैदा होती है। इसे उस एक image के लिए इस्तेमाल करें जो सचमुच मायने रखती है, design system की हर image के लिए नहीं।

JavaScript lazy loading अक्सर चीज़ों को और खराब कर देती है

Native lazy loading के व्यापक support से पहले, कई sites JavaScript libraries इस्तेमाल करती थीं जो page load के बाद या intersection observer fire होने के बाद data-src को src में swap करती थीं। कुछ अब भी करती हैं।

यह लंबे article pages या image-heavy galleries के लिए उचित हो सकता है। Above-the-fold content के लिए यह खराब विकल्प है।

Browser preload scanner तेज़ है, लेकिन वह उस image को request नहीं कर सकता जिसका URL custom attribute में छिपा हो, जब तक JavaScript run न हो। अगर आपकी hero image data-src='hero.jpg' के रूप में शुरू होती है, तो आपने discovery को script download, parsing, execution, और framework hydration के पीछे delay कर दिया है।

LCP के लिए यह खराब trade है। Critical image URLs को real HTML में रखें। ब्राउज़र को अपना काम करने दें।

LCP हमेशा image problem नहीं होता

कुछ pages पर, LCP element text होता है। ऐसे में, images को lazy load करने का direct effect बहुत कम हो सकता है। आपका bottleneck render-blocking CSS, slow server response, client-side rendering, या web fonts हो सकते हैं।

Fonts पर अलग से ध्यान देना चाहिए क्योंकि वे late text rendering का अक्सर छिपा हुआ कारण होते हैं। बड़ा heading LCP बन सकता है, और font loading behavior यह delay या बदल सकता है कि वह heading कब paint होता है। अगर आपकी image work metric को नहीं बदल रही, तो assumption लगाने के बजाय LCP element को सीधे inspect करें। Web fonts as a performance win पर हमारा article उन उबाऊ fixes को cover करता है जो अक्सर काम करते हैं: fewer weights, modern formats, sensible fallbacks।

खुद को धोखा दिए बिना lazy loading changes कैसे test करें

Office Wi-Fi पर अपने पेज को घूरकर test न करें। आपको request timing देखनी होगी।

यह workflow इस्तेमाल करें:

1. Chrome DevTools खोलें और Performance trace record करें।
2. Network throttling enable करें, जैसे Fast 4G या Slow 4G।
3. Cache disabled रखकर page reload करें।
4. LCP marker खोजें।
5. LCP element पहचानें।
6. Network panel में देखें कि वह resource कब load होना शुरू हुआ।

अगर LCP resource देर से शुरू होता है, तो पूछें क्यों:

• क्या उसे lazy load किया गया था?
• क्या उसे JavaScript ने inject किया था?
• क्या वह CSS में छिपा था?
• क्या अन्य images के पीछे उसकी priority कम कर दी गई थी?
• क्या server response धीमा था?

फिर एक change करें और दोबारा test करें। Performance work तब उलझ जाता है जब teams एक ही deployment में image format, lazy loading, preloading, JavaScript bundles, और CDN settings बदल देती हैं। हो सकता है आप page improve कर दें, लेकिन आपको पता नहीं चलेगा कि कौन-सा change मायने रखता था।

Field data भी मायने रखता है। Lab tools diagnosis के लिए उपयोगी हैं, लेकिन LCP device, network, viewport, cache state, और geography के अनुसार बदलता है। जब संभव हो, real-user monitoring या Chrome User Experience Report data इस्तेमाल करें।

<!-- tool-cta:start -->

💡 यह आज़माएँ: अपनी LCP इमेज को छोटा और प्राथमिकता से लोड होने वाला रखें, इसे Image Compressor से प्रोसेस करके, ताकि यह lazy loading की आवश्यकता के बिना जल्दी रेंडर हो।

<!-- tool-cta:end -->

अधिकांश websites के लिए practical policy

अधिकांश marketing sites, ecommerce pages, documentation sites, और publisher pages के लिए, यह policy पर्याप्त है:

• Above-the-fold primary image: eager load करें, high fetch priority पर विचार करें।
• Below-the-fold content images: lazy load करें।
• Icons और tiny UI assets: आम तौर पर individually सोचने लायक नहीं।
• CSS background hero: HTML image के रूप में फिर से विचार करें या सावधानी से preload करें।
• JavaScript-injected hero image: संभव हो तो rendering architecture ठीक करें।
• Carousels: केवल पहली visible slide eager load करें; बाकी lazy load करें।

Edge cases होते हैं। Browser heuristics सुधरते हैं। Frameworks automatic image components जोड़ते हैं। कुछ platforms अब viewport के पास detect की गई images को lazy load करने से बचते हैं। फिर भी, सिद्धांत नहीं बदलता: critical resources जल्दी और स्पष्ट होने चाहिए; non-critical resources इंतज़ार कर सकते हैं।

लेज़ी लोडिंग तब मूल्यवान है जब वह इस अंतर को व्यक्त करती है। यह तब नुकसानदेह है जब यह सबसे महत्वपूर्ण content को ब्राउज़र से तब तक छिपाती है जब तक पेज LCP race हारना शुरू कर चुका होता है।