आप खराब Core Web Vitals का निदान (diagnose) और सुधार कैसे करते हैं?

समस्या विवरण और लागू संदर्भ

एक ई-कॉमर्स प्रोडक्ट पेज का 28-दिन का मोबाइल फ़ील्ड डेटा p75 LCP 4.1 सेकंड, INP 320 मिलीसेकंड, और CLS 0.06 दिखाता है। डेस्कटॉप तीनों मेट्रिक्स को पास करता है। एक डेवलपर का स्थानीय Lighthouse रन 1.8 सेकंड का LCP, 80 मिलीसेकंड का TBT, और 0.01 का CLS रिपोर्ट करता है। समझाएं कि आप इस विसंगति (discrepancy) का मिलान कैसे करेंगे, LCP और INP के मूल कारणों का पता कैसे लगाएंगे, सुधारों को कैसे क्रमबद्ध करेंगे, और यह कैसे साबित करेंगे कि परिनियोजित (deployed) परिवर्तनों ने वास्तविक उपयोगकर्ता अनुभव में सुधार किया है।

वर्तमान "अच्छे" Core Web Vitals थ्रेशोल्ड का उपयोग करें: मोबाइल और डेस्कटॉप के लिए अलग-अलग 75वें पर्सेंटाइल की गणना करें, जिसमें LCP 2.5 सेकंड या उससे कम, INP 200 मिलीसेकंड या उससे कम, और CLS 0.1 या उससे कम हो। ये संख्याएं साक्षात्कार के लिए मानी गई धारणाएं हैं, किसी वास्तविक कंपनी के माप नहीं। इसका लक्ष्य केवल ऑप्टिमाइज़ेशन चेकलिस्ट दोहराना नहीं है। इसका उद्देश्य उपयोगकर्ता वितरण (user distributions), मेट्रिक घटकों, ब्राउज़र के काम और सत्यापन को एक मिथ्याकरणीय (falsifiable) नैदानिक श्रृंखला से जोड़ना है।

यह प्रश्न सीनियर फ़्रंटएंड, वेब परफ़ॉर्मेंस और फ़ुल-स्टैक साक्षात्कारों के लिए उपयुक्त है। एक उम्मीदवार को नेटवर्क वाटरफ़ॉल, मुख्य थ्रेड (main thread), और लेआउट को समझने की आवश्यकता होती है, साथ ही यह भी पहचानना होता है कि एक Lighthouse रन वास्तविक-उपयोगकर्ता डेटा को खारिज नहीं कर सकता और TBT, INP नहीं है।

साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है

पहला, क्या उम्मीदवार कार्रवाई करने से पहले साक्ष्यों को सामान्यीकृत (normalize) कर सकता है? एक मजबूत उत्तर यह स्थापित करता है कि फ़ील्ड डेटा एक URL, एक URL समूह, या पूरे ऑरिजिन का प्रतिनिधित्व करता है या नहीं, फिर मोबाइल बनाम डेस्कटॉप, रूट टेम्पलेट, डिवाइस टीयर, नेटवर्क, भूगोल और रिलीज़ द्वारा खंडित (segment) करता है। एक कमजोर उत्तर समस्या को अस्तित्वहीन घोषित कर देता है क्योंकि स्थानीय Lighthouse स्कोर हरा है।

दूसरा, क्या उम्मीदवार प्रत्येक मेट्रिक को एक अलग बाधा (bottleneck) से मैप कर सकता है? LCP का संबंध इस बात से है कि मुख्य सामग्री कब दिखाई देती है। INP एक इंटरैक्शन से लेकर अगले रेंडर किए गए फ़्रेम तक के पूरे विलंब (delay) को कवर करता है। CLS अनपेक्षित विज़ुअल मूवमेंट को कवर करता है। वे कुछ मुख्य-थ्रेड और रेंडरिंग लागत साझा करते हैं, लेकिन "बंडल कम करना" हर विफलता की व्याख्या नहीं कर सकता।

तीसरा, क्या उम्मीदवार लेटेंसी का सटीक कारण निर्धारित (attribute) कर सकता है? LCP को TTFB, रिसोर्स लोड डिले, रिसोर्स लोड ड्यूरेशन, और एलिमेंट रेंडर डिले में विभाजित किया जा सकता है। एक इंटरैक्शन की लेटेंसी को इनपुट डिले, प्रोसेसिंग ड्यूरेशन, और प्रेजेंटेशन डिले में विभाजित किया जा सकता है। एक सुधार को किसी परफ़ॉर्मेंस चेकलिस्ट के यादृच्छिक आइटम के बजाय एक असामान्य घटक को लक्षित करना चाहिए।

चौथा, क्या उम्मीदवार फ़ील्ड और लैब टूल का सही उपयोग कर सकता है? RUM और CrUX पहचानते हैं कि वास्तविक उपयोगकर्ता क्या अनुभव करते हैं। DevTools, Lighthouse, और एक पुनरुत्पादनीय सीमित-डिवाइस परिदृश्य यह समझाने में मदद करते हैं कि ऐसा क्यों है। वास्तविक उपयोगकर्ता इनपुट के बिना, Lighthouse INP को नहीं माप सकता; प्रयोगशाला संकेत जैसे TBT नैदानिक सहायता हैं।

पांचवां, क्या उम्मीदवार केवल एक परिनियोजन (deployment) दिखाने के बजाय सुधार साबित कर सकता है? रिलीज़ के बाद, वर्ज़न या रोलआउट कोहोर्ट द्वारा समान-से-समान RUM वितरण की तुलना करें, त्रुटि और व्यावसायिक सुरक्षा उपायों (guardrails) की जांच करें, और फिर रोलिंग 28-दिवसीय फ़ील्ड डेटा को परिवर्तन की पुष्टि करने दें। एक स्नैपशॉट, एक कम औसत (mean), या एक तेज़ फ़ोन यह साबित नहीं करता है कि p75 पास होता है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• फ़ील्ड-डेटा का दायरा क्या है? URL, URL-समूह और ऑरिजिन परिणाम भिन्न हो सकते हैं। यदि 4.1 सेकंड ऑरिजिन का है, तो प्रोडक्ट पेज अभी तक सिद्ध कारण नहीं है। यदि यह प्रोडक्ट टेम्पलेट का है, तो उस टेम्पलेट के ट्रैफ़िक को आगे खंडित करें।
• कौन से डिवाइस, नेटवर्क और क्षेत्र मोबाइल नमूनों में योगदान करते हैं? निचले स्तर के उपकरणों या एक क्षेत्र तक सीमित विफलता के लिए एक अलग पुनरुत्पादन (reproduction) और प्राथमिकता की आवश्यकता होती है। मोबाइल और डेस्कटॉप को संयोजित करने से समस्या छिप जाती है।
• मेट्रिक्स कब बिगड़े? रिलीज़, तीसरे पक्ष की स्क्रिप्ट, इमेज पाइपलाइन, या ट्रैफ़िक-मिश्रण परिवर्तन के साथ संरेखण परिकल्पनाओं को संकीर्ण करता है। एक रोलिंग 28-दिवसीय मान किसी एक रिलीज़ के तात्कालिक प्रभाव को सटीक रूप से उजागर नहीं करता है।
• वास्तविक LCP एलिमेंट और धीमा INP इंटरैक्शन क्या हैं? एक हीरो इमेज, हेडिंग टेक्स्ट, और क्लाइंट-रेंडर किए गए कंटेनर को अलग-अलग सुधारों की आवश्यकता होती है। ऐड-टू-कार्ट, वेरिएंट चयन, और खोज इनपुट भी विभिन्न मुख्य-थ्रेड पथों का उपयोग करते हैं।
• Lighthouse को कैसे चलाया गया था? डिवाइस और नेटवर्क थ्रॉटलिंग, कैश, प्रमाणीकरण, पेज डेटा, और परीक्षण की गई यात्रा धीमी आबादी से मिलती-जुलती होनी चाहिए। एक तेज़ लैपटॉप पर एक बार कोल्ड लोड होना मोबाइल वितरण का प्रतिनिधित्व नहीं करता है।
• टीम किन परतों को बदल सकती है? एक केवल-फ़्रंटएंड टीम को अभी भी TTFB की मात्रा निर्धारित करनी चाहिए, लेकिन वह यह नाटक नहीं कर सकती कि वह ऑरिजिन को सीधे ठीक कर सकती है। यदि CDN, सर्वर रेंडरिंग, और इमेज सेवाएं दायरे में हैं, तो योजना पूरे महत्वपूर्ण पथ (critical path) को कवर कर सकती है।
• एक सफल रिलीज़ को क्या परिभाषित करता है? यहां, सभी तीन मोबाइल p75 मेट्रिक्स अच्छे होने चाहिए, जबकि त्रुटि दर, रूपांतरण (conversion), और एक्सेसिबिलिटी सुरक्षित रहनी चाहिए। गलत हीरो इमेज को पहले पेंट करना या किसी महत्वपूर्ण इंटरैक्शन को ब्लॉक करना सफलता नहीं है।

30-सेकंड का उत्तर

"मैं पहले यह सत्यापित करूंगा कि क्या 4.1 सेकंड और 320 मिलीसेकंड मोबाइल URL-स्तर या ऑरिजिन-स्तर का फ़ील्ड डेटा है, फिर रूट टेम्पलेट, डिवाइस, नेटवर्क, और रिलीज़ द्वारा खंडित करूंगा। Lighthouse TBT, INP नहीं है, इसलिए स्थानीय परिणाम वास्तविक-उपयोगकर्ता की समस्या को खारिज नहीं कर सकता। मैं वास्तविक LCP एलिमेंट और सबसे धीमे इंटरैक्शन की पहचान करने के लिए RUM का उपयोग करूंगा, फिर एक तुलनीय डिवाइस पर नेटवर्क और Performance ट्रेस कैप्चर करूंगा। मैं LCP को TTFB, डिस्कवरी, डाउनलोड, और रेंडरिंग में विभाजित करूंगा, और INP को इनपुट, इवेंट प्रोसेसिंग, और अगली-फ़्रेम प्रेजेंटेशन में विभाजित करूंगा। CLS पहले से ही 0.06 पर पास है, इसलिए यह पहले निवेश के बजाय एक रिग्रेशन गार्डरेल बन जाता है। अंत में, मैं धीरे-धीरे रोल आउट करूंगा, समान-से-समान RUM p75 और गार्डरेल्स की तुलना करूंगा, और पुष्टि करने के लिए 28-दिवसीय CrUX विंडो की प्रतीक्षा करूंगा।"

चरण-दर-चरण विस्तृत विश्लेषण

चरण 1: समझाएं कि फ़ील्ड और लैब परिणाम दोनों कैसे सही हो सकते हैं

अट्ठाईस दिनों का फ़ील्ड डेटा वास्तविक उपयोगकर्ताओं के उपकरणों, नेटवर्क, कैश स्थितियों, पेज जीवनचक्रों, और इंटरैक्शन को जोड़ता है। 4.1 सेकंड का एक मोबाइल p75 LCP प्रासंगिक विज़िट्स के लगभग सबसे धीमे एक-चौथाई हिस्से को 4.1 सेकंड या उससे भी बदतर स्थिति में रखता है। इसका मतलब यह नहीं है कि एक "विशिष्ट फ़ोन" में ठीक 4.1 सेकंड लगते हैं। पास होने वाला डेस्कटॉप डेटा बताता है कि विफलता सीमित CPU, मोबाइल नेटवर्क, एक मोबाइल टेम्पलेट, या एक मोबाइल उपयोगकर्ता यात्रा में केंद्रित हो सकती है।

स्थानीय Lighthouse एक नियंत्रित प्रयोग है। यह दोहराने योग्य है और वाटरफ़ॉल और रिग्रेशन का पता लगाने के लिए उपयोगी है, लेकिन यह एक डिवाइस और नेटवर्क कॉन्फ़िगरेशन का प्रतिनिधित्व करता है। उपयोगकर्ता इनपुट के बिना, Lighthouse सीधे INP का उत्पादन नहीं कर सकता। 80 मिलीसेकंड का TBT मुख्य-थ्रेड ब्लॉकिंग के बारे में एक लैब सिग्नल है। एक पेज में स्टार्टअप TBT कम हो सकता है, लेकिन जब कोई उपयोगकर्ता वेरिएंट पिकर खोलता है तो वह 300-मिलीसेकंड का कार्य चला सकता है। इसके विपरीत भी संभव है: उच्च लैब TBT उस समय हो सकता है जब कुछ वास्तविक उपयोगकर्ता इंटरैक्ट करते हैं।

पहले PageSpeed Insights या डेटा प्लेटफ़ॉर्म में पुष्टि करें कि परिणाम URL, ऑरिजिन, या URL-समूह डेटा है या नहीं, और मोबाइल और डेस्कटॉप का अलग-अलग निरीक्षण करें। फिर पेज टेम्पलेट, डिवाइस टीयर, प्रभावी कनेक्शन प्रकार, भूगोल, नेविगेशन प्रकार, और एप्लिकेशन रिलीज़ द्वारा खंडित करने के लिए फ़र्स्ट-पार्टी RUM का उपयोग करें। प्रत्येक आयाम के लिए पर्याप्त नमूनों और एक उचित गोपनीयता सीमा की आवश्यकता होती है। परफ़ॉर्मेंस निदान पूर्ण क्वेरी स्ट्रिंग्स, टाइप किए गए टेक्स्ट, या उपयोगकर्ता पहचान को एकत्र करने को उचित नहीं ठहराता है।

चरण 2: ऐसा RUM बनाएं जो केवल स्कोर रिपोर्ट करने के बजाय समस्याओं का कारण बताए

एक न्यूनतम कार्यान्वयन web-vitals के माध्यम से तीनों मेट्रिक्स की रिपोर्ट कर सकता है। निम्नलिखित कोड सभी आठ भाषा संस्करणों में समान है:

import { onCLS, onINP, onLCP } from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    id: metric.id,
    rating: metric.rating,
    route: location.pathname,
  });

  (navigator.sendBeacon && navigator.sendBeacon('/rum', body)) ||
    fetch('/rum', { body, method: 'POST', keepalive: true });
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

यह उदाहरण पठनीयता के लिए location.pathname का उपयोग करता है। प्रोडक्शन कोड को इसे निम्न-कार्डिनैलिटी रूट टेम्पलेट जैसे /products/:id पर मैप करना चाहिए और एक रिलीज़, डिवाइस टीयर, और आवश्यक एट्रिब्यूशन फ़ील्ड संलग्न करने चाहिए। क्वेरी पैरामीटर, DOM टेक्स्ट, या उपयोगकर्ता-पहचान की जानकारी प्रसारित न करें। metric.id एक पेज विज़िट के लिए मेट्रिक इवेंट्स को अलग करने में मदद करता है, लेकिन प्राप्त करने वाली सेवा को अभी भी स्पष्ट सैंपलिंग और डुप्लिकेट-रिपोर्ट नियमों की आवश्यकता होती है।

रिग्रेशन को ठीक करने के लिए केवल name और value संग्रहीत करना पर्याप्त नहीं है। LCP को एलिमेंट और चार टाइमिंग घटकों की आवश्यकता होती है। INP को इंटरैक्शन लक्ष्य और तीन टाइमिंग घटकों की आवश्यकता होती है। CLS को शिफ़्ट किए गए एलिमेंट्स और जीवनचक्र चरण की आवश्यकता होती है। उन फ़ील्ड्स को जोड़ने के लिए एक एट्रिब्यूशन बिल्ड या किसी मौजूदा RUM प्रोडक्ट का उपयोग करें। एकत्रीकरण (aggregation) के समय, प्रत्येक नेविगेशन के अंतिम मेट्रिक से पर्सेंटाइल की गणना करें। प्रत्येक घटक के लिए स्वतंत्र रूप से p75 की गणना न करें और उन्हें जोड़ें नहीं: वे पर्सेंटाइल अवलोकन अलग-अलग विज़िट्स से आ सकते हैं।

चरण 3: चार टाइमिंग घटकों के साथ LCP का निदान करें

एक प्रतिनिधि धीमा मोबाइल नेविगेशन 0.6 सेकंड का TTFB, 1.5 सेकंड का रिसोर्स लोड डिले, 0.9 सेकंड का रिसोर्स लोड ड्यूरेशन, और 1.3 सेकंड का एलिमेंट रेंडर डिले दिखाता है, जो कुल 4.3 सेकंड का LCP बनाता है। ये घटक एक ही नेविगेशन से संबंधित हैं, इसलिए इन्हें जोड़ा जा सकता है। ये चार स्वतंत्र p75 मान नहीं हैं।

दो सबसे बड़े संदिग्ध घटक लोड डिले और रेंडर डिले हैं। जांचें कि क्या हीरो केवल क्लाइंट जावास्क्रिप्ट चलने के बाद डाला गया है या गलत तरीके से लेज़ी-लोड किया गया है। एक इमेज के लिए, शुरुआती HTML में <img> और उसके src या srcset को रखें, सही sizes प्रदान करें, अबोव-द-फ़ोल्ड LCP इमेज को लेज़ी-लोड न करें, और केवल वास्तव में महत्वपूर्ण संसाधन के लिए उच्च fetchpriority का उपयोग करें। यदि CSS ही एकमात्र डिस्कवरी पथ है, तो एक सटीक प्रीलोड का मूल्यांकन करें। प्रत्येक बड़ी इमेज को प्रीलोड करने से महत्वपूर्ण संसाधन बैंडविड्थ के लिए प्रतिस्पर्धा करते हैं।

संसाधन के डाउनलोड समाप्त होने के बाद अन्य 1.3 सेकंड बीत जाते हैं, इसलिए आगे इमेज कम्प्रेशन केवल समय को रेंडर डिले में स्थानांतरित कर सकता है। सिंक्रोनस जावास्क्रिप्ट, क्लाइंट-रेंडरिंग गेट्स, ब्लॉकिंग स्टाइल्स, फ़ॉन्ट्स, और हीरो को छिपाने वाली स्थिति का निरीक्षण करें। दृश्यमान हीरो सामग्री को सर्वर-रेंडर करना, क्रिटिकल CSS को कम करना, और गैर-महत्वपूर्ण हाइड्रेशन को टालना मदद कर सकता है, लेकिन एक नए ट्रेस को यह दिखाना चाहिए कि लक्षित घटक वास्तव में कम हो गया है। 0.6 सेकंड का TTFB अभी भी निगरानी के योग्य है। इस नमूने में मापे गए 1.5- और 1.3-सेकंड के विलंब की तुलना में इसकी प्राथमिकता कम है; यह स्थायी रूप से ऑप्टिमाइज़ेशन से मुक्त नहीं है।

चरण 4: तीन टाइमिंग घटकों के साथ INP का निदान करें

एक प्रतिनिधि धीमा "सेलेक्ट वेरिएंट" इंटरैक्शन 350 मिलीसेकंड लेता है: 140 मिलीसेकंड का इनपुट डिले, 120 मिलीसेकंड का इवेंट प्रोसेसिंग, और 90 मिलीसेकंड का प्रेजेंटेशन डिले। तीनों घटक एक इंटरैक्शन से आते हैं, इसलिए उनका योग सार्थक है। 320 मिलीसेकंड का फ़ील्ड p75 INP एक अलग समुच्चय (aggregate) है और इसे इस ट्रेस द्वारा प्रतिस्थापित नहीं किया जा सकता है।

इनपुट डिले का मतलब है कि जब उपयोगकर्ता ने कार्रवाई की तो अन्य कार्य पहले से ही मुख्य थ्रेड पर कब्जा कर रहे थे। इंटरैक्शन से पहले शुरू होने वाले Performance ट्रेस को रिकॉर्ड करें और स्क्रिप्ट मूल्यांकन, तीसरे पक्ष के टैग, टाइमर, या हाइड्रेशन लॉन्ग टास्क की तलाश करें। रोके जा सकने वाले (interruptible) काम को छोटे कार्यों में विभाजित करें, गैर-महत्वपूर्ण काम को टालें, और इसे स्टार्टअप के दौरान केंद्रित करने से बचें। केवल वर्तमान क्लिक हैंडलर को छोटा करने से उस हैंडलर के शुरू होने से पहले प्रतीक्षा में बिताए गए 140 मिलीसेकंड समाप्त नहीं होते हैं।

प्रोसेसिंग अवधि इवेंट कॉलबैक से संबंधित है। इन्वेंट्री विश्लेषण, अनुशंसा रीफ़्रेश (recommendation refreshes), या लॉगिंग से पहले चयनित स्थिति या लोडिंग फ़ीडबैक को अगले फ़्रेम में रखें; डुप्लिकेट गणना को हटाएं और स्थिति अपडेट को संकीर्ण करें। प्रेजेंटेशन डिले के लिए, बड़े DOM अपडेट, फ़ोर्स्ड सिंक्रोनस लेआउट, और लेआउट थ्रैशिंग का निरीक्षण करें। DOM रीड और राइट को समूहीकृत करें और उस क्षेत्र को कम करें जिसे इस इंटरैक्शन के लिए लेआउट और पेंट किया जाना चाहिए। एक समय में एक मापी गई बाधा को बदलें और तीनों घटकों की तुलना करने के लिए उसी यात्रा को दोहराएं।

चरण 5: पहले से ही अच्छे CLS को रिग्रेशन गार्डरेल में बदलें

0.06 का CLS 0.1 से नीचे है, इसलिए इसे असफल LCP और INP से आगे नहीं रखना चाहिए। इसे अभी भी सुरक्षा की आवश्यकता है क्योंकि पहले हीरो लोडिंग, एक प्रतिस्थापन इमेज घटक, या नया इंटरैक्शन फ़ीडबैक लेआउट शिफ़्ट ला सकता है। छवियों और वीडियो को width, height, या एक स्थिर aspect-ratio दें; विज्ञापनों, अनुशंसाओं, और एसिंक्रोनस सामग्री के लिए स्थान आरक्षित करें; और वेब फ़ॉन्ट्स और फ़ॉलबैक के बीच आकार के अंतर को नियंत्रित करें।

लैब CLS 0.01 और फ़ील्ड CLS 0.06 के बीच का अंतर उपयोगी साक्ष्य है। डिफ़ॉल्ट Lighthouse रन मुख्य रूप से लोडिंग को कवर करते हैं, जबकि वास्तविक उपयोगकर्ता स्क्रॉल करते समय, घटकों को खोलते समय, या लंबे पेज को सक्रिय रखते हुए लोड के बाद के बदलाव देख सकते हैं। उन यात्राओं को पुनरुत्पादित करने के लिए RUM एट्रिब्यूशन और DevTools Layout Shifts ट्रैक का उपयोग करें। एक क्रॉस-ऑरिजिन iframe के अंदर लेआउट बदलाव CrUX में दिखाई दे सकते हैं लेकिन शीर्ष पेज के Web APIs के माध्यम से पूरी तरह से एट्रिब्यूट नहीं किए जा सकते हैं, इसलिए जब वह विसंगति दिखाई दे तो एम्बेडेड सामग्री का निरीक्षण करें।

चरण 6: साक्ष्य के आधार पर परिवर्तनों को क्रमबद्ध करें और धीरे-धीरे रिलीज़ करें

अलग-अलग "इमेज" और "जावास्क्रिप्ट" प्रोजेक्ट न बनाएं और सब कुछ समानांतर में न बदलें। वर्तमान ट्रेसेस से पता चलता है कि हीरो की विलंबित क्लाइंट-साइड डिस्कवरी और स्टार्टअप लॉन्ग टास्क LCP लोड/रेंडर डिले और INP इनपुट डिले दोनों को बढ़ा सकते हैं। एक पहला बैच एक साझा परिकल्पना का परीक्षण कर सकता है: हीरो को शुरुआती HTML में खोजने योग्य बनाएं और उस जावास्क्रिप्ट को टालें जिसकी पहली स्क्रीन को आवश्यकता नहीं है। परिवर्तन छोटा रहता है, कारणात्मक दावा परीक्षण योग्य रहता है, और दोनों असफल मेट्रिक्स में सुधार हो सकता है।

प्रत्येक परिवर्तन के लिए एक अपेक्षित संकेत लिखें। हीरो की खोजने योग्यता से रिसोर्स लोड डिले कम होना चाहिए। स्टार्टअप लॉन्ग टास्क को कम करने से LCP रेंडर डिले, INP इनपुट डिले, और लैब TBT कम होना चाहिए। यदि संबंधित घटक नहीं बदलता है, तो किसी आकस्मिक स्कोर परिवर्तन के लिए उस सुधार को श्रेय न दें। इमेज की गुणवत्ता, त्रुटि दर, पेज के उपयोग योग्य होने तक का समय, रूपांतरण, और एक्सेसिबिलिटी सुरक्षा उपाय हैं ताकि परफ़ॉर्मेंस संख्या उत्पाद की गिरावट को छिपा न सके।

तुलनीय पुराने वर्ज़न या समवर्ती बेसलाइन को बनाए रखते हुए एक ट्रैफ़िक कोहोर्ट के लिए रिलीज़ करें। ट्रैफ़िक मिश्रण में भौतिक रूप से बदलाव नहीं होने की पुष्टि करते हुए समान रूट, मोबाइल आबादी, और रिलीज़ की तुलना करें। जब कोई परिनियोजन किसी ट्रैफ़िक परिवर्तन के साथ ओवरलैप होता है, तो पहले और बाद की समयरेखा सहसंबंध (correlation) दिखाती है, स्वचालित कार्य-कारण (causation) नहीं।

चरण 7: साक्ष्य की तीन परतों के साथ समस्या को बंद करें

पहली परत प्री-मर्ज लैब गार्डरेल है: सीमित मोबाइल प्रोफ़ाइल, कैश स्थिति, और महत्वपूर्ण इंटरैक्शन को ठीक करें, फिर LCP, TBT, CLS, नेटवर्क वाटरफ़ॉल, और Performance ट्रेसेस रिकॉर्ड करें। यह स्पष्ट रिग्रेशन को पकड़ता है लेकिन वास्तविक INP को प्रतिस्थापित नहीं करता है।

दूसरी परत पोस्ट-रिलीज़ RUM है। नमूना आकार, स्थिर सैंपलिंग, और मेट्रिक-इवेंट डिडुप्लिकेशन की जांच करें, फिर उनके घटकों और उत्पाद गार्डरेल्स के साथ मोबाइल उत्पाद टेम्पलेट के लिए p75 LCP, INP, और CLS की तुलना करें। अल्पकालिक RUM दिशा को तेज़ी से प्रकट कर सकता है। यदि नमूना अपर्याप्त है, तो यह दावा करने के बजाय कि सभी उपयोगकर्ता पास हो गए हैं, अपर्याप्त विश्वास की रिपोर्ट करें।

तीसरी परत CrUX या Search Console में रोलिंग 28-दिवसीय पुष्टि है। पुरानी विज़िट विंडो से धीरे-धीरे बाहर निकलती हैं, इसलिए परिनियोजन के दिन मेट्रिक अपनी नई स्थिर स्थिति में नहीं कूदता है। पास होने का मतलब है कि मोबाइल और डेस्कटॉप अलग-अलग तीनों p75 लक्ष्यों को पूरा करते हैं: LCP ≤ 2.5 सेकंड, INP ≤ 200 मिलीसेकंड, और CLS ≤ 0.1। LCP को ठीक करने से CLS 0.06 से अपनी सीमा को पार नहीं करना चाहिए। रोलबैक मानदंड और किसी भी शेष धीमे सेगमेंट को रिकॉर्ड करें ताकि एक समग्र पास निचले स्तर के डिवाइस की समस्या को न छिपाए।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं मोबाइल फ़ील्ड डेटा को खारिज करने के लिए हरे स्थानीय Lighthouse परिणाम का उपयोग नहीं करूंगा। पहले मैं यह निर्धारित करूंगा कि 4.1 सेकंड प्रोडक्ट-डिटेल URL, एक URL समूह, या ऑरिजिन से संबंधित है या नहीं, फिर डिवाइस, नेटवर्क, क्षेत्र, और रिलीज़ द्वारा मोबाइल को खंडित करूंगा। 28-दिवसीय p75 एक वितरण है, एक उपकरण नहीं, और Lighthouse TBT, INP नहीं है।

मैं वास्तविक LCP एलिमेंट और सबसे धीमे इंटरैक्शन की पहचान करने के लिए RUM एट्रिब्यूशन जोड़ूंगा, फिर एक तुलनीय डिवाइस पर ट्रेस कैप्चर करूंगा। मान लीजिए कि एक धीमे नेविगेशन में 0.6, 1.5, 0.9, और 1.3 सेकंड के LCP घटक हैं। मैं पहले 1.5-सेकंड की डिस्कवरी डिले और 1.3-सेकंड की रेंडर डिले पर काम करूंगा: हीरो इमेज को शुरुआती HTML में रखें, अबोव-द-फ़ोल्ड लेज़ी लोडिंग हटाएं, और इसके पेंट को ब्लॉक करने वाले क्लाइंट कार्य को कम करें। पहले से डाउनलोड की जा चुकी इमेज को कंप्रेस करना मेरा पहला कदम नहीं है।

INP के लिए, मैं धीमे इंटरैक्शन को इनपुट डिले, प्रोसेसिंग, और प्रेजेंटेशन में विभाजित करूंगा। यदि वे 140, 120, और 90 मिलीसेकंड हैं, तो मैं पहले इंटरैक्शन से पहले मुख्य थ्रेड पर कब्जा करने वाले स्टार्टअप कार्य को खोजूंगा, फिर कॉलबैक को छोटा करूंगा और अपडेट के लिए लेआउट और पेंट को कम करूंगा। CLS पहले से ही 0.06 पर पास है, इसलिए इमेज के आयाम और एसिंक्रोनस-सामग्री प्लेसहोल्डर रिग्रेशन गार्ड बने रहते हैं।

मैं एक छोटे कोहोर्ट के लिए रिलीज़ करूंगा, प्रत्येक परिवर्तन के लिए उसके अनुमानित टाइमिंग घटक को स्थानांतरित करने की आवश्यकता होगी, और समान-से-समान RUM और उत्पाद गार्डरेल्स के साथ वर्ज़न की तुलना करूंगा। लैब परफ़ॉर्मेंस बजट प्री-मर्ज रिग्रेशन को रोकते हैं, RUM एक तेज़ वास्तविक-उपयोगकर्ता संकेत देता है, और 28-दिवसीय CrUX विंडो अंतिम पुष्टि प्रदान करती है। मैं इस मुद्दे को केवल तभी बंद करता हूं जब मोबाइल p75 LCP, INP, और CLS सभी त्रुटि दर, रूपांतरण, या एक्सेसिबिलिटी को ख़राब किए बिना 2.5 सेकंड, 200 मिलीसेकंड, और 0.1 तक पहुंच जाते हैं।"

सामान्य गलतियां

• स्थानीय Lighthouse पास होने के कारण फ़ील्ड डेटा को खारिज करना → दो डेटासेट अलग-अलग उपयोगकर्ताओं, समय विंडो, और इंटरैक्शन को कवर करते हैं → पहले URL, डिवाइस, नेटवर्क, रिलीज़, और मेट्रिक के दायरे को सामान्यीकृत करें।
• 80 मिलीसेकंड के TBT को 80 मिलीसेकंड के INP के रूप में पढ़ना → Lighthouse वास्तविक इंटरैक्शन के बिना INP को नहीं माप सकता → प्रभाव के लिए फ़ील्ड INP और निदान के लिए TBT प्लस इंटरैक्शन ट्रेसेस का उपयोग करें।
• केवल साइट-व्यापी औसत को देखना → औसत मोबाइल टेल (tail) और एक असफल टेम्पलेट को छिपाते हैं → मोबाइल और डेस्कटॉप के लिए अलग-अलग p75 की गणना करें, फिर पर्याप्त नमूनों वाले समूहों को खंडित करें।
• LCP धीमा होते ही इमेज को कंप्रेस करना → डिस्कवरी या रेंडर डिले का प्रभुत्व हो सकता है → LCP को चार घटकों में विभाजित करें और असामान्य वाले को बदलें।
• प्रत्येक अबोव-द-फ़ोल्ड संसाधन को प्रीलोड करना → कथित तौर पर महत्वपूर्ण संसाधन एक दूसरे के साथ प्रतिस्पर्धा करते हैं → केवल पुष्टि किए गए LCP संसाधन के लिए प्राथमिकता बढ़ाएं और वाटरफ़ॉल की दोबारा जांच करें।
• केवल क्लिक कॉलबैक को ऑप्टिमाइज़ करना → कॉलबैक से पहले के लंबे कार्य और उसके बाद का लेआउट अभी भी योगदान करते हैं → इनपुट, प्रोसेसिंग, और प्रेजेंटेशन का अलग-अलग निरीक्षण करें।
• CLS को 0.06 से 0.02 तक प्राथमिकता देना → काम एक पासिंग मेट्रिक पर जाता है जबकि LCP और INP अभी भी विफल होते हैं → एक CLS गार्डरेल रखें और थ्रेशोल्ड से बाहर मेट्रिक्स को प्राथमिकता दें।
• चार घटक p75 मानों को जोड़ना → प्रत्येक पर्सेंटाइल एक अलग विज़िट से आ सकता है → केवल एक नेविगेशन के भीतर घटकों को जोड़ें; एकत्रीकरण समय पर अंतिम मेट्रिक पर्सेंटाइल की गणना करें।
• परिनियोजन के दिन RUM गिरने पर जीत की घोषणा करना → नमूना आकार, ट्रैफ़िक मिश्रण, और 28-दिवसीय विंडो स्थिर नहीं हैं → रोलआउट कोहोर्ट्स की तुलना करें, गार्डरेल्स का निरीक्षण करें, और रोलिंग फ़ील्ड पुष्टि की प्रतीक्षा करें।

अनुवर्ती प्रश्न और उत्तर

अनुवर्ती 1: जब कई परीक्षण फ़ोन इसे पुनरुत्पादित नहीं कर सकते हैं तो फ़ील्ड LCP ख़राब क्यों है?

जांचें कि क्या फ़ील्ड मान URL या ऑरिजिन के लिए है, क्या पेज टेम्पलेट को सही ढंग से समूहीकृत किया गया है, और किस भूगोल, नेटवर्क, नेविगेशन प्रकार, या रिलीज़ में धीमे नमूने हैं। यदि परीक्षण उपकरण वास्तविक टेल से चूक जाते हैं, तो धीमे RUM नेविगेशन से कम-कार्डिनैलिटी पर्यावरण लेबल लें और तुलनीय CPU, नेटवर्क, कैश, और प्रमाणीकरण स्थिति को फिर से बनाएं। यदि इसे अभी भी पुनरुत्पादित नहीं किया जा सकता है, तो ऑनलाइन एट्रिब्यूशन साक्ष्य को सुरक्षित रखें। तेज़ उपकरणों को बार-बार चलाने से समस्या का अस्तित्व समाप्त नहीं हो सकता।

अनुवर्ती 2: केवल एक निचले स्तर का Android सेगमेंट INP में विफल रहता है, जबकि वैश्विक p75 पास हो जाता है। क्या आपको इसे ठीक करना चाहिए?

उस सेगमेंट के ट्रैफ़िक, व्यावसायिक महत्व, और नमूना विश्वसनीयता को सत्यापित करें। एक उत्तीर्ण वैश्विक सीमा समग्र वितरण का वर्णन करती है, प्रत्येक महत्वपूर्ण कोहोर्ट का नहीं। यदि डिवाइस टीयर में कई भुगतान करने वाले उपयोगकर्ता हैं या इसका INP 500 मिलीसेकंड से काफी ऊपर है, तो एक सेगमेंट SLO परिभाषित करें और इसे हल करें। यदि नमूना बहुत छोटा है, तो पहले अवलोकन क्षमता (observability) में सुधार करें। प्रत्येक छोटे सेगमेंट को एक कठिन रिलीज़ गेट बनाने से सैंपलिंग का शोर रिलीज़ को रोक देगा।

अनुवर्ती 3: यदि LCP एलिमेंट वेब फ़ॉन्ट का उपयोग करने वाला हेडिंग टेक्स्ट है तो योजना कैसे बदलती है?

रिसोर्स डिस्कवरी एक इमेज से फ़ॉन्ट्स और ब्लॉकिंग स्टाइल्स पर शिफ़्ट हो जाती है। जांचें कि फ़ॉन्ट अनुरोध कब खोजा जाता है, क्या यह ऑरिजिन कनेक्शन, फ़ाइल आकार, font-display, और फ़ॉलबैक-फ़ॉन्ट आयामों को पार करता है, साथ ही क्या हेडिंग क्लाइंट रेंडरिंग की प्रतीक्षा करती है। इमेज fetchpriority योजना की नकल न करें। केवल उन फ़ॉन्ट फ़ाइलों को प्रीलोड करें जिनका उपयोग पहली स्क्रीन वास्तव में करती है, और सत्यापित करें कि इससे डुप्लिकेट डाउनलोड नहीं होते हैं या अधिक महत्वपूर्ण संसाधन विस्थापित नहीं होते हैं।

अनुवर्ती 4: धीमा इंटरैक्शन क्रॉस-ऑरिजिन भुगतान iframe के अंदर है। शीर्ष पेज क्या कर सकता है?

INP एक iframe इंटरैक्शन से उपयोगकर्ता लेटेंसी को प्रतिबिंबित कर सकता है, लेकिन क्रॉस-ऑरिजिन सीमा शीर्ष-पेज एट्रिब्यूशन को सीमित करती है। RUM को एम्बेड वर्ज़न और युक्त पेज के साथ सहसंबंधित करें, प्रदाता या पुनरुत्पादनीय परीक्षण से परफ़ॉर्मेंस साक्ष्य का उपयोग करें, और उस प्रदाता के साथ काम करें। शीर्ष पेज अपने स्वयं के समवर्ती लंबे कार्यों को भी कम कर सकता है। आंतरिक कॉल स्टैक के बिना, साक्ष्य सीमा बताएं: न तो स्वचालित रूप से प्रदाता को दोष दें और न ही दावा करें कि स्थानीय कोड ने iframe को ठीक कर दिया है।

अनुवर्ती 5: पेज पर URL-स्तरीय CrUX डेटा के लिए बहुत कम ट्रैफ़िक है। आप कैसे तय करते हैं कि यह पास है या नहीं?

नमूना आकार और समय विंडो दोनों की रिपोर्ट करते हुए प्रति-विज़िट मेट्रिक्स और आवश्यक पर्यावरण फ़ील्ड एकत्र करने के लिए फ़र्स्ट-पार्टी RUM का उपयोग करें, जबकि लैब क्रिटिकल-यात्रा परीक्षण रिग्रेशन से रक्षा करते हैं। टेम्पलेट-स्तरीय एकत्रीकरण केवल तभी नमूना आकार बढ़ा सकता है जब पेज संरचना और उपयोगकर्ता यात्राएं तुलनीय हों। अपर्याप्त डेटा के साथ, आप साबित कर सकते हैं कि ज्ञात ट्रेसेस में सुधार हुआ है, लेकिन आप URL-स्तर की "अच्छी" CrUX स्थिति का दावा नहीं कर सकते।

अनुवर्ती 6: हीरो को पहले रेंडर करने से LCP में सुधार होता है लेकिन हाइड्रेशन पहले शुरू होता है और INP खराब हो जाता है। अब क्या?

यह एक वास्तविक मेट्रिक ट्रेड-ऑफ़ है, इसलिए दोनों परिणाम रखें। जांचें कि क्या पहले रेंडर करने के लिए वास्तव में पहले हाइड्रेशन की आवश्यकता है। अक्सर स्थिर दृश्य सामग्री पहले आ सकती है जबकि इंटरैक्शन कोड मांग पर लोड होता है। यदि तत्काल इंटरैक्शन एक व्यावसायिक आवश्यकता है, तो महत्वपूर्ण उपयोगकर्ता कार्रवाई के आसपास बजट निर्धारित करें, मुख्य-थ्रेड कार्य को विभाजित करें, और रोलआउट के दौरान LCP, INP, और रूपांतरण की तुलना करें। एक समग्र परफ़ॉर्मेंस स्कोर को INP रिग्रेशन को नहीं छिपाना चाहिए।

अनुवर्ती 7: गोपनीयता नीति पूर्ण URL और DOM लक्ष्यों को संग्रहीत करने से रोकती है। क्या RUM अभी भी समस्या का निदान कर सकता है?

पूर्वनिर्धारित रूट टेम्पलेट्स, घटक इनम (component enums), इंटरैक्शन प्रकार, रिलीज़ वर्ज़न, और मोटे डिवाइस टीयर का उपयोग करें। प्रोडक्ट आईडी, क्वेरी पैरामीटर, टेक्स्ट, या उपयोगकर्ता पहचानकर्ताओं को न रखें। रिपोर्ट करने से पहले क्लाइंट पर फ़ील्ड्स को मैप करें, और सर्वर पर उच्च-कार्डिनैलिटी मानों को अस्वीकार करें। एट्रिब्यूशन कम सटीक हो जाता है, इसलिए लैब पुनरुत्पादन को गणना किए गए घटकों और यात्राओं के आसपास के अंतर को भरना चाहिए। परफ़ॉर्मेंस निदान व्यक्तिगत-डेटा संग्रह का विस्तार करने की अनुमति नहीं है।