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

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

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

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

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

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

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

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

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

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

सीएलएस

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

PageSpeed Insights की इस रिपोर्ट का इस्तेमाल करें:

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

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

LayoutShiftAttribution इंटरफ़ेस से यह काम किया जा सकता है.

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

LayoutShiftAttribution इंटरफ़ेस, हर 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});

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

इसका लक्ष्य, हर उपयोगकर्ता के लिए होने वाले हर एक लेआउट शिफ़्ट की पहचान करना और उसे ठीक करना नहीं है. इसका लक्ष्य उन बदलावों की पहचान करना है जो सबसे ज़्यादा उपयोगकर्ताओं पर असर डालते हैं. साथ ही, इस तरह 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 टूल को इसकी रिपोर्ट दी जा सकती है.

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

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

सबसे बड़े शिफ़्ट सोर्स एलिमेंट के साथ कैप्चर करने के लिए, कुछ और मेटाडेटा मददगार हो सकते हैं:

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

एलसीपी

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

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

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

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

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

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

JavaScript में एलसीपी कैंडिडेट एलिमेंट का पता लगाने के लिए, largestContentful 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});

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

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

एफ़आईडी

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

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

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

अगर आपके ऐप्लिकेशन फ़्रेमवर्क में हाइड्रेशन टाइमस्टैंप दिखता है, तो उसकी तुलना first-input एंट्री के टाइमस्टैंप से की जा सकती है. इससे यह पता चलेगा कि पहला इनपुट, हाइड्रेशन से पहले हुआ है या उसके बाद. अगर आपका फ़्रेमवर्क उस टाइमस्टैंप को नहीं दिखाता है या हाइड्रेशन का इस्तेमाल बिलकुल नहीं करता है, तो हो सकता है कि इनपुट, JavaScript के लोड होने से पहले हुआ हो या उसके बाद.

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

यह कोड, first-input एंट्री और लॉग का पता लगाता है. इससे कोई फ़र्क़ नहीं पड़ता कि DOMContentLoaded इवेंट के खत्म होने से पहले, पहला इनपुट मिला है या नहीं:

new PerformanceObserver((list) => {
  const fidEntry = list.getEntries()[0];
  const navEntry = performance.getEntriesByType('navigation')[0];
  const wasFIDBeforeDCL =
    fidEntry.startTime < navEntry.domContentLoadedEventStart;

  console.log('FID occurred before DOMContentLoaded:', wasFIDBeforeDCL);
}).observe({type: 'first-input', buffered: true});

एफ़आईडी टारगेट एलिमेंट और इवेंट टाइप की पहचान करना

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

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

पहले इनपुट इवेंट से जुड़े इंटरैक्शन टाइप और एलिमेंट को पाने के लिए, first-input एंट्री की target और name प्रॉपर्टी देखें:

new PerformanceObserver((list) => {
  const fidEntry = list.getEntries()[0];

  console.log('FID target element:', fidEntry.target);
  console.log('FID interaction type:', fidEntry.name);
}).observe({type: 'first-input', buffered: true});

आईएनपी

INP, FID से काफ़ी मिलता-जुलता है. इस फ़ील्ड में, कैप्चर की जाने वाली जानकारी के सबसे काम के हिस्से ये हैं:

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

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

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

आईएनपी और एफ़आईडी, दोनों Event Timing API पर आधारित हैं. इसलिए, JavaScript में इस जानकारी को तय करने का तरीका पिछले उदाहरण से काफ़ी मिलता-जुलता है. नीचे दिया गया कोड, आईएनपी एंट्री के टारगेट एलिमेंट और समय (DOMContentLoaded के हिसाब से) को लॉग करता है.

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

  const navEntry = performance.getEntriesByType('navigation')[0];
  const wasINPBeforeDCL =
    inpEntry.startTime < navEntry.domContentLoadedEventStart;

  console.log('INP occurred before DCL:', wasINPBeforeDCL);
}

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

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

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

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

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

import {onCLS, onFID, 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 'FID':
    case 'INP':
      eventParams.debug_target = attribution.eventTarget;
      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, onFID, 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.eventTarget;
      eventParams.debug_type = attribution.eventType;
      eventParams.debug_time = attribution.eventTime;
      eventParams.debug_load_state = attribution.loadState;
      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 पर भेजें.