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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• getEntries()
• getEntriesByName()
• getEntriesByType()

ये एपीआई अब भी काम करते हैं. हालांकि, इन्हें इस्तेमाल करने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि ये नई एंट्री जनरेट होने पर आपको सूचना नहीं देते. इसके अलावा, कई नए एपीआई (जैसे कि largest-contentful-paint) को 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 टाइप की एंट्री पर नज़र रखने के लिए रजिस्टर किया जा सकता है:

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

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

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

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

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

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

लंबा एनिमेशन फ़्रेम API

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

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

// 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 `long-animation-frame` entries to be dispatched.
po.observe({type: 'long-animation-frame', buffered: true});

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

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

इन मामलों के लिए, 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>
  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});
</script>

इवेंट समय API

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

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

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

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

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 presentationDelay = entry.startTime + entry.duration - entry.processingEnd;
    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 processing time (ms): ${processingTime}`);
    console.log(`Presentation delay (ms): ${presentationDelay}`);
    console.log(`Total event duration (ms): ${duration}`);
    console.log(`Event type: ${eventType}`);
    console.log(target);
  });
});

// A durationThreshold of 16ms is necessary to include more
// interactions, since the default is 104ms. The minimum
// durationThreshold is 16ms.
po.observe({type: 'event', buffered: true, durationThreshold: 16});

संसाधन समय API

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

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

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

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

// 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(entry.name, entry.transferSize === 0);
  }
});

// Start listening for `resource` entries to be dispatched.
po.observe({type: 'resource', buffered: true});

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

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

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

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

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

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

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

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

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, दोनों एंट्री में पढ़ा जा सकता है.

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