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

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

Philip Walton

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

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

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

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

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

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

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

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

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

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

PageSpeed Insights की यह रिपोर्ट देखें:

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

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

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

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

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

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

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वें पर्सेंटाइल पर आपके पेज के सीएलएस में सबसे ज़्यादा योगदान होता है.

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

नीचे दिया गया कोड, उन 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 के "अच्छी" थ्रेशोल्ड के अंदर हैं!

कुछ और ऐसे मेटाडेटा जिन्हें सबसे बड़े shift सोर्स एलिमेंट के साथ कैप्चर करने में मदद मिल सकती है:

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

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

फ़ील्ड में एलसीपी को डीबग करने के लिए, आपको जिस मुख्य जानकारी की ज़रूरत होगी वह यह है कि उस खास पेज लोड के लिए कौनसा एलिमेंट सबसे बड़ा एलिमेंट (एलसीपी कैंडिडेट एलिमेंट) था.

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

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

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

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

एलसीपी उम्मीदवार के बारे में बताएं

JavaScript में एलसीपी कैंडिडेट एलिमेंट का पता लगाने के लिए, सबसे बड़े कॉन्टेंटफ़ुल पेंट एपीआई का इस्तेमाल किया जा सकता है. यह वही एपीआई है जिसका इस्तेमाल आप एलसीपी समय की वैल्यू तय करने के लिए करते हैं.

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});

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

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

इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी)

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

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 एंट्री आईएनपी एंट्री है, क्योंकि उसी लॉजिक की मदद से कार्रवाई की जा सकती है. हालांकि, नीचे दिए गए सेक्शन में बताया गया है कि web-वाइटल JavaScript लाइब्रेरी का इस्तेमाल करके, यह जानकारी कैसे पाई जा सकती है.

वेब-वाइटल JavaScript लाइब्रेरी के साथ इस्तेमाल

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

तीसरे वर्शन में, वेब-वाइटल 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);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

यह कोड खास तौर पर Google Analytics के लिए है, लेकिन इस कोड को अन्य Analytics टूल के लिए भी इस्तेमाल किया जाना चाहिए.

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

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

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

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);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

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

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

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

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

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

खास जानकारी

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

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

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

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