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

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

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

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

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

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

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

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

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

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

सीएलएस

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

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

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

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

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

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

LayoutShiftAttribution इंटरफ़ेस, हर layout-shift एंट्री पर दिखता है, जो लेआउट 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});

हर एक लेआउट शिफ़्ट के लिए, डेटा को मेज़र करना और अपने 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 में एलसीपी कैंडिडेट एलिमेंट तय करने के लिए, सबसे बड़े कॉन्टेंटफ़ुल पेंट एपीआई का इस्तेमाल किया जा सकता है. यह वही एपीआई है जिसका इस्तेमाल एलसीपी टाइम की वैल्यू तय करने के लिए किया जाता है.

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

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

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

एफ़आईडी

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

उदाहरण के लिए, सर्वर साइड रेंडरिंग (एसएसआर) के साथ काम करने वाले कई 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});

आईएनपी

आईएनपी, एफ़आईडी से काफ़ी मिलता-जुलता है, क्योंकि फ़ील्ड में कैप्चर की जाने वाली जानकारी के सबसे काम के बिट ये हैं:

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 टूल के लिए बनाई गई है; हालांकि, अलग-अलग Analytics टूल और ज़्यादा डीबग जानकारी को कैप्चर और रिपोर्ट कर सकते हैं (और ऐसा करना चाहिए).

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