फ़ील्ड में परफ़ॉर्मेंस को डीबग करना

डीबग करने से जुड़ी जानकारी के साथ परफ़ॉर्मेंस डेटा को एट्रिब्यूट करने का तरीका जानें. इससे, आपको Analytics का इस्तेमाल करने वाले असली उपयोगकर्ताओं की समस्याओं का पता लगाने और उन्हें ठीक करने में मदद मिलेगी

Philip Walton

Google, परफ़ॉर्मेंस को मेज़र करने और डीबग करने के लिए, दो कैटगरी के टूल उपलब्ध कराता है:

• लैब टूल: ये ऐसे टूल होते हैं जिनमें पेज को सिम्युलेट किए गए एनवायरमेंट में लोड किया जाता है. जैसे, Lighthouse. यह एनवायरमेंट, अलग-अलग स्थितियों को दोहरा सकता है. उदाहरण के लिए, धीमा नेटवर्क और कम कॉन्फ़िगरेशन वाला मोबाइल डिवाइस.
• फ़ील्ड टूल: Chrome उपयोगकर्ता अनुभव रिपोर्ट (CrUX) जैसे टूल. यह Chrome से मिले, असली उपयोगकर्ताओं के एग्रीगेट किए गए डेटा पर आधारित होता है. (ध्यान दें कि PageSpeed Insights और Search Console जैसे टूल से मिले फ़ील्ड डेटा का सोर्स, CrUX डेटा होता है.)

फ़ील्ड टूल से ज़्यादा सटीक डेटा मिलता है. यह डेटा, असल उपयोगकर्ताओं के अनुभव को दिखाता है. हालांकि, लैब टूल से समस्याओं की पहचान करने और उन्हें ठीक करने में मदद मिलती है.

CrUX डेटा से, आपके पेज की असल परफ़ॉर्मेंस के बारे में ज़्यादा जानकारी मिलती है. हालांकि, CrUX स्कोर जानने से आपको यह पता नहीं चलेगा कि परफ़ॉर्मेंस को कैसे बेहतर बनाया जाए.

वहीं दूसरी ओर, Lighthouse समस्याओं की पहचान करेगा और उन्हें ठीक करने के लिए खास सुझाव देगा. हालांकि, Lighthouse सिर्फ़ उन परफ़ॉर्मेंस समस्याओं के लिए सुझाव देगा जो उसे पेज लोड होने के दौरान मिलती हैं. यह उन समस्याओं का पता नहीं लगाता जो सिर्फ़ उपयोगकर्ता के इंटरैक्शन की वजह से होती हैं. जैसे, पेज पर स्क्रोल करना या बटन पर क्लिक करना.

इससे एक अहम सवाल उठता है: फ़ील्ड में मौजूद असली उपयोगकर्ताओं से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी या परफ़ॉर्मेंस की अन्य मेट्रिक के लिए डीबग करने से जुड़ी जानकारी कैसे कैप्चर की जा सकती है?

इस पोस्ट में, इस बारे में पूरी जानकारी दी गई है कि मौजूदा Core Web Vitals मेट्रिक के लिए, डीबग करने की जानकारी इकट्ठा करने के लिए किन एपीआई का इस्तेमाल किया जा सकता है. साथ ही, आपको यह डेटा अपने मौजूदा Analytics टूल में कैप्चर करने के तरीके के बारे में सुझाव दिए गए हैं.

एट्रिब्यूशन और डीबग करने के लिए एपीआई

कुल लेआउट शिफ़्ट (सीएलएस)

वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली सभी Core Web Vitals मेट्रिक में से, CLS शायद वह मेट्रिक है जिसके लिए फ़ील्ड में डीबग करने की जानकारी इकट्ठा करना सबसे ज़रूरी है. सीएलएस को पेज के पूरे लाइफ़टाइम के दौरान मेज़र किया जाता है. इसलिए, उपयोगकर्ता के पेज से इंटरैक्ट करने के तरीके से, लेआउट शिफ़्ट पर काफ़ी असर पड़ सकता है. जैसे, उपयोगकर्ता कितना स्क्रोल करता है, वह किस चीज़ पर क्लिक करता है वगैरह. इससे यह भी पता चलता है कि लेआउट शिफ़्ट होते हैं या नहीं और कौनसे एलिमेंट शिफ़्ट हो रहे हैं.

PageSpeed Insights की इस रिपोर्ट को देखें:

लैब (Lighthouse) से मिले सीएलएस की तुलना में, फ़ील्ड (CrUX डेटा) से मिले सीएलएस की वैल्यू काफ़ी अलग है. ऐसा इसलिए हो सकता है, क्योंकि पेज पर काफ़ी इंटरैक्टिव कॉन्टेंट मौजूद है. हालांकि, Lighthouse में जांच करते समय इसका इस्तेमाल नहीं किया जा रहा है.

हालांकि, अगर आपको यह पता है कि उपयोगकर्ता के इंटरैक्शन से फ़ील्ड डेटा पर असर पड़ता है, तो भी आपको यह जानना होगा कि पेज पर कौनसे एलिमेंट शिफ़्ट हो रहे हैं. इससे 75वें पर्सेंटाइल पर 0.28 का स्कोर मिलता है. LayoutShiftAttribution इंटरफ़ेस की मदद से ऐसा किया जा सकता है.

लेआउट शिफ़्ट एट्रिब्यूशन पाना

LayoutShiftAttribution इंटरफ़ेस, layout-shift की हर उस एंट्री पर दिखता है जिसे Layout Instability API से जनरेट किया जाता है.

इन दोनों इंटरफ़ेस के बारे में ज़्यादा जानकारी के लिए, लेआउट में होने वाले बदलावों को डीबग करना लेख पढ़ें. इस पोस्ट के लिए, आपको यह जानना ज़रूरी है कि डेवलपर के तौर पर, आपको पेज पर होने वाले हर लेआउट शिफ़्ट के साथ-साथ यह भी पता चलता है कि कौनसा एलिमेंट शिफ़्ट हो रहा है.

यहां उदाहरण के तौर पर ऐसा कोड दिया गया है जो हर लेआउट शिफ़्ट के साथ-साथ, शिफ़्ट होने वाले एलिमेंट को भी लॉग करता है:

new PerformanceObserver((list) => {
  for (const {value, startTime, sources} of list.getEntries()) {
    // Log the shift amount and other entry info.
    console.log('Layout shift:', {value, startTime});
    if (sources) {
      for (const {node, curRect, prevRect} of sources) {
        // Log the elements that shifted.
        console.log('  Shift source:', node, {curRect, prevRect});
      }
    }
  }
}).observe({type: 'layout-shift', buffered: true});

हर लेआउट शिफ़्ट को मेज़र करना और उसके डेटा को अपने आंकड़ों के टूल पर भेजना शायद सही नहीं है. हालांकि, सभी शिफ़्ट को मॉनिटर करके, सबसे खराब शिफ़्ट को ट्रैक किया जा सकता है और सिर्फ़ उनकी जानकारी दी जा सकती है.

हमारा मकसद, हर उपयोगकर्ता के लिए होने वाली हर लेआउट शिफ़्ट की पहचान करना और उसे ठीक करना नहीं है. हमारा मकसद, उन लेआउट शिफ़्ट की पहचान करना है जिनसे सबसे ज़्यादा उपयोगकर्ताओं पर असर पड़ता है. इस वजह से, ये लेआउट शिफ़्ट 75वें पर्सेंटाइल पर आपके पेज के सीएलएस में सबसे ज़्यादा योगदान देती हैं.

इसके अलावा, लेआउट में बदलाव होने पर, आपको हर बार सबसे बड़े सोर्स एलिमेंट का हिसाब लगाने की ज़रूरत नहीं है. आपको ऐसा सिर्फ़ तब करना होगा, जब आपको अपने आंकड़ों के विश्लेषण वाले टूल को सीएलएस वैल्यू भेजनी हो.

नीचे दिए गए कोड में, layout-shift एंट्री की एक सूची दी गई है. इन एंट्री से सीएलएस में योगदान मिला है. साथ ही, सबसे बड़े शिफ़्ट से सबसे बड़े सोर्स एलिमेंट की जानकारी मिलती है:

function getCLSDebugTarget(entries) {
  const largestEntry = entries.reduce((a, b) => {
    return a && a.value > b.value ? a : b;
  });
  if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
    const largestSource = largestEntry.sources.reduce((a, b) => {
      return a.node && a.previousRect.width * a.previousRect.height >
          b.previousRect.width * b.previousRect.height ? a : b;
    });
    if (largestSource) {
      return largestSource.node;
    }
  }
}

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

किसी पेज के लिए सीएलएस में सबसे ज़्यादा योगदान देने वाला एलिमेंट, उपयोगकर्ता के हिसाब से अलग-अलग हो सकता है. हालांकि, अगर सभी उपयोगकर्ताओं के लिए इन एलिमेंट को इकट्ठा किया जाता है, तो आपको उन एलिमेंट की सूची जनरेट करने में मदद मिलेगी जो सबसे ज़्यादा उपयोगकर्ताओं को प्रभावित करते हैं.

जब आपको उन एलिमेंट में बदलाव होने की असल वजह पता चल जाएगी और उसे ठीक कर लिया जाएगा, तब आपका Analytics कोड, छोटे बदलावों को आपके पेजों के लिए "सबसे खराब" बदलाव के तौर पर रिपोर्ट करना शुरू कर देगा. आखिरकार, रिपोर्ट किए गए सभी बदलाव इतने कम हो जाएंगे कि आपके पेज, "अच्छा" थ्रेशोल्ड 0.1 के अंदर आ जाएंगे!

सबसे बड़े बदलाव वाले सोर्स एलिमेंट के साथ-साथ, कुछ अन्य मेटाडेटा भी कैप्चर किया जा सकता है. यह मेटाडेटा आपके काम आ सकता है:

• सबसे बड़े बदलाव का समय
• सबसे बड़े बदलाव के समय का यूआरएल पाथ (उन साइटों के लिए जो यूआरएल को डाइनैमिक तरीके से अपडेट करती हैं, जैसे एक पेज का ऐप्लिकेशन).

सबसे बड़ा कॉन्टेंटफ़ुल पेंट (एलसीपी)

फ़ील्ड में एलसीपी की गड़बड़ी ठीक करने के लिए, आपको यह जानकारी होनी चाहिए कि पेज लोड होने के दौरान, सबसे बड़ा एलिमेंट (एलसीपी कैंडिडेट एलिमेंट) कौन-सा था.

ध्यान दें कि ऐसा हो सकता है कि एलसीपी कैंडिडेट एलिमेंट, हर उपयोगकर्ता के लिए अलग-अलग हो. ऐसा एक ही पेज के लिए भी हो सकता है.

ऐसा कई वजहों से हो सकता है:

• उपयोगकर्ताओं के डिवाइसों के स्क्रीन रिज़ॉल्यूशन अलग-अलग होते हैं. इस वजह से, पेज के लेआउट अलग-अलग होते हैं. इसलिए, व्यूपोर्ट में अलग-अलग एलिमेंट दिखते हैं.
• उपयोगकर्ता हमेशा उन पेजों को लोड नहीं करते जिन्हें सबसे ऊपर स्क्रोल किया गया हो. अक्सर लिंक में फ़्रैगमेंट आइडेंटिफ़ायर या टेक्स्ट फ़्रैगमेंट शामिल होते हैं. इसका मतलब है कि आपके पेजों को लोड किया जा सकता है और पेज पर किसी भी स्क्रोल पोज़िशन पर दिखाया जा सकता है.
• मौजूदा उपयोगकर्ता के हिसाब से कॉन्टेंट को मनमुताबिक बनाया जा सकता है. इसलिए, एलसीपी कैंडिडेट एलिमेंट हर उपयोगकर्ता के हिसाब से अलग-अलग हो सकता है.

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

एलसीपी कैंडिडेट एलिमेंट की पहचान करना

JavaScript में एलसीपी कैंडिडेट एलिमेंट का पता लगाने के लिए, Largest Contentful Paint API का इस्तेमाल किया जा सकता है. यह वही एपीआई है जिसका इस्तेमाल एलसीपी टाइम वैल्यू का पता लगाने के लिए किया जाता है.

largest-contentful-paint एंट्री देखते समय, मौजूदा एलसीपी कैंडिडेट एलिमेंट का पता लगाया जा सकता है. इसके लिए, आखिरी एंट्री की element प्रॉपर्टी देखें:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];

  console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});

एलसीपी कैंडिडेट एलिमेंट के बारे में जानने के बाद, इसे अपनी आंकड़ों के विश्लेषण वाले टूल को मेट्रिक वैल्यू के साथ भेजा जा सकता है. सीएलएस की तरह, इससे आपको यह पता चलेगा कि किन एलिमेंट को सबसे पहले ऑप्टिमाइज़ करना ज़रूरी है.

एलसीपी कैंडिडेट एलिमेंट के अलावा, एलसीपी के सब-पार्ट के समय को मेज़र करना भी फ़ायदेमंद हो सकता है. इससे यह तय करने में मदद मिल सकती है कि आपकी साइट के लिए, ऑप्टिमाइज़ेशन के कौनसे चरण काम के हैं.

पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी)

आईएनपी के लिए फ़ील्ड में कैप्चर की जाने वाली सबसे अहम जानकारी ये हैं:

1. किस एलिमेंट के साथ इंटरैक्ट किया गया
2. इंटरैक्शन किस तरह का था
3. वह इंटरैक्शन कब हुआ

इंटरैक्शन धीमे होने की मुख्य वजह, मुख्य थ्रेड का ब्लॉक होना है. ऐसा JavaScript लोड होने के दौरान हो सकता है. अगर आपको यह पता चल जाए कि पेज लोड होने के दौरान, सबसे ज़्यादा धीमे इंटरैक्शन होते हैं, तो समस्या को ठीक करने के लिए ज़रूरी कार्रवाई तय करने में मदद मिलती है.

आईएनपी मेट्रिक, इंटरैक्शन की पूरी लेटेन्सी को ध्यान में रखती है. इसमें रजिस्टर किए गए किसी भी इवेंट लिसनर को चलाने में लगने वाला समय शामिल होता है. साथ ही, इसमें सभी इवेंट लिसनर के चलने के बाद, अगले फ़्रेम को पेंट करने में लगने वाला समय भी शामिल होता है. इसका मतलब है कि आईएनपी के लिए यह जानना बहुत ज़रूरी है कि कौनसे टारगेट एलिमेंट की वजह से इंटरैक्शन धीमे होते हैं और वे किस तरह के इंटरैक्शन हैं.

यहां दिया गया कोड, टारगेट एलिमेंट और आईएनपी एंट्री के समय को लॉग करता है.

function logINPDebugInfo(inpEntry) {
  console.log('INP target element:', inpEntry.target);
  console.log('INP interaction type:', inpEntry.name);
  console.log('INP time:', inpEntry.startTime);
}

ध्यान दें कि इस कोड में यह नहीं दिखाया गया है कि कौनसी event एंट्री, INP एंट्री है. ऐसा इसलिए, क्योंकि यह लॉजिक ज़्यादा जटिल है. हालांकि, यहां बताया गया है कि web-vitals JavaScript लाइब्रेरी का इस्तेमाल करके, यह जानकारी कैसे पाई जा सकती है.

web-vitals JavaScript लाइब्रेरी के साथ इस्तेमाल करना

पिछले सेक्शन में, डीबग करने से जुड़ी जानकारी को कैप्चर करने के लिए कुछ सामान्य सुझाव और कोड के उदाहरण दिए गए हैं. इस जानकारी को, अपनी आंकड़ों के विश्लेषण से जुड़े टूल को भेजे जाने वाले डेटा में शामिल किया जा सकता है.

वर्शन 3 से, web-vitals JavaScript लाइब्रेरी में एक एट्रिब्यूशन बिल्ड शामिल है. यह बिल्ड, इस सारी जानकारी के साथ-साथ कुछ अतिरिक्त सिग्नल भी दिखाता है.

यहां दिए गए कोड के उदाहरण में बताया गया है कि परफ़ॉर्मेंस से जुड़ी समस्याओं की असल वजह का पता लगाने में मदद करने वाली डीबग स्ट्रिंग वाले अतिरिक्त इवेंट पैरामीटर (या कस्टम डाइमेंशन) को कैसे सेट किया जा सकता है.

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

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'CLS':
      eventParams.debug_target = attribution.largestShiftTarget;
      break;
    case 'LCP':
      eventParams.debug_target = attribution.element;
      break;
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      break;
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

यह कोड सिर्फ़ Google Analytics के लिए है. हालांकि, इसका सामान्य सिद्धांत अन्य Analytics टूल पर भी लागू होना चाहिए.

यह कोड सिर्फ़ एक डीबग सिग्नल की रिपोर्ट बनाने का तरीका दिखाता है. हालांकि, हर मेट्रिक के लिए कई अलग-अलग सिग्नल इकट्ठा करना और उनकी रिपोर्ट बनाना फ़ायदेमंद होता है.

उदाहरण के लिए, INP को डीबग करने के लिए, आपको इंटरैक्ट किए जा रहे एलिमेंट, इंटरैक्शन टाइप, समय, loadState, इंटरैक्शन फ़ेज़ वगैरह (जैसे कि लंबे ऐनिमेशन फ़्रेम का डेटा) इकट्ठा करना पड़ सकता है.

web-vitals एट्रिब्यूशन बिल्ड से, एट्रिब्यूशन की अतिरिक्त जानकारी मिलती है. INP के लिए, यहां दिए गए उदाहरण में यह जानकारी दिखाई गई है:

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

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      eventParams.debug_type = attribution.interactionType;
      eventParams.debug_time = attribution.interactionTime;
      eventParams.debug_load_state = attribution.loadState;
      eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
      eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
      eventParams.debug_presentation_delay =  Math.round(attribution.presentationDelay);
      break;

    // Additional metric logic...
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

डीबग करने के लिए उपलब्ध कराए गए सभी सिग्नल की पूरी सूची देखने के लिए, Web Vitals एट्रिब्यूशन दस्तावेज़ देखें.

डेटा की रिपोर्ट बनाना और उसे विज़ुअलाइज़ करना

मेट्रिक वैल्यू के साथ डीबग करने की जानकारी इकट्ठा करने के बाद, अगला चरण यह है कि सभी उपयोगकर्ताओं के डेटा को इकट्ठा किया जाए, ताकि पैटर्न और रुझानों का पता लगाया जा सके.

जैसा कि पहले बताया गया है, यह ज़रूरी नहीं है कि आप उन सभी समस्याओं को ठीक करें जिनका सामना आपके उपयोगकर्ताओं को करना पड़ रहा है. आपको उन समस्याओं को ठीक करना चाहिए जिनका असर सबसे ज़्यादा उपयोगकर्ताओं पर पड़ रहा है. खास तौर पर, शुरुआत में. साथ ही, ये ऐसी समस्याएं होनी चाहिए जिनका आपके Core Web Vitals स्कोर पर सबसे ज़्यादा बुरा असर पड़ा है.

GA4 के लिए, BigQuery का इस्तेमाल करके डेटा की क्वेरी करने और उसे विज़ुअलाइज़ करने के तरीके के बारे में लेख पढ़ें.

खास जानकारी

हमें उम्मीद है कि इस पोस्ट से आपको यह समझने में मदद मिली होगी कि परफ़ॉर्मेंस से जुड़े मौजूदा एपीआई और web-vitals लाइब्रेरी का इस्तेमाल करके, डीबग करने से जुड़ी जानकारी कैसे पाई जा सकती है. इससे आपको फ़ील्ड में असल उपयोगकर्ताओं की विज़िट के आधार पर परफ़ॉर्मेंस का पता लगाने में मदद मिलेगी. इस गाइड में, Core Web Vitals पर फ़ोकस किया गया है. हालांकि, इसमें बताए गए कॉन्सेप्ट, JavaScript में मेज़र की जा सकने वाली किसी भी परफ़ॉर्मेंस मेट्रिक को डीबग करने के लिए भी इस्तेमाल किए जा सकते हैं.

अगर आप एक ऐनलिटिक्स वेंडर हैं और आपको अपने प्रॉडक्ट को बेहतर बनाना है और अपने उपयोगकर्ताओं को डीबग करने से जुड़ी ज़्यादा जानकारी देनी है, तो यहां बताई गई कुछ तकनीकों का इस्तेमाल करें. हालांकि, यहां दिए गए विचारों तक ही सीमित न रहें. यह पोस्ट, आम तौर पर सभी आंकड़ों के विश्लेषण से जुड़े टूल पर लागू होती है. हालांकि, आंकड़ों के विश्लेषण से जुड़े अलग-अलग टूल, डीबग करने से जुड़ी ज़्यादा जानकारी कैप्चर और रिपोर्ट कर सकते हैं. उन्हें ऐसा करना चाहिए.

अगर आपको लगता है कि एपीआई में मौजूद सुविधाओं या जानकारी की कमी की वजह से, इन मेट्रिक को डीबग करने में आपको परेशानी हो रही है, तो अपने सुझाव/राय या शिकायत web-vitals-feedback@googlegroups.com पर भेजें.