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

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

Jeremy Wagner

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DNS लुकअप

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

• domainLookupStart तब होता है, जब डीएनएस लुकअप शुरू होता है.
• 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 दस्तावेज़ अनलोड हो रहे हैं.
• दस्तावेज़ प्रोसेसिंग: जब तक आपकी वेबसाइट बहुत बड़े एचटीएमएल पेलोड नहीं भेजती, तब तक हो सकता है कि दस्तावेज़ प्रोसेस होने में लगने वाला समय अलग-अलग न हो. अगर यह आपकी स्थिति के बारे में बताता है, तो 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 या fetch जिसमें keepalive विकल्प सेट हो. दोनों तरीकों से अनुरोध, ब्लॉक न करने वाले तरीके से किसी बताए गए एंडपॉइंट पर भेजा जाएगा. साथ ही, अनुरोध को ऐसी सूची में भेजा जाएगा जो मौजूदा पेज सेशन से अलग हो, अगर ज़रूरी हो:

// 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 का इस्तेमाल.
• नेविगेशन टाइमिंग एपीआई (MDN)
• रिसॉर्स टाइमिंग एपीआई (एमडीएन)

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