नेविगेशन टाइमिंग और रिसॉर्स टाइमिंग की मदद से, फ़ील्ड में लोड होने की परफ़ॉर्मेंस का आकलन करने का तरीका

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

Jeremy Wagner

पब्लिश करने की तारीख: 8 अक्टूबर, 2021

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

सिंथेटिक टेस्टिंग अपने-आप में खराब नहीं है. हालांकि, इससे यह पता नहीं चलता कि आपकी वेबसाइट, असल उपयोगकर्ताओं के लिए कितनी तेज़ी से लोड हो रही है. इसके लिए फ़ील्ड डेटा की ज़रूरत होती है, जिसे आप Navigation Timing और Resource Timing API से इकट्ठा कर सकते हैं.

फ़ील्ड में लोडिंग की परफ़ॉर्मेंस का आकलन करने में आपकी मदद करने वाले एपीआई

नेविगेशन टाइमिंग और रिसॉर्स टाइमिंग, एक जैसे दो एपीआई हैं. इनमें काफ़ी ओवरलैप होता है और ये दो अलग-अलग चीज़ों को मेज़र करते हैं:

• नेविगेशन टाइमिंग, HTML दस्तावेज़ों के अनुरोधों की स्पीड को मेज़र करता है. इसका मतलब है कि नेविगेशन के अनुरोधों की स्पीड.
• संसाधन समय, दस्तावेज़ पर आधारित संसाधनों, जैसे कि सीएसएस, JavaScript, इमेज, और दूसरी तरह के रिसॉर्स के लिए अनुरोधों की स्पीड को मापता है.

ये एपीआई, अपना डेटा परफ़ॉर्मेंस एंट्री बफ़र में दिखाते हैं. इसे ब्राउज़र में JavaScript की मदद से ऐक्सेस किया जा सकता है. परफ़ॉर्मेंस बफ़र के बारे में क्वेरी करने के कई तरीके हैं. हालांकि, आम तौर पर performance.getEntriesByType का इस्तेमाल किया जाता है:

// Get Navigation Timing entries:
performance.getEntriesByType('navigation');

// Get Resource Timing entries:
performance.getEntriesByType('resource');

performance.getEntriesByType, ऐसी स्ट्रिंग स्वीकार करता है जिसमें बताया गया हो कि आपको परफ़ॉर्मेंस एंट्री बफ़र से किस तरह की एंट्री वापस लानी हैं. 'navigation' और 'resource', नेविगेशन टाइमिंग और Resource Timing एपीआई के लिए समय हासिल करते हैं.

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

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

नेटवर्क अनुरोध की अवधि और समय

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

Chrome DevTools के नेटवर्क पैनल में, नेटवर्क अनुरोध का विज़ुअलाइज़ेशन

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

ध्यान दें: इस गाइड को पढ़ते समय, नेविगेशन टाइमिंग और रिसॉर्स टाइमिंग, दोनों के लिए टाइमिंग का डायग्राम उपलब्ध है. इससे, अनुरोध में लगने वाले समय के सोर्स के क्रम को विज़ुअलाइज़ करने में मदद मिल सकती है.

DNS लुकअप

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

• domainLookupStart वह समय होता है जब DNS लुकअप शुरू होता है.
• domainLookupEnd वह समय होता है जब डीएनएस लुकअप खत्म होता है.

डीएनएस लुकअप के कुल समय का हिसाब लगाने के लिए, खत्म होने की मेट्रिक से शुरू होने की मेट्रिक को घटाएं:

// Measuring DNS lookup time
const [pageNav] = performance.getEntriesByType('navigation');
const totalLookupTime = pageNav.domainLookupEnd - pageNav.domainLookupStart;

चेतावनी: यह हमेशा नहीं होता कि समय अपने-आप भर जाए. कुछ मामलों में, दोनों एपीआई में दी गई समयावधि की वैल्यू 0 होगी. उदाहरण के लिए, डीएनएस लुकअप को किसी लोकल कैश से दिखाया जा सकता है. इसके अलावा, अगर ऑरिजिन Timing-Allow-Origin रिस्पॉन्स हेडर सेट नहीं करते हैं, तो हो सकता है कि क्रॉस-ऑरिजिन अनुरोधों के लिए कोई भी समय उपलब्ध न हो.

कनेक्शन के लिए बातचीत

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

• connectStart तब ट्रिगर होता है, जब ब्राउज़र किसी वेब सर्वर से कनेक्ट होना शुरू करता है.
• secureConnectionStart, क्लाइंट के TLS बातचीत शुरू करने के समय को मार्क करता है.
• connectEnd का मतलब है कि वेब सर्वर से कनेक्शन बन गया है.

कनेक्शन के कुल समय को मेज़र करना, डीएनएस लुकअप के कुल समय को मेज़र करने जैसा ही है: इसके लिए, खत्म होने के समय से शुरू होने के समय को घटाएं. हालांकि, एक और secureConnectionStart प्रॉपर्टी होती है, जो 0 हो सकती है. ऐसा तब होता है, जब एचटीटीपीएस का इस्तेमाल न किया गया हो या कनेक्शन लगातार बना रहे. अगर आपको TLS समझौते के लिए लगने वाले समय को मेज़र करना है, तो आपको इन बातों का ध्यान रखना होगा:

// Quantifying total connection time
const [pageNav] = performance.getEntriesByType('navigation');
const connectionTime = pageNav.connectEnd - pageNav.connectStart;
let tlsTime = 0; // <-- Assume 0 to start with

// Was there TLS negotiation?
if (pageNav.secureConnectionStart > 0) {
  // Awesome! Calculate it!
  tlsTime = pageNav.connectEnd - pageNav.secureConnectionStart;
}

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

अनुरोध और जवाब

लोडिंग की परफ़ॉर्मेंस पर दो तरह के फ़ैक्टर असर डालते हैं:

• बाहरी फ़ैक्टर: इनमें इंतज़ार का समय और बैंडविड्थ जैसी चीज़ें शामिल हैं. होस्टिंग कंपनी और शायद सीडीएन चुनने के अलावा, ये (ज़्यादातर) हमारे कंट्रोल से बाहर होते हैं. ऐसा इसलिए, क्योंकि उपयोगकर्ता वेब को कहीं से भी ऐक्सेस कर सकते हैं.
• इंटिग्रल फ़ैक्टर: इनमें सर्वर और क्लाइंट-साइड आर्किटेक्चर के साथ-साथ, संसाधन का साइज़ और उन चीज़ों को ऑप्टिमाइज़ करने की हमारी क्षमता शामिल है जो हमारे कंट्रोल में हैं.

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

• fetchStart, नेविगेशन अनुरोध के लिए ब्राउज़र के किसी संसाधन (संसाधन के लोड होने में लगने वाला समय) या दस्तावेज़ को फ़ेच करने की शुरुआत के समय को मार्क करता है (नेविगेशन के लोड होने में लगने वाला समय). यह असल अनुरोध से पहले आता है और इसी जगह पर ब्राउज़र कैश मेमोरी की जांच करता है (उदाहरण के लिए, एचटीटीपी और Cache इंस्टेंस).
• workerStart तब मार्क होता है, जब कोई अनुरोध, सर्विस वर्कर के fetch इवेंट हैंडलर में हैंडल किया जाता है. जब कोई सर्विस वर्कर मौजूदा पेज को कंट्रोल नहीं कर रहा होगा, तब यह 0 होगा.
• requestStart वह समय होता है जब ब्राउज़र अनुरोध करता है.
• responseStart तब है, जब रिस्पॉन्स का पहला बाइट मिलता है.
• responseEnd वह समय होता है जब जवाब का आखिरी बाइट मिलता है.

ये समय आपको लोड होने की परफ़ॉर्मेंस के कई पहलुओं को मापने की सुविधा देते हैं, जैसे कि सर्विस वर्कर में कैश लुकअप और डाउनलोड के समय:

// Cache seek plus response time of the current document
const [pageNav] = performance.getEntriesByType('navigation');
const fetchTime = pageNav.responseEnd - pageNav.fetchStart;

// Service worker time plus response time
let workerTime = 0;

if (pageNav.workerStart > 0) {
  workerTime = pageNav.responseEnd - pageNav.workerStart;
}

अनुरोध और जवाब मिलने में लगने वाले समय के अन्य पहलुओं को भी मेज़र किया जा सकता है:

const [pageNav] = performance.getEntriesByType('navigation');

// Request time only (excluding redirects, DNS, and connection/TLS time)
const requestTime = pageNav.responseStart - pageNav.requestStart;

// Response time only (download)
const responseTime = pageNav.responseEnd - pageNav.responseStart;

// Request + response time
const requestResponseTime = pageNav.responseEnd - pageNav.requestStart;

अन्य मेज़रमेंट

नेविगेशन टाइमिंग और रिसॉर्स टाइमिंग, ऊपर दिए गए उदाहरणों के अलावा और भी कामों के लिए फ़ायदेमंद है. यहां कुछ ऐसी अन्य स्थितियां दी गई हैं जिनमें सही समय का इस्तेमाल किया जा सकता है:

• पेज रीडायरेक्ट: रीडायरेक्ट, रीडायरेक्ट चेन के साथ-साथ, लैटेंसी बढ़ाने का एक ऐसा सोर्स है जिस पर अक्सर ध्यान नहीं दिया जाता. इंतज़ार का समय कई तरीकों से जुड़ता है. जैसे, एचटीटीपी से एचटीटीपीएस पर जाने में लगने वाला समय. इसके अलावा, 302/कैश मेमोरी में सेव नहीं किए गए 301 रीडायरेक्ट भी इंतज़ार का समय बढ़ाते हैं. redirectStart, redirectEnd, और redirectCount के समय से, रीडायरेक्ट में लगने वाले समय का आकलन करने में मदद मिलती है.
• दस्तावेज़ को अनलोड करना: जिन पेजों पर unload इवेंट हैंडलर में कोड चलाया जाता है उन पर, अगले पेज पर जाने से पहले ब्राउज़र को उस कोड को लागू करना होगा. unloadEventStart और unloadEventEnd दस्तावेज़ अनलोड हो रहे हैं.
• दस्तावेज़ प्रोसेस करने में लगने वाला समय: दस्तावेज़ प्रोसेस करने में लगने वाला समय तब तक मायने नहीं रखता, जब तक आपकी वेबसाइट बहुत बड़े HTML पेलोड नहीं भेजती. अगर इस वजह से आपकी स्थिति बेहतर होती है, तो domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, और domComplete के समय आपके हिसाब से सही हो सकते हैं.

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

अपने कोड में समयावधि देखने का तरीका

अब तक दिखाए गए सभी उदाहरणों में performance.getEntriesByType का इस्तेमाल किया गया है. हालांकि, परफ़ॉर्मेंस एंट्री बफ़र से क्वेरी करने के अन्य तरीके भी हैं, जैसे कि performance.getEntriesByName और performance.getEntries. अगर आपको सिर्फ़ सामान्य विश्लेषण की ज़रूरत है, तो ये तरीके ठीक हैं. हालांकि, अन्य स्थितियों में, वे बड़ी संख्या में एंट्री को दोहराकर या नई एंट्री ढूंढने के लिए परफ़ॉर्मेंस बफ़र की बार-बार पोलिंग करके, मुख्य थ्रेड का बहुत ज़्यादा काम शुरू कर सकते हैं.

परफ़ॉर्मेंस एंट्री बफ़र से एंट्री इकट्ठा करने के लिए, PerformanceObserver का इस्तेमाल करने का सुझाव दिया जाता है. PerformanceObserver परफ़ॉर्मेंस एंट्री सुनता है और बफ़र में जुड़ते ही यह उपलब्ध कराता है:

// Create the performance observer:
const perfObserver = new PerformanceObserver((observedEntries) => {
  // Get all resource entries collected so far:
  const entries = observedEntries.getEntries();

  // Iterate over entries:
  for (let i = 0; i < entries.length; i++) {
    // Do the work!
  }
});

// Run the observer for Navigation Timing entries:
perfObserver.observe({
  type: 'navigation',
  buffered: true
});

// Run the observer for Resource Timing entries:
perfObserver.observe({
  type: 'resource',
  buffered: true
});

ध्यान दें: परफ़ॉर्मेंस ऑब्ज़र्वर के observe इवेंट में buffered विकल्प जोड़ने से यह पक्का होता है कि परफ़ॉर्मेंस ऑब्ज़र्वर के इंस्टैंशिएशन से पहले बफ़र में जोड़ी गई परफ़ॉर्मेंस एंट्री को देखा जा सकता है.

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

घर पर फ़ोन करने का तरीका

ज़रूरी समयावधि इकट्ठा करने के बाद, उन्हें आगे के विश्लेषण के लिए एंडपॉइंट पर भेजा जा सकता है. ऐसा करने के दो तरीके हैं: navigator.sendBeacon या keepalive विकल्प के साथ fetch सेट करें. दोनों तरीके, किसी खास एंडपॉइंट पर बिना ब्लॉक किए अनुरोध भेजेंगे. साथ ही, अनुरोध को इस तरह से कतार में लगाया जाएगा कि ज़रूरत पड़ने पर वह मौजूदा पेज सेशन से ज़्यादा समय तक बना रहे:

// Check for navigator.sendBeacon support:
if ('sendBeacon' in navigator) {
  // Caution: If you have lots of performance entries, don't
  // do this. This is an example for illustrative purposes.
  const data = JSON.stringify(performance.getEntries());

  // Send the data!
  navigator.sendBeacon('/analytics', data);
}

इस उदाहरण में, JSON स्ट्रिंग POST पेलोड में आएगी. इसे ज़रूरत के हिसाब से, डिकोड, प्रोसेस, और ऐप्लिकेशन के बैकएंड में सेव किया जा सकता है.

नतीजा

मेट्रिक इकट्ठा करने के बाद, यह तय करना आपका काम है कि फ़ील्ड के डेटा का विश्लेषण कैसे करना है. फ़ील्ड डेटा का विश्लेषण करते समय, कुछ सामान्य नियमों का पालन करना ज़रूरी है, ताकि यह पक्का हो सके कि आप सही नतीजे पा रहे हैं:

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

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

• नेविगेशन के लिए समय तय करने की सुविधा.
• संसाधन समय की जानकारी.
• ResourceTiming का इस्तेमाल.
• Navigation Timing API (MDN)
• Resource Timing API (MDN)

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