कस्टम मेट्रिक

Philip Walton

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

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

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

कस्टम मेट्रिक की मदद से, आपकी साइट पर मिलने वाले अनुभव के उन पहलुओं का आकलन किया जा सकता है जो शायद सिर्फ़ आपकी साइट पर लागू हों, जैसे:

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

कस्टम मेट्रिक मापने के लिए एपीआई

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

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

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

परफ़ॉर्मेंस ऑब्ज़र्वर एपीआई

ब्राउज़र सहायता

  • 52
  • 79
  • 57
  • 11

सोर्स

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

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

PerformanceObserver बनाने के लिए, इसे कॉलबैक पास करें, ताकि जब भी नई परफ़ॉर्मेंस एंट्री भेजी जाएं, तब यह ट्रिगर हो. इसके बाद, ऑब्ज़र्वर को बताएं कि observe() तरीके का इस्तेमाल करके, किस तरह की एंट्री सुननी हैं:

// Catch errors since some browsers throw when using the new `type` option.
// https://bugs.webkit.org/show_bug.cgi?id=209216
try {
  const po = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Log the entry and all associated details.
      console.log(entry.toJSON());
    }
  });

  po.observe({type: 'some-entry-type'});
} catch (e) {
  // Do nothing if the browser doesn't support this API.
}

नीचे दिए गए सेक्शन में निगरानी के लिए उपलब्ध सभी एंट्री टाइप की सूची दी गई है. हालांकि, नए ब्राउज़र में स्टैटिक PerformanceObserver.supportedEntryTypes प्रॉपर्टी की मदद से यह जांच की जा सकती है कि कौनसे एंट्री टाइप उपलब्ध हैं.

पहले ही हो चुकी एंट्री देखें

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

ऐतिहासिक एंट्री (इसके आने के बाद) की जानकारी पाने के लिए, observe() को कॉल करने पर buffered फ़्लैग को true पर सेट करें. जब पहली बार आपके PerformanceObserver कॉलबैक को कॉल किया जाता है, तब ब्राउज़र अपने परफ़ॉर्मेंस एंट्री बफ़र से ऐतिहासिक एंट्री शामिल करेगा.

po.observe({
  type: 'some-entry-type',
  buffered: true,
});

लेगसी परफ़ॉर्मेंस एपीआई का इस्तेमाल न करें

परफ़ॉर्मेंस पर आधारित एपीआई के पहले, डेवलपर performance ऑब्जेक्ट पर बताए गए इन तीन तरीकों का इस्तेमाल करके, परफ़ॉर्मेंस एंट्री को ऐक्सेस कर सकते थे:

ये एपीआई अब भी काम करते हैं. हालांकि, इन्हें इस्तेमाल करने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि ये नई एंट्री जनरेट होने पर आपको सूचना नहीं देते. इसके अलावा, कई नए एपीआई (जैसे कि लंबे टास्क) performance ऑब्जेक्ट से नहीं दिखाए जाते. वे सिर्फ़ PerformanceObserver से दिखते हैं.

अगर आपको खास तौर पर Internet Explorer के साथ काम करने की ज़रूरत न हो, तो अपने कोड में इन तरीकों का इस्तेमाल न करें और PerformanceObserver का इस्तेमाल करें.

उपयोगकर्ता समय API

User Timing API समय पर आधारित मेट्रिक के लिए अलग-अलग कामों के लिए इस्तेमाल होने वाला मेज़रमेंट एपीआई है. इसकी मदद से, अपनी मर्ज़ी से समय पर पॉइंट मार्क किए जा सकते हैं और बाद में, उन मार्क के बीच की अवधि को मापा जा सकता है.

// Record the time immediately before running a task.
performance.mark('myTask:start');
await doMyTask();

// Record the time immediately after running a task.
performance.mark('myTask:end');

// Measure the delta between the start and end of the task
performance.measure('myTask', 'myTask:start', 'myTask:end');

Date.now() या performance.now() जैसे एपीआई से आपको मिलती-जुलती सुविधाएं मिलती हैं. हालांकि, User Timing API के इस्तेमाल का फ़ायदा यह है कि यह परफ़ॉर्मेंस टूल के साथ अच्छी तरह से इंटिग्रेट हो जाता है. उदाहरण के लिए, Chrome DevTools परफ़ॉर्मेंस पैनल में उपयोगकर्ता समय के मेज़रमेंट को विज़ुअलाइज़ करता है. साथ ही, आंकड़ों की सेवा देने वाली कई कंपनियां आपके किसी भी मेज़रमेंट को अपने-आप ट्रैक करती हैं और कुल समय का डेटा अपने ऐनलिटिक्स बैकएंड में भेजती हैं.

उपयोगकर्ता समय को मेज़र करने वाली जानकारी को रिपोर्ट करने के लिए, PerformanceObserver का इस्तेमाल करके measure टाइप की एंट्री पर नज़र रखने के लिए रजिस्टर किया जा सकता है:

// Catch errors since some browsers throw when using the new `type` option.
// https://bugs.webkit.org/show_bug.cgi?id=209216
try {
  // Create the performance observer.
  const po = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Log the entry and all associated details.
      console.log(entry.toJSON());
    }
  });

  // Start listening for `measure` entries to be dispatched.
  po.observe({type: 'measure', buffered: true});
} catch (e) {
  // Do nothing if the browser doesn't support this API.
}

लंबे टास्क एपीआई

ब्राउज़र सहायता

  • 58
  • 79
  • x
  • x

सोर्स

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

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

यह तय करने के लिए कि लंबे टास्क कब हों, PerformanceObserver का इस्तेमाल करके, longtask टाइप की एंट्री पर नज़र रखने के लिए रजिस्टर करें:

// Catch errors since some browsers throw when using the new `type` option.
// https://bugs.webkit.org/show_bug.cgi?id=209216
try {
  // Create the performance observer.
  const po = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Log the entry and all associated details.
      console.log(entry.toJSON());
    }
  });

  // Start listening for `longtask` entries to be dispatched.
  po.observe({type: 'longtask', buffered: true});
} catch (e) {
  // Do nothing if the browser doesn't support this API.
}

एलिमेंट टाइमिंग एपीआई

ब्राउज़र सहायता

  • 77
  • 79
  • x
  • x

सोर्स

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

इन मामलों के लिए, Element Timing API का इस्तेमाल करें. LCP API को Element Timing API पर सबसे ऊपर बनाया गया है और यह सबसे बड़े एलिमेंट की अपने-आप रिपोर्टिंग करता है. हालांकि, आपके पास दूसरे एलिमेंट की रिपोर्ट को रिपोर्ट करने का भी विकल्प है. इसके लिए, उनमें elementtiming एट्रिब्यूट को साफ़ तौर पर जोड़ें और element एंट्री टाइप को ट्रैक करने के लिए, Performanceऑब्ज़ेक्ट को रजिस्टर करें.

<img elementtiming="hero-image" />
<p elementtiming="important-paragraph">This is text I care about.</p>
<!-- ... -->

<script>
  // Catch errors since some browsers throw when using the new `type` option.
  // https://bugs.webkit.org/show_bug.cgi?id=209216
  try {
    // Create the performance observer.
    const po = new PerformanceObserver((entryList) => {
      for (const entry of entryList.getEntries()) {
        // Log the entry and all associated details.
        console.log(entry.toJSON());
      }
    });

    // Start listening for `element` entries to be dispatched.
    po.observe({type: 'element', buffered: true});
  } catch (e) {
    // Do nothing if the browser doesn't support this API.
  }
</script>

इवेंट समय API

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

आईएनपी मेट्रिक को Event Timing API की मदद से बनाया गया है. यह एपीआई, इवेंट के लाइफ़साइकल के दौरान होने वाले कई टाइमस्टैंप दिखाता है. इनमें ये शामिल हैं:

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

नीचे दिए गए उदाहरण में, कस्टम मेज़रमेंट बनाने के लिए इन वैल्यू का इस्तेमाल करने का तरीका बताया गया है:

// Catch errors some browsers throw when using the new `type` option.
// https://bugs.webkit.org/show_bug.cgi?id=209216
try {
  const po = new PerformanceObserver((entryList) => {
    // Get the last interaction observed:
    const entries = Array.from(entryList.getEntries()).forEach((entry) => {
      // Get various bits of interaction data:
      const inputDelay = entry.processingStart - entry.startTime;
      const processingTime = entry.processingEnd - entry.processingStart;
      const duration = entry.duration;
      const eventType = entry.name;
      const target = entry.target || "(not set)"

      console.log("----- INTERACTION -----");
      console.log(`Input delay (ms): ${inputDelay}`);
      console.log(`Event handler time (ms): ${processingTime}`);
      console.log(`Total event duration (ms): ${duration}`);
      console.log(`Event type: ${eventType}`);
      console.log(target);
    });
  });

  // A durationThreshold of 16ms is necessary to surface more
  // interactions, since the default is 104ms. The minimum
  // durationThreshold is 16ms.
  po.observe({type: 'event', buffered: true, durationThreshold: 16});
} catch (error) {
  // Do nothing if the browser doesn't support this API.
}

संसाधन समय API

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

  • initiatorType: संसाधन को फ़ेच करने का तरीका: जैसे कि <script> या <link> टैग से या fetch() कॉल से.
  • nextHopProtocol: वह प्रोटोकॉल जिसका इस्तेमाल संसाधन को फ़ेच करने के लिए किया जाता है, जैसे कि h2 या quic.
  • encodedBodySize/decodedBodySize]: रिसॉर्स का साइज़, कोड में बदले गए या डिकोड किए गए फ़ॉर्म में (क्रमशीय रूप से)
  • transferSize: नेटवर्क पर ट्रांसफ़र किए गए संसाधन का साइज़. जब संसाधनों को कैश मेमोरी में सेव किया जाता है, तब यह वैल्यू, encodedBodySize से काफ़ी कम हो सकती है. कुछ मामलों में यह वैल्यू शून्य भी हो सकती है. ऐसा तब होता है, जब कैश मेमोरी में सेव किए गए डेटा की दोबारा पुष्टि करने की ज़रूरत न हो.

कैश हिट रेट मेट्रिक या कैश मेमोरी में सेव किए गए संसाधन के साइज़ की मेट्रिक मेज़र करने के लिए, रिसॉर्स टाइमिंग एंट्री की transferSize प्रॉपर्टी का इस्तेमाल किया जा सकता है. इससे यह समझने में मदद मिल सकती है कि आपकी साइट पर आने वाले लोगों के लिए, रिसॉर्स कैश करने की रणनीति किस तरह से परफ़ॉर्मेंस पर असर डालती है.

नीचे दिए गए उदाहरण में, पेज के अनुरोध किए गए सभी रिसॉर्स लॉग किए गए हैं. साथ ही, यह भी बताया गया है कि हर रिसॉर्स, कैश मेमोरी से पूरा हुआ है या नहीं.

// Catch errors since some browsers throw when using the new `type` option.
// https://bugs.webkit.org/show_bug.cgi?id=209216
try {
  // Create the performance observer.
  const po = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // If transferSize is 0, the resource was fulfilled via the cache.
      console.log(entry.name, entry.transferSize === 0);
    }
  });

  // Start listening for `resource` entries to be dispatched.
  po.observe({type: 'resource', buffered: true});
} catch (e) {
  // Do nothing if the browser doesn't support this API.
}

ब्राउज़र सहायता

  • 57
  • 12
  • 58
  • 15

सोर्स

नेविगेशन टाइमिंग एपीआई, Resource Timing API की तरह है. हालांकि, यह सिर्फ़ नेविगेशन अनुरोधों की रिपोर्ट करता है. navigation एंट्री टाइप, resource एंट्री टाइप से भी मिलता-जुलता है. हालांकि, इसमें सिर्फ़ नेविगेशन के अनुरोधों (जैसे कि DOMContentLoaded और load इवेंट ट्रिगर होने पर) के लिए कुछ ज़्यादा जानकारी मौजूद होती है.

एक मेट्रिक जिसे कई डेवलपर सर्वर से जवाब मिलने के समय को समझने के लिए ट्रैक करते हैं (पहली बाइट का समय (टीटीएफ़बी)), नेविगेशन टाइमिंग एपीआई का इस्तेमाल करके उपलब्ध होती है—खास तौर पर, यह एंट्री का responseStart टाइमस्टैंप है.

// Catch errors since some browsers throw when using the new `type` option.
// https://bugs.webkit.org/show_bug.cgi?id=209216
try {
  // Create the performance observer.
  const po = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // If transferSize is 0, the resource was fulfilled via the cache.
      console.log('Time to first byte', entry.responseStart);
    }
  });

  // Start listening for `navigation` entries to be dispatched.
  po.observe({type: 'navigation', buffered: true});
} catch (e) {
  // Do nothing if the browser doesn't support this API.
}

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

किसी खास नेविगेशन अनुरोध के लिए सर्विस वर्कर के शुरू होने का समय, entry.responseStart और entry.workerStart के बीच के डेल्टा से तय किया जा सकता है.

// Catch errors since some browsers throw when using the new `type` option.
// https://bugs.webkit.org/show_bug.cgi?id=209216
try {
  // Create the performance observer.
  const po = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      console.log('Service Worker startup time:',
          entry.responseStart - entry.workerStart);
    }
  });

  // Start listening for `navigation` entries to be dispatched.
  po.observe({type: 'navigation', buffered: true});
} catch (e) {
  // Do nothing if the browser doesn't support this API.
}

सर्वर टाइमिंग एपीआई

Server Timing API की मदद से रिस्पॉन्स हेडर के ज़रिए, अनुरोध के समय के हिसाब से अपने सर्वर से ब्राउज़र में डेटा भेजने की सुविधा मिलती है. उदाहरण के लिए, आपके पास यह बताने का विकल्प होता है कि किसी अनुरोध के लिए, डेटाबेस में डेटा खोजने में कितना समय लगा. इसका इस्तेमाल, सर्वर पर धीमी रफ़्तार से परफ़ॉर्मेंस की समस्याओं को डीबग करने में किया जा सकता है.

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

अपने रिस्पॉन्स में सर्वर टाइमिंग का डेटा शामिल करने के लिए, Server-Timing रिस्पॉन्स हेडर का इस्तेमाल किया जा सकता है. यहां एक उदाहरण दिया गया है.

HTTP/1.1 200 OK

Server-Timing: miss, db;dur=53, app;dur=47.2

इसके बाद, अपने पेजों से इस डेटा को Resource Timing और Navigation Timing एपीआई की resource या navigation, दोनों एंट्री में पढ़ा जा सकता है.

// Catch errors since some browsers throw when using the new `type` option.
// https://bugs.webkit.org/show_bug.cgi?id=209216
try {
  // Create the performance observer.
  const po = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Logs all server timing data for this response
      console.log('Server Timing', entry.serverTiming);
    }
  });

  // Start listening for `navigation` entries to be dispatched.
  po.observe({type: 'navigation', buffered: true});
} catch (e) {
  // Do nothing if the browser doesn't support this API.
}