PerformanceObserver के साथ विश्वसनीय रियल-यूज़र मॉनिटरिंग (RUM) कैसे बनाएं?

1. प्रश्न

विश्व स्तर पर एक्सेस किए जाने वाले एक सिंगल-पेज ऐप को विभिन्न डिवाइसों, नेटवर्कों और रिलीज़ों में अनुभवों की तुलना करने के लिए रियल-यूज़र परफॉर्मेंस डेटा की आवश्यकता होती है। प्रति पेज सेशन रिपोर्ट को सीमित करते हुए LCP, संसाधन-लोड और लॉन्ग-टास्क डेटा एकत्र करें। एक PerformanceObserver कलेक्टर डिज़ाइन करें और बताएं कि यह ऑब्ज़र्वर रजिस्ट्रेशन से पहले बनी प्रविष्टियों (entries), बफर लॉस, क्रॉस-ओरिजिन संसाधनों और SPA रूट परिवर्तनों को कैसे संभालता है।

2. सीमाएं और स्पष्टीकरण

प्रत्येक मेट्रिक का समय दायरा (time scope) परिभाषित करें: प्रारंभिक दस्तावेज़, सॉफ्ट नेविगेशन, या एक पूरा सेशन।
सैंपलिंग दर, प्रति-प्रकार प्रविष्टि सीमा, बैच आकार और विफलता-पुनर्प्रयास (failure-retry) नीति निर्धारित करें ताकि डेटा संग्रह पेज को प्रभावित न करे।
ब्राउज़र सपोर्ट अंतर को अनुपलब्ध डेटा से अलग पहचानें; अनुपलब्ध मानों के लिए एक कारण होना चाहिए और उन्हें शून्य नहीं बनाया जाना चाहिए।
संसाधन URL, यूज़र पहचानकर्ताओं और क्वेरी आयामों के लिए गोपनीयता सीमाएं परिभाषित करें; पूरे URL या संवेदनशील पैरामीटर सीधे रिपोर्ट न करें।

3. मुख्य अवधारणाएं

PerformanceObserver चयनित प्रविष्टि प्रकारों के लिए प्रविष्टियां प्राप्त करता है; buffered: true ऑब्ज़र्वर बनने से पहले रिकॉर्ड की गई प्रविष्टियों को पुनः प्राप्त कर सकता है। संसाधन, लॉन्ग-टास्क, पेंट और LCP प्रकारों की बफर सीमाएं होती हैं, और कॉलबैक बफर भर जाने के कारण छोड़ी गई प्रविष्टियों को प्रकट करने के लिए droppedEntriesCount प्राप्त कर सकता है। LCP लोडिंग के दौरान सबसे बड़ी छवि या टेक्स्ट ब्लॉक का रेंडर समय है; यूज़र इनपुट के बाद, बाद की सामग्री को प्रारंभिक LCP के रूप में नहीं माना जाना चाहिए। एक उपयुक्त Timing-Allow-Origin प्रतिक्रिया हेडर के बिना, क्रॉस-ओरिजिन संसाधनों के लिए टाइमिंग डेटा प्रतिबंधित या अनुपलब्ध हो सकता है।

4. संदर्भ कार्यान्वयन

text

startCollector():
  session = createSessionId()
  observe("largest-contentful-paint", {buffered: true})
  observe("resource", {buffered: true})
  observe("longtask", {buffered: true})

observe(type, options):
  if type not in PerformanceObserver.supportedEntryTypes:
    markUnsupported(type)
    return
  observer = new PerformanceObserver((list, _, dropped) =>
    appendSanitized(list.getEntries())
    if dropped > 0: markDropped(type, dropped)
    flushWhenBatchIsReady()
  )
  observer.observe({type, ...options})

onSoftNavigation(route):
  closePreviousView(route)
  resetViewScopedMetrics()

प्रत्येक प्रविष्टि प्रकार के लिए एक अलग ऑब्ज़र्वर रजिस्टर करें और शुरुआती रिकॉर्ड पुनः प्राप्त करने के लिए buffered का उपयोग करें। कॉलबैक केवल आवश्यक फ़ील्ड रखता है, URL पैरामीटर हटाता है, और बैच भेजता है। प्रत्येक व्यू में ऑब्ज़र्वर-रजिस्ट्रेशन समय, रूट और रिलीज़ संग्रहीत होती है; एक सॉफ्ट नेविगेशन पिछले व्यू को बंद कर देता है और व्यू-स्कोप मेट्रिक्स को रीसेट कर देता है। सेशन-स्कोप संसाधन या त्रुटि गणना एक स्पष्ट डीडुप्लिकेशन कुंजी के साथ जारी रहती है।

5. डेटा गुणवत्ता और लागत ट्रेड-ऑफ

उच्च सैंपलिंग क्वांटाइल्स को स्थिर करती है लेकिन नेटवर्क और स्टोरेज लागत को बढ़ाती है। LCP और लॉन्ग-टास्क के लिए एक उच्च सैंपल रखें, जबकि संसाधन प्रविष्टियों के लिए हेड-सैंपलिंग करें या केवल धीमे संसाधनों को बनाए रखें। एक सिंगल resource बफर डिफ़ॉल्ट रूप से 250 प्रविष्टियों तक रखता है, इसलिए कलेक्टर को पेज जीवनचक्र के दौरान इसका उपभोग करना चाहिए और रिपोर्ट आवृत्ति को अंतहीन रूप से बढ़ाने के बजाय नुकसान को रिकॉर्ड करना चाहिए। बैच विफलता के बाद क्लाइंट पुन: प्रयासों को सीमित करें और अगली विज़िट पर पुराने बैचों को त्याग दें ताकि कोई स्थानीय कतार स्टार्टअप को धीमा न करे।

6. सत्यापन और अवलोकनीयता (Observability)

buffered को सत्यापित करने के लिए ऑब्ज़र्वर रजिस्ट्रेशन से पहले प्रविष्टियां बनाएं; droppedEntriesCount अलर्ट को सत्यापित करने के लिए संसाधन-गहन (resource-heavy) पेज का उपयोग करें।
Timing-Allow-Origin के साथ और उसके बिना क्रॉस-ओरिजिन संसाधनों का परीक्षण करें और पुष्टि करें कि अनुपलब्ध-फ़ील्ड के कारणों में अंतर बना रहे।
प्रारंभिक लोड, सॉफ्ट नेविगेशन, बैकग्राउंड रिकवरी और पेज छिपाने को अलग-अलग रीप्ले करें; सत्यापित करें कि LCP और संसाधन प्रविष्टियों को एकाधिक व्यूज़ में एट्रिब्यूट नहीं किया गया है।
कलेक्टर CPU, मेमोरी, रिपोर्ट किए गए बाइट्स, बैच-विफलता दर, प्रविष्टि-हानि दर और सपोर्ट दर की निगरानी करें।

7. सामान्य गलतियां

केवल load इवेंट के बाद ऑब्ज़र्वर बनाना, जिससे शुरुआती LCP या संसाधन प्रविष्टियां स्थायी रूप से छूट जाती हैं।
एक अपूर्ण सैंपल को पूर्ण वितरण के रूप में मानते हुए चुपचाप droppedEntriesCount को अनदेखा करना।
प्रतिबंधित क्रॉस-ओरिजिन टाइमिंग को वास्तविक शून्य विलंबता (latency) मानकर परफॉर्मेंस क्वांटाइल्स को दूषित करना।
पुराने ऑब्ज़र्वर को बंद किए बिना प्रत्येक SPA रूट पर एक नया ऑब्ज़र्वर बनाना, जिससे डुप्लिकेट रिपोर्ट और मेमोरी लीक होते हैं।

8. साक्षात्कार स्कोरिंग बिंदु

ऑब्ज़र्वर जीवनचक्र का सही उपयोग करता है

शुरुआती नुकसान और डुप्लिकेट एट्रिब्यूशन से बचने के लिए उत्तर में buffered, supportedEntryTypes, ऑब्ज़र्वर शटडाउन और सॉफ्ट-नेविगेशन सीमाओं को शामिल किया जाना चाहिए।

बफर और क्रॉस-ओरिजिन सीमाओं को संभालता है

उम्मीदवार को droppedEntriesCount की निगरानी करनी चाहिए, संसाधन-बफर सीमा को जानना चाहिए, और अनुपलब्ध क्रॉस-ओरिजिन फ़ील्ड को समझाने के लिए Timing-Allow-Origin का उपयोग करना चाहिए।

नियंत्रित सैंपलिंग और रिपोर्टिंग डिज़ाइन करता है

उम्मीदवार को मेट्रिक मूल्य के आधार पर सैंपलिंग, प्रविष्टि सीमा और बैचिंग आवंटित करनी चाहिए और यह बताना चाहिए कि पुनर्प्रयास पेज को धीमा क्यों नहीं करते हैं।

डेटा विश्वसनीयता की पुष्टि करता है

उम्मीदवार को कलेक्टर ओवरहेड और नुकसान को मापते हुए शुरुआती प्रविष्टियों, संसाधन-गहन पेजों, क्रॉस-ओरिजिन टाइमिंग, सॉफ्ट नेविगेशन और बैकग्राउंड रिकवरी को कवर करना चाहिए।

PerformanceObserver के साथ विश्वसनीय रियल-यूज़र मॉनिटरिंग (RUM) कैसे बनाएं?

प्रश्न