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

Philip Walton

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

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

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

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

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

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

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

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

  • 52
  • 79
  • 57
  • 11

सोर्स

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

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

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

// Catch errors that 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 ऑब्जेक्ट सिर्फ़ एंट्री होने पर ही उन्हें मॉनिटर कर सकते हैं. अगर आप अपना परफ़ॉर्मेंस Analytics कोड लेज़ी-लोड करना चाहते हैं, तो इससे समस्या हो सकती है, ताकि वह ज़्यादा प्राथमिकता वाले संसाधनों को ब्लॉक न करे.

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

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

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

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

इसके अलावा, performance ऑब्जेक्ट से कई नए एपीआई (जैसे, लंबे टास्क) नहीं दिखते. इन्हें सिर्फ़ PerformanceObserver दिखाता है. इसलिए, अगर आपको खास तौर पर Internet Explorer के साथ काम करने की ज़रूरत न हो, तो बेहतर होगा कि आप अपने कोड में इन तरीकों का इस्तेमाल न करें. साथ ही, आने वाले समय में PerformanceObserver का इस्तेमाल करें.

उपयोगकर्ता समय एपीआई

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

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

// Catch errors 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.
  po.observe({type: 'measure', buffered: true});
} catch (e) {
  // Do nothing if the browser doesn't support this API.
}

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

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

  • 58
  • 79
  • x
  • x

सोर्स

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

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

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

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) => {
    const firstInput = entryList.getEntries()[0];

    // Measure First Input Delay (FID).
    const firstInputDelay = firstInput.processingStart - firstInput.startTime;

    // Measure the time it takes to run all event handlers
    // Doesn't include work scheduled asynchronously using methods like
    // `requestAnimationFrame()` or `setTimeout()`.
    const firstInputProcessingTime = firstInput.processingEnd - firstInput.processingStart;

    // Measure the entire duration of the event, from when input is received by
    // the browser until the next frame can be painted after processing all
    // event handlers.
    // Doesn't include work scheduled asynchronously using
    // `requestAnimationFrame()` or `setTimeout()`.
    // For security reasons, this value is rounded to the nearest 8 ms.
    const firstInputDuration = firstInput.duration;

    // Log these values to the console.
    console.log({
      firstInputDelay,
      firstInputProcessingTime,
      firstInputDuration,
    });
  });

  po.observe({type: 'first-input', buffered: true});
} 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 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  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 using 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 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 रिस्पॉन्स हेडर का इस्तेमाल करें. यहां एक उदाहरण दिया गया है:

HTTP/1.1 200 OK

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

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

// Catch errors 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.
}