जानें कि प्रत्येक माप आपको क्या बता रहा है
Largest Contentful Paint, या LCP, मापता है कि प्रारंभिक viewport में सबसे बड़ा इमेज या टेक्स्ट ब्लॉक कब रेंडर होता है। Interaction to Next Paint, या INP, एक विज़िट की उत्तरदायिता को उसके सबसे धीमे योग्य इंटरैक्शन के माध्यम से मापता है। Cumulative Layout Shift, या CLS, एक विज़िट के दौरान अनपेक्षित दृश्यात्मक मूवमेंट को मापता है।
Google के प्रकाशित अनुभव लक्ष्य हैं: LCP ≤ 2.5 सेकंड, INP ≤ 200 मिलीसेकंड, और CLS ≤ 0.1। इन्हें पेज लोड्स के 75वें पर्सेन्टाइल पर आकलन करें, मोबाइल और डेस्कटॉप के लिए अलग–अलग। लक्ष्यों का उपयोग कार्यों पर ध्यान केंद्रित करने के लिए करें, न कि रैंकिंग की गारंटी के रूप में या धीमे विज़िटर्स को अनदेखा करने के बहाने के रूप में।
मुख्य सामग्री देर से प्रकट होती है; सर्वर, संसाधन खोज, डाउनलोड, और रेंडरिंग पाथ की जाँच करें।
क्लिक, टैप, या कीप्रेस के लिए दृश्यात्मक प्रतिक्रिया में बहुत देर होती है; स्रोत एक एम्बेडेड फ़्रेम भी हो सकता है।
सामग्री अनपेक्षित रूप से हिलती है; नियंत्रणों, फ़ॉर्म्स, और पढ़ने की स्थिति के पास होने वाले शिफ्ट्स पर विशेष ध्यान दें।
रीयल-यूज़र (फ़ील्ड) डेटा प्राथमिकता तय करे और लैब परीक्षण उसे समझाए
फ़ील्ड डेटा वास्तविक विज़िट्स से आता है, जिनमें असली डिवाइस, नेटवर्क, लोकेशन, कैश स्थिति और व्यवहार शामिल होते हैं। Chrome User Experience Report डेटा PageSpeed Insights और Search Console में तब दिखाई देता है जब पर्याप्त डेटा मौजूद हो। आपका अपना रियल-यूज़र मॉनिटरिंग पेज-व्यू संदर्भ जोड़ सकता है; केवल आवश्यक टेलीमेट्री इकट्ठा करें और ग्राहक-प्रविष्ट सामग्री से बचें।
लैब डेटा चयनित परिस्थितियों के तहत एक दोहराने योग्य परीक्षण है। यह किसी रिलीज़ परिवर्तन को अलग करने और एक ट्रेस पढ़ने के लिए उपयोगी है, लेकिन यह हर विज़िटर का प्रतिनिधित्व नहीं कर सकता। Lighthouse बिना वास्तविक इंटरैक्शन के true INP को माप नहीं सकता, इसलिए इसका Total Blocking Time एक निदानात्मक प्रॉक्सी है। जब परिणाम भिन्न हों, प्राथमिकता तय करने के लिए फ़ील्ड डेटा और कारण खोजने के लिए लैब डेटा का उपयोग करें।
रिकॉर्ड करें कि डेटा URL स्तर का है या origin स्तर का और क्या वह मोबाइल है या डेस्कटॉप।
बेसलाइन के साथ तारीख, पेज ग्रुप, डिवाइस, वितरण, परीक्षण सेटिंग्स, और हालिया रिलीज़ सेव करें।
पहचान-क्रम: पहुँच, टास्क हानि, सबूत और उलटनीयता के आधार पर त्रियाज करें
सबसे कम डैशबोर्ड नंबर से शुरू न करें। प्रभावित विज़िट्स, विज़िटर टास्क की महत्ता, किसी टेम्पलेट में आवृत्ति, और क्या परिवर्तन को अलग किया जा सकता है व रोलबैक किया जा सकता है—इनके आधार पर उम्मीदवारों को रैंक करें। इससे Core Web Vitals अनुकूलन स्कोर-चेज़िंग के बजाय परिचालनात्मक उपचार बन जाता है।
एक साझा टेम्पलेट पर एक गायब इमेज डायमेंशन नई फ्रंट-एंड री-राइट से बेहतर पहला परिवर्तन हो सकता है। एक कम सामान्य चेकआउट इंटरैक्शन प्राथमिकता ले सकता है जब वह पूरा करना रोक रहा हो। मेट्रिक सबूत को सपोर्ट फ़ीडबैक, फ़नल निरीक्षण, और पहुँचयोग्यता समीक्षा के साथ जोड़ें।
महत्वपूर्ण टेम्पलेट्स पर फ़ील्ड-देखी समस्याएँ जो बार-बार हों और जिनका स्पष्ट, कम-जोखिम समाधान हो।
ऐसी वास्तुशिल्प विचार जिनके पास मापी हुई उपयोगकर्ता समस्या या रोलबैक पाथ न हो; इन्हें परिकल्पनाएँ बनाए रखें।
LCP को मुख्य सामग्री तक के पथ को छोटा करके ठीक करें
प्रभावित पेज और डिवाइस समूह के लिए LCP तत्व की पहचान करें। प्रारंभिक HTML प्रतिक्रिया, ब्राउज़र किस समय तत्व खोजता है, उसके संसाधन का डाउनलोड कितना समय लेता है, और क्या रेंडरिंग ब्लॉक कर रहा है—इनकी जाँच करें। उच्च सर्वर रिस्पॉन्स समय LCP लक्ष्य को असम्भव बना सकता है भले ही हीरो एसेट अच्छी तरह से ऑप्टिमाइज़्ड हो।
प्राथमिक सामग्री को जल्दी खोजने योग्य रखें जब यह डिज़ाइन में फिट बैठता हो। उस इमेज को lazy-load न करें जो LCP तत्व है। इमेज-नेतृत्व वाले पृष्ठों के लिए उपयुक्त आकार और एन्कोडिंग वाले एसेट का उपयोग करें और स्पष्ट डायमेंशन दें। प्रीलोड्स और डिलिवरी नियमों का परीक्षण करें: एक प्रारंभिक अनुरोध तभी उपयोगी है जब वह अधिक महत्त्वपूर्ण काम के साथ प्रतिस्पर्धा न करे।
रीडायरेक्ट, सर्वर वर्क, कैश व्यवहार, और डिलिवरी निकटता की जाँच करें; इसके लिए एप्लिकेशन या होस्टिंग की जवाबदेही चाहिए हो सकती है।
जाँचें कि क्या क्लाइंट रेंडरिंग, स्क्रिप्ट्स, या CSS मुख्य टेक्स्ट या इमेज की खोज में देरी कर रहे हैं।
इंटरैक्शंस को उत्तरदायी और लेआउट को Predictable बनाएं
INP के लिए, ब्राउज़र ट्रेस में किसी धीमे फ्लो को पुनःउत्पन्न करें। इनपुट देरी, इवेंट प्रोसेसिंग, और प्रेजेंटेशन देरी को अलग करें। लंबे मेन-थ्रेड टास्क, भारी हैंडलर्स, महंगे रेंडरिंग, और लेआउट थ्रैशिंग प्रत्येक अगले पेंट को विलंबित कर सकते हैं। अगले फ्रेम के लिए दृश्यात्मक काम पहले करें; जहाँ उत्पाद आवश्यकताएँ अनुमति दें वहाँ गैर-महत्वपूर्ण सेविंग, एनालिटिक्स, या द्वितीयक अपडेट्स को स्थगित करें।
CLS के लिए, कुल से अनुमान लगाने के बजाय हिलने वाले तत्वों को ढूंढें। इमेज, वीडियो, विज्ञापन, एम्बेड्स, और फ़्रेम्स के लिए डायमेंशन या CSS aspect-ratio से जगह रिज़र्व करें। फ़ॉन्ट लोडिंग और इंजेक्ट की गई सामग्री की जाँच करें। केवल स्कोर सुधारने के लिए आवश्यक सहमति, त्रुटि, या पहुँचयोग्यता संदेश को छिपाएँ नहीं; उसे एक स्थिर स्थान दें।
काम को स्थगित करने से एप्लिकेशन की टाइमिंग बदल सकती है। स्टेट, वैलिडेशन, और कीबोर्ड व्यवहार का रिग्रेशन-परीक्षण करें।
lazy-loaded और एम्बेडेड क्षेत्रों में स्क्रोल करें; केवल लोड-टाइम टेस्ट बाद के शिफ्ट्स को मिस कर सकता है।
सुरक्षित रूप से सुधार रिलीज़ करें और उनकी पुष्टि करें
परफॉरमेंस परिवर्तन स्क्रिप्ट्स, कैशिंग, रेंडरिंग, एम्बेड्स, या डिलिवरी कॉन्फ़िगरेशन को प्रभावित कर सकते हैं। परिवर्तन को स्टेज करें, बेसलाइन के साथ परिभाषित टेस्ट पाथ की तुलना करें, और रोलबैक डॉक्यूमेंट करें। भुगतान, अकाउंट, या विनियमित फ्लो के लिए एम्बेड्स, वैलिडेशन, या डेटा हैंडलिंग बदलने से पहले संबंधित सुरक्षा, अनुपालन, और पहुँचयोग्यता समीक्षकों को शामिल करें। यह शैक्षिक मार्गदर्शन है, न कि अनुपालन मूल्यांकन।
रिलीज़ के बाद, वही लैब पाथ तुलना करें और रिपोर्टिंग विंडो के दौरान संबंधित फ़ील्ड सेगमेंट्स को देखें। छिपी हुई त्रुटि या पठनीयता कम इंटरफ़ेस जैसे अनपेक्षित प्रभावों की जाँच करें। Status Is UP रीकरींग चेक, स्पष्ट सुधार जिम्मेदारी, और घटनाओं के बीच रोलबैक-readiness के माध्यम से सक्रिय अपटाइम अनुकूलन का समर्थन करता है।
प्रत्येक परिवर्तन को एक पेज ग्रुप, मेट्रिक, मालिक, टेस्ट साक्ष्य, ट्रेड-ऑफ, और रोलबैक निर्देश से लिंक करें।
एक सिंथेटिक पास से सफलता की घोषणा न करें; संबंधित वास्तविक-उपयोगकर्ता पैटर्न की पुष्टि करें।