फ़ील्ड में, वेबसाइट की परफ़ॉर्मेंस की जानकारी को मेज़र करने के सबसे सही तरीके

अपने मौजूदा Analytics टूल की मदद से, वेबसाइट की परफ़ॉर्मेंस से जुड़ी अहम जानकारी का आकलन करने का तरीका.

Philip Walton

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

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

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

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

कस्टम मेट्रिक या इवेंट का इस्तेमाल करना

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

आम तौर पर, किसी एनालिटिक्स टूल में कस्टम मेट्रिक या इवेंट को मेज़र करने की प्रोसेस तीन चरणों में पूरी होती है:

1. अपने टूल के एडमिन पेज पर, ज़रूरत पड़ने पर कस्टम मेट्रिक तय करें या रजिस्टर करें. (ध्यान दें: आंकड़ों की सेवा देने वाली सभी कंपनियों को, पहले से कस्टम मेट्रिक तय करने की ज़रूरत नहीं होती.)
2. अपने फ़्रंटएंड JavaScript कोड में मेट्रिक की वैल्यू का हिसाब लगाएं.
3. मेट्रिक की वैल्यू को अपने Analytics बैकएंड पर भेजें. साथ ही, पक्का करें कि नाम या आईडी, पहले चरण में तय किए गए नाम या आईडी से मैच करता हो (अगर ज़रूरी हो, तो फिर से).

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

नीचे दिए गए कोड सैंपल से पता चलता है कि कोड में इन मेट्रिक को ट्रैक करना और उन्हें किसी Analytics सेवा को भेजना कितना आसान है.

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

औसत से बचना

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

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

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

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

पक्का करें कि आपके पास डिस्ट्रिब्यूशन की शिकायत करने का विकल्प हो

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

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

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

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

वेब विटल्स रिपोर्ट, इस तकनीक का एक उदाहरण है. इसमें Google Analytics का इस्तेमाल किया जाता है. रिपोर्ट का कोड ओपन सोर्स है, इसलिए डेवलपर इस सेक्शन में बताई गई तकनीकों के उदाहरण के तौर पर इसका इस्तेमाल कर सकते हैं.

सही समय पर डेटा भेजना

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

हालांकि, इससे समस्या हो सकती है, क्योंकि beforeunload और unload दोनों इवेंट भरोसेमंद नहीं होते (खास तौर पर मोबाइल पर). साथ ही, इनका इस्तेमाल करने का सुझाव नहीं दिया जाता, क्योंकि इनसे किसी पेज को बैक-फ़ॉरवर्ड कैश मेमोरी की ज़रूरी शर्तें पूरी करने से रोका जा सकता है.

किसी पेज के पूरे लाइफ़स्पैन को ट्रैक करने वाली मेट्रिक के लिए, visibilitychange इवेंट के दौरान मेट्रिक की मौजूदा वैल्यू भेजना सबसे सही होता है. ऐसा तब किया जाना चाहिए, जब पेज की दिखने की स्थिति hidden में बदल जाए. इसकी वजह यह है कि पेज के दिखने की स्थिति hidden में बदलने के बाद, इस बात की कोई गारंटी नहीं है कि उस पेज पर मौजूद कोई स्क्रिप्ट फिर से चल पाएगी. यह बात खास तौर पर मोबाइल ऑपरेटिंग सिस्टम पर लागू होती है, जहां पेज कॉलबैक ट्रिगर किए बिना ही ब्राउज़र ऐप्लिकेशन बंद हो सकता है.

ध्यान दें कि मोबाइल ऑपरेटिंग सिस्टम, टैब स्विच करने, ऐप्लिकेशन स्विच करने या ब्राउज़र ऐप्लिकेशन को बंद करने पर, आम तौर पर visibilitychange इवेंट ट्रिगर करते हैं. टैब बंद करने या किसी नए पेज पर जाने पर भी, ये visibilitychange इवेंट ट्रिगर करते हैं. इससे visibilitychange इवेंट, unload या beforeunload इवेंट के मुकाबले ज़्यादा भरोसेमंद बन जाता है.

समय के साथ परफ़ॉर्मेंस पर नज़र रखना

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

बदलावों का वर्शन बनाना

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

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

एक्सपेरिमेंट चलाना

एक ही समय पर कई वर्शन (या प्रयोग) को ट्रैक करके, वर्शन को एक कदम आगे बढ़ाया जा सकता है.

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

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

पक्का करें कि मेज़रमेंट से परफ़ॉर्मेंस पर कोई असर न पड़े

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

अपनी प्रोडक्शन साइट पर RUM Analytics कोड को डिप्लॉय करते समय, इन सिद्धांतों का हमेशा पालन करें:

आंकड़े देखने की सुविधा को कुछ समय के लिए रोकना

Analytics कोड को हमेशा एसिंक्रोनस और बिना ब्लॉक किए लोड किया जाना चाहिए. आम तौर पर, इसे आखिर में लोड किया जाना चाहिए. अगर आपने अपना Analytics कोड ब्लॉक करने वाले तरीके से लोड किया है, तो इससे एलसीपी पर बुरा असर पड़ सकता है.

Core Web Vitals मेट्रिक को मेज़र करने के लिए इस्तेमाल किए जाने वाले सभी एपीआई, खास तौर पर buffered फ़्लैग की मदद से, एसिंक्रोनस और देर से लोड होने वाली स्क्रिप्ट के साथ काम करने के लिए डिज़ाइन किए गए थे. इसलिए, अपनी स्क्रिप्ट को जल्दी लोड करने की ज़रूरत नहीं है.

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

लंबे टास्क न बनाएं

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

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

sendBeacon() और requestIdleCallback() जैसे एपीआई, खास तौर पर ऐसे कामों को चलाने के लिए डिज़ाइन किए गए हैं जो ज़रूरी नहीं हैं. इनसे उपयोगकर्ता के ज़रूरी कामों में रुकावट नहीं आती.

ये एपीआई, आरयूएम ऐनलिटिक्स लाइब्रेरी में इस्तेमाल करने के लिए बेहतरीन टूल हैं.

आम तौर पर, सभी Analytics बीकन को sendBeacon() एपीआई (अगर उपलब्ध हो) का इस्तेमाल करके भेजा जाना चाहिए. साथ ही, सभी पैसिव Analytics मेज़रमेंट कोड को, ऐप्लिकेशन के इस्तेमाल में न होने के दौरान चलाया जाना चाहिए.

ज़रूरत से ज़्यादा डेटा ट्रैक न करें

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

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

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