अब क्या चाहिए यह तय करें—न कि केवल मार्कअप में क्या पहले दिखता है
लेज़ी लोडिंग किसी संसाधन को गैर-क्रिटिकल के रूप में चिह्नित करती है जब तक कि उसकी ज़रूरत न हो। वास्तविक यात्रा के आधार पर वर्गीकृत करें: पहली-व्यू अनिवार्यताएँ, नीचे-फोल्ड मीडिया, वैकल्पिक एम्बेड, और बाद में रूट या पैनल के लिए कोड। CMS स्थिति पर्याप्त सबूत नहीं है; एक इमेज एक टेम्पलेट में ऑफस्क्रीन हो सकती है और दूसरे में केंद्रीय हो सकती है।
एक छोटे फोन और एक सामान्य डेस्कटॉप पर कोल्ड लोड्स की समीक्षा करें। साथ ही अभियान लिंक और इन-पेज एंकर का परीक्षण करें, जो विज़िटर को पेज पर नीचे ले जा सकते हैं। वह समीक्षा बताती है कि बिना स्क्रोल-ट्रिगर अनुरोध के क्या तैयार होना चाहिए।
प्रारंभिक कार्य, दृश्यमान नेविगेशन, प्रमुख कॉपी, और पहली मायने वाली दृश्य वस्तु तुरंत उपलब्ध होनी चाहिए।
निचले पृष्ठ की गैलरी, मानचित्र, सोशल एम्बेड, ऑफस्क्रीन प्लेयर, और अनचुने फीचर्स के लिए कोड आम उम्मीदवार हैं।
हीरो और प्रारंभिक व्यूपोर्ट की रक्षा करें
ऐसी सामग्री को लेज़ी-लोड न करें जो पेज खुलने पर दिखाई देने की संभावना रखती हो। Google इस पर सावधानी बरतता है, और web.dev का विश्लेषण दिखाता है कि प्रारंभिक-व्यूपोर्ट इमेज का लेज़ी-लोड LCP को देर कर सकता है। LCP एलिमेंट एक हीरो, प्रोडक्ट इमेज, पोस्टर, या टेक्स्ट हो सकता है; अनुमान लगाने की बजाय हर महत्वपूर्ण टेम्पलेट पर इसकी पुष्टि करें।
पुष्टि किए गए LCP इमेज को ईगरली लोड करें। अगर टेस्ट से पता चले कि एक क्रिटिकल इमेज नेटवर्क ध्यान खो बैठती है, तो उसके लिए हाई fetch-priority संकेत (hint) परखें। यह एक संकेत है, आदेश नहीं। एक क्रिटिकल CSS बैकग्राउंड इमेज को जल्दी preload की ज़रूरत पड़ सकती है क्योंकि पार्सर उसे सीधे खोज नहीं पाता; ऐसे मामले को मापें।
CMS और प्लगइन डिफ़ॉल्ट्स की जांच करें कि फ़ीचर किए गए इमेजलिस्टिंग पृष्ठों पर गलत तरीके से lazy-mark तो नहीं हैं।
सिर्फ़ डेस्कटॉप डिजाइन प्रिव्यू पर भरोसा न करें—कोल्ड मोबाइल और डेस्कटॉप लोड्स का उपयोग करें।
मीडिया आने से पहले स्थान आरक्षित करें
Cumulative Layout Shift (CLS) वह अनपेक्षित मूवमेंट है जो दृश्य कंटेंट में होता है। बिना ज्ञात ऊँचाई वाली टाली गई इमेज टेक्स्ट और कंट्रोल को तब तक धक्का दे सकती है जब पाठक स्कैन कर रहा हो या बटन दबाने जा रहा हो। यह केवल मेट्रिक समस्या नहीं, इंटरैक्शन जोखिम है।
इमेज और वीडियो के लिए सटीक width और height attributes दें, या CSS aspect-ratio के साथ शेप रिज़र्व करें। कंपोनेंट की अंतिम फुटप्रिंट के साथ एक प्लेसहोल्डर इस्तेमाल करें। तीसरे पक्ष के फ्रेम के लिए उसकी ऊँचाई आरक्षित करें और स्पष्ट लोडिंग या अनुपलब्ध स्थिति दिखाएँ।
जहाँ संभव हो, एसेट के साथ मीडिया डायमेंशन स्टोर करें; विभिन्न इमेज आकारों के लिए एक सामान्य अनुपात भरोसेमंद नहीं है।
स्क्रोल करें, फ़िल्टर लागू करें, पैनल खोलें, मोबाइल डिवाइस घुमाएँ, और बैक नेविगेशन का उपयोग कर बाद के शिफ्ट ढूँढें।
कंटेंट खोज योग्य और इंटरैक्शन समझने योग्य रखें
Google Search Central कहता है कि Google पेजों के साथ स्क्रोल या क्लिक करके इंटरैक्ट नहीं करता। महत्वपूर्ण लेज़ी-लोडेड कंटेंट दृश्यमान होने पर लोड होना चाहिए, और रेंडर्ड HTML में अपेक्षित कंटेंट या मीडिया URLs को एक्सपोज़ करना चाहिए। कार्यान्वयन के बाद प्रतिनिधि पृष्ठों को Search Console में निरीक्षण करें।
एक इनडेक्सेबल इनफिनिट लिस्ट को हर स्थायी हिस्से के लिए पेजिनेटेड रूट की आवश्यकता होती है: एक स्थायी यूनिक URL, उस URL पर स्थिर कंटेंट, और अनुक्रम के माध्यम से लिंक। इससे लोग उसे साझा कर के वापस आ सकते हैं।
जब कोई कार्रवाई कंटेंट प्रकट करे, तो नियंत्रण कीबोर्ड-ऑपरेबल रखें और परिणाम स्पष्ट बनाएं। किसी अर्थपूर्ण नॉन-फोकस अपडेट जैसे ‘रिज़ल्ट लोड हो गए’ के लिए प्रोग्रामैटिक रूप से स्थिति एक्सपोज़ करें ताकि सहायक तकनीकें बिना फोकस मूव किए उसे घोषित कर सकें।
प्रोडक्ट विवरण, लेख का बॉडी, पात्रता जानकारी और कार्य निर्देश ऐसी चीज़ें नहीं होनी चाहिए जो पहले किसी क्रिया के बाद ही मौजूद हों।
आवश्यक चेकआउट या ऑथेंटिकेशन नियंत्रण को न टालें। पेमेंट, पहचान, और थर्ड-पार्टी-स्क्रिप्ट परिवर्तनों का मूल्यांकन करने के लिए योग्य सुरक्षा और कम्प्लाइंस समीक्षकों को शामिल करें।
कम से कम नाज़ुक तंत्र का उपयोग करें
साधारण ऑफस्क्रीन इमेज और iframes के लिए नेटिव ब्राउज़र लेज़ी-लोडिंग आम तौर पर सबसे सरल शुरुआती विकल्प है। ब्राउज़र तय करता है कब near-viewport अनुरोध शुरू हो; वह दूरी कोई गारंटी नहीं है। विंडो load ईवेंट तब भी फायर हो सकता है जबकि लेज़ी संसाधन अपूर्ण हों।
जब किसी नामांकित कंपोनेंट को कस्टम सक्रियता चाहिए—उदाहरण के लिए महँगा पैनल mount करना ठीक पहले—तो Intersection Observer का उपयोग करें। ऑब्ज़र्वर को संकीर्ण रखें और तेज़ स्क्रोलिंग के लिए काम को उतना ही जल्दी शुरू करें जितनी ज़रूरत हो। नॉन-इनिशियल रूट्स या ऑप्शनल फीचर्स के लिए कोड-स्प्लिटिंग प्रयोग करें, न कि वर्तमान टास्क को देरी देने के बहाने।
जब तक जोड़ा गया व्यवहार परीक्षित आवश्यकता को हल न करे, साधारण स्रोत को data attributes, कई स्क्रिप्ट्स और एक लाइब्रेरी से न बदलें।
एक वैकल्पिक एम्बेड के पास स्पष्ट फॉलबैक या अनुपस्थिति स्थिति होनी चाहिए—स्थायी स्पिनर नहीं।
मापें, रिलीज़ करें, और साथ में रेमेडिएट करें
बेसलाइन और कैंडिडेट की तुलना एक ही URLs, कैश स्थिति, व्यूपोर्ट और उपयोगकर्ता पथ पर करें। जहाँ संभव हो कोल्ड, सीमित मोबाइल टेस्टिंग और रियल-डिवाइस चेक्स का उपयोग करें। LCP, दृश्य अनुक्रम, लेआउट शिफ्ट्स, मीडिया त्रुटियाँ, रेंडर्ड HTML, और आवश्यक कार्रवाइयों को रिकॉर्ड करें। फील्ड डेटा लैब टेस्टिंग को पूरक बनाती है।
एक उलटनीय, टेम्पलेट-स्कोप्ड परिवर्तन शिप करें। ईगर से डिफर्ड में स्थानांतरित किए गए एसेट्स, डिप्लॉयमेंट संदर्भ, कैश कार्रवाई, मालिक और पहला रोलबैक स्टेप रिकॉर्ड करें। अगर LCP लेज़ी हो जाए या कन्वर्ज़न पाथ अधूरा हो, तो उस क्रिटिकल एसेट से नियम हटा दें और फिर से सत्यापित करें। थीम, CMS, इमेज-सर्विस, टैग, या एम्बेड परिवर्तन के बाद फिर से जाँच करें।
वर्तमान-स्थिति रिपोर्टिंग या अलर्टिंग पर नहीं—टूटे हुए अनुभव को रोकने और ठीक करने पर ध्यान दें।
हर इमेज साइट-व्यापी फिर से ट्यून करने से पहले प्रभावित टेम्पलेट सेटिंग को पलटें।