अपने मौजूदा ऐनलिटिक्स टूल की मदद से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी को मापने का तरीका.
समय के साथ परफ़ॉर्मेंस का पता लगाने और उसे बेहतर बनाने के लिए, अपने पेजों की असल परफ़ॉर्मेंस को मापने और रिपोर्ट करने की सुविधा होना बहुत ज़रूरी है. फ़ील्ड डेटा के बिना, यह पक्का करना मुश्किल है कि आपकी साइट में जो बदलाव किए जा रहे हैं वे असल में मनमुताबिक नतीजे हासिल कर रहे हैं या नहीं.
रीयल यूज़र मॉनिटरिंग (आरयूएम) ऐनलिटिक्स से जुड़ी कई लोकप्रिय कंपनियां पहले से ही अपने टूल में वेबसाइट की परफ़ॉर्मेंस की जानकारी मेट्रिक के साथ-साथ, वेब की परफ़ॉर्मेंस की अन्य जानकारी का इस्तेमाल करती हैं. अगर फ़िलहाल इन आरयूएम ऐनलिटिक्स टूल में से किसी एक का इस्तेमाल किया जा रहा है, तो इस बात का आकलन किया जा सकता है कि आपकी साइट के पेज, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली सुझाई गई थ्रेशोल्ड के हिसाब से हैं या नहीं. इससे आने वाले समय में पेज रिग्रेशन को रोकने में भी मदद मिलेगी.
हालांकि, हम वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक के साथ काम करने वाले ऐनलिटिक्स टूल का इस्तेमाल करने का सुझाव देते हैं. हालांकि, फ़िलहाल, जो ऐनलिटिक्स टूल इस्तेमाल किया जा रहा है, अगर वह काम नहीं करता, तो आपको स्विच करने की ज़रूरत नहीं है. तकरीबन सभी Analytics टूल में कस्टम मेट्रिक या इवेंट की जानकारी देने और उनका आकलन करने की सुविधा होती है. इसका मतलब है कि अपनी मौजूदा Analytics कंपनी का इस्तेमाल, वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली मेट्रिक को मेज़र करने और उन्हें अपनी मौजूदा Analytics रिपोर्ट और डैशबोर्ड में जोड़ने के लिए किया जा सकता है.
इस गाइड में, तीसरे पक्ष या इन-हाउस ऐनलिटिक्स टूल की मदद से, वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली मेट्रिक या किसी कस्टम मेट्रिक को मेज़र करने के सबसे सही तरीकों के बारे में बताया गया है. साथ ही, यह उन ऐनलिटिक्स वेंडर के लिए गाइड के तौर पर भी काम कर सकती है जो अपनी सेवा के लिए, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली सुविधा को जोड़ना चाहते हैं.
कस्टम मेट्रिक या इवेंट का इस्तेमाल करना
जैसा कि ऊपर बताया गया है, ज़्यादातर Analytics टूल की मदद से कस्टम डेटा को मेज़र किया जा सकता है. अगर आपके Analytics टूल में यह सुविधा काम करती है, तो इस तरीके का इस्तेमाल करके, वेबसाइट की परफ़ॉर्मेंस के हर मेट्रिक को मेज़र किया जा सकता है.
किसी Analytics टूल में कस्टम मेट्रिक या इवेंट को मेज़र करना आम तौर पर तीन चरणों वाली प्रोसेस होती है:
- अपने टूल के एडमिन सेक्शन में जाकर, कस्टम मेट्रिक तय करें या रजिस्टर करें. हालांकि, ऐसा करना ज़रूरी हो. (ध्यान दें: यह ज़रूरी नहीं है कि Analytics की सभी कंपनियों के लिए, कस्टम मेट्रिक को पहले से तय करना ज़रूरी हो.)
- अपने फ़्रंटएंड JavaScript कोड में मेट्रिक की वैल्यू का हिसाब लगाएं.
- मेट्रिक की वैल्यू को Analytics बैकएंड में भेजें और पक्का करें कि नाम या आईडी, पहले चरण में तय की गई वैल्यू से मेल खाता हो (अगर ज़रूरी हो, तो फिर से).
पहले और तीसरे चरण में दिए गए निर्देशों के लिए, Analytics टूल के दस्तावेज़ देखें. दूसरे चरण में, वेब की परफ़ॉर्मेंस की अहम जानकारी वाली JavaScript लाइब्रेरी का इस्तेमाल करके, वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली हर मेट्रिक की वैल्यू का पता लगाया जा सकता है.
नीचे दिए गए कोड सैंपल से पता चलता है कि इन मेट्रिक को कोड में ट्रैक करना और उन्हें किसी ऐनलिटिक्स सेवा को भेजना कितना आसान हो सकता है.
import {onCLS, onFID, 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);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
औसत से बचें
औसत का हिसाब लगाकर, किसी परफ़ॉर्मेंस मेट्रिक के लिए कई वैल्यू को जोड़ा जा सकता है. पहली नज़र में औसत देखना आसान लगता है, क्योंकि ये बहुत बड़ी संख्या में डेटा को व्यवस्थित तरीके से दिखाते हैं, लेकिन आपको पेज की परफ़ॉर्मेंस को समझने के लिए उन पर भरोसा करने से बचना चाहिए.
औसतों से समस्याएं होती हैं, क्योंकि वे किसी एक उपयोगकर्ता के सेशन को नहीं दिखाती हैं. डिस्ट्रिब्यूशन की किसी भी रेंज में आउटलायर होने की वजह से, औसत को गलत तरीके से कम किया जा सकता है.
उदाहरण के लिए, हो सकता है कि उपयोगकर्ताओं का एक छोटा ग्रुप बहुत ही धीमे नेटवर्क या डिवाइस का इस्तेमाल कर रहा हो, जो वैल्यू की सबसे ज़्यादा रेंज की ओर हों, लेकिन उपयोगकर्ता सेशन के इतने प्रतिशत की गिनती नहीं की जाती है कि औसत पर असर डालने के लिए, कोई समस्या हो.
जब भी मुमकिन हो, औसत के बजाय पर्सेंटाइल पर भरोसा करें. किसी दी गई परफ़ॉर्मेंस मेट्रिक के लिए, पूरे डिस्ट्रिब्यूशन का पर्सेंटाइल, आपकी वेबसाइट पर उपयोगकर्ता अनुभव की पूरी जानकारी के बारे में बेहतर तरीके से बताता है. इससे असल अनुभवों के सबसेट पर फ़ोकस किया जा सकता है. इससे आपको किसी एक वैल्यू से ज़्यादा अहम जानकारी मिल सकती है.
पक्का करना कि डिस्ट्रिब्यूशन की शिकायत की जा सकती है
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली हर मेट्रिक की वैल्यू का हिसाब लगाने और कस्टम मेट्रिक या इवेंट का इस्तेमाल करके, उन्हें अपनी Analytics सेवा को भेजने के बाद, इकट्ठा की गई वैल्यू दिखाने वाली रिपोर्ट या डैशबोर्ड बनाया जाता है.
यह पक्का करने के लिए कि वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के लिए सुझाई गई सीमा आपके पास है, आपको अपनी रिपोर्ट में हर मेट्रिक की वैल्यू को 75वें पर्सेंटाइल पर दिखाना होगा.
अगर आपका Analytics टूल, बिल्ट-इन सुविधा के रूप में क्वानटाइल रिपोर्टिंग की सुविधा नहीं देता, तो भी शायद आपको मैन्युअल तरीके से यह डेटा मिल सकता है. इसके लिए, आपको एक ऐसी रिपोर्ट जनरेट करनी होगी जिसमें हर मेट्रिक की वैल्यू बढ़ते क्रम में लगी हो. इस रिपोर्ट के जनरेट होने के बाद, उस रिपोर्ट में सभी वैल्यू की पूरी और क्रम से लगाई गई सूची की पूरी सूची में मौजूद नतीजों का 75% हिस्सा, उस मेट्रिक का 75वां पर्सेंटाइल होगा. यह अपने डेटा को डिवाइस के टाइप, कनेक्शन टाइप, देश वगैरह के हिसाब से चाहे सेगमेंट में बांटने पर भी लागू होगा.
अगर विश्लेषण करने वाला आपका टूल, आपको डिफ़ॉल्ट रूप से मेट्रिक-लेवल की रिपोर्टिंग की जानकारी का स्तर डिफ़ॉल्ट रूप से नहीं देता, तो हो सकता है कि Analytics टूल के साथ कस्टम डाइमेंशन भी काम करता हो. ऐसे में, हो सकता है कि आपको भी ऐसा ही नतीजा मिले. रिपोर्ट कॉन्फ़िगरेशन में कस्टम डाइमेंशन को शामिल करने पर, ट्रैक किए जाने वाले हर मेट्रिक इंस्टेंस के लिए एक यूनीक, कस्टम डाइमेंशन वैल्यू सेट करके, अलग-अलग मेट्रिक इंस्टेंस के हिसाब से रिपोर्ट जनरेट की जा सकती है. हर इंस्टेंस की एक यूनीक डाइमेंशन वैल्यू होगी, इसलिए कोई ग्रुपिंग नहीं होगी.
वेब की परफ़ॉर्मेंस की जानकारी देने वाली रिपोर्ट, इस तकनीक का एक उदाहरण है, जो Google Analytics का इस्तेमाल करती है. रिपोर्ट का कोड ओपन सोर्स है, ताकि डेवलपर इसका रेफ़रंस इस सेक्शन में बताई गई तकनीकों के उदाहरण के तौर पर दे सकें.
अपना डेटा सही समय पर भेजें
कुछ परफ़ॉर्मेंस मेट्रिक का हिसाब, पेज के लोड होने के बाद लगाया जाता है. वहीं दूसरी ओर, सीएलएस जैसी कुछ मेट्रिक, पेज के पूरे जीवनकाल को ध्यान में रखती हैं और फ़ाइनल पेज के अनलोड होने के बाद ही कैलकुलेट की जाती हैं.
हालांकि, beforeunload और unload, दोनों इवेंट भरोसेमंद नहीं होते (खास तौर पर मोबाइल पर) भरोसेमंद नहीं होते और इन्हें इस्तेमाल करने का सुझाव नहीं दिया जाता. ऐसा इसलिए, क्योंकि इनकी वजह से हो सकता है कि पेज, बैक-फ़ॉरवर्ड कैश मेमोरी की ज़रूरी शर्तों को पूरा न कर पाए.
किसी पेज की पूरी अवधि को ट्रैक करने वाली मेट्रिक के लिए, बेहतर होगा कि आप
visibilitychange इवेंट के दौरान मेट्रिक की मौजूदा वैल्यू को तब भी भेजें, जब
जब पेज की 'किसको दिखे' स्थिति बदलकर hidden हो जाए. इसकी वजह यह है कि—पेज की दृश्यता स्थिति hidden में बदलने पर—इस बात की कोई गारंटी नहीं होती कि उस पेज पर कोई भी स्क्रिप्ट फिर से चल सकेगी. ऐसा खास तौर पर मोबाइल ऑपरेटिंग सिस्टम पर होता है, जहां ब्राउज़र ऐप्लिकेशन को पेज कॉलबैक के बिना बंद किया जा सकता है.
ध्यान दें कि मोबाइल ऑपरेटिंग सिस्टम आम तौर पर टैब स्विच करने, ऐप्लिकेशन स्विच करने या ब्राउज़र ऐप्लिकेशन को बंद करने पर visibilitychange इवेंट फ़ायर करते हैं.
वे टैब बंद करते समय या किसी नए पेज पर नेविगेट करते समय भी visibilitychange इवेंट फ़ायर करते हैं. इससे visibilitychange इवेंट, unload या beforeunload इवेंट की तुलना में कहीं ज़्यादा भरोसेमंद हो जाता है.
समय के साथ परफ़ॉर्मेंस पर नज़र रखें
वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली मेट्रिक को ट्रैक और रिपोर्ट करने के लिए, आंकड़ों को लागू करने की प्रोसेस को अपडेट करने के बाद, यह ट्रैक किया जा सकता है कि समय के साथ आपकी साइट में होने वाले बदलावों की वजह से आपकी परफ़ॉर्मेंस पर क्या असर पड़ता है.
आपके बदलावों का वर्शन
बदलावों को ट्रैक करने का एक आसान (और आखिर में गैर-भरोसेमंद) तरीका यह है कि आप प्रोडक्शन में बदलाव लागू करें. इसके बाद यह मान लें कि डिप्लॉयमेंट की तारीख के बाद मिले सभी मेट्रिक नई साइट की हैं और डिप्लॉयमेंट की तारीख से पहले के सभी मेट्रिक, पुरानी साइट की हैं. हालांकि, कई वजहों से (इसमें एचटीटीपी, सर्विस वर्कर या सीडीएन लेयर पर कैश मेमोरी में डेटा सेव करना भी शामिल है) इसे काम करने से रोक सकता है.
बेहतर तरीका यह है कि डिप्लॉय किए गए हर बदलाव के लिए एक यूनीक वर्शन बनाएं और फिर Analytics टूल में उस वर्शन को ट्रैक करें. ज़्यादातर Analytics टूल, वर्शन सेट करने में काम करते हैं. अगर आपका डाइमेंशन ऐसा नहीं है, तो कस्टम डाइमेंशन बनाकर उसे डिप्लॉय किए गए वर्शन पर सेट किया जा सकता है.
एक्सपेरिमेंट चलाएं
आप एक ही समय में कई वर्शन (या प्रयोग) ट्रैक करके वर्शन को एक कदम आगे ले जा सकते हैं.
अगर आपके Analytics टूल की मदद से एक्सपेरिमेंट ग्रुप तय किए जा सकते हैं, तो उस सुविधा का इस्तेमाल करें. इसके अलावा, कस्टम डाइमेंशन का इस्तेमाल करके यह पक्का किया जा सकता है कि आपकी हर मेट्रिक वैल्यू को आपकी रिपोर्ट में, किसी खास एक्सपेरिमेंट ग्रुप के साथ जोड़ा जा सकता है या नहीं.
आपके Analytics में एक्सपेरिमेंट होने पर, आपको अपने उपयोगकर्ताओं के किसी सबसेट के लिए एक्सपेरिमेंटल बदलाव रोल आउट करने का विकल्प मिलता है. साथ ही, उस बदलाव की परफ़ॉर्मेंस की तुलना कंट्रोल ग्रुप में मौजूद उपयोगकर्ताओं की परफ़ॉर्मेंस से की जा सकती है. जब आपको भरोसा हो जाए कि किसी बदलाव से परफ़ॉर्मेंस बेहतर होती है, तो उसे सभी उपयोगकर्ताओं के लिए रोल आउट किया जा सकता है.
पक्का करें कि मेज़रमेंट से परफ़ॉर्मेंस पर कोई असर न हो
असल उपयोगकर्ताओं की परफ़ॉर्मेंस का आकलन करते समय, इस बात का ध्यान रखना ज़रूरी है कि जो भी परफ़ॉर्मेंस मेज़रमेंट कोड चलाया जा रहा है उससे आपके पेज की परफ़ॉर्मेंस पर बुरा असर न पड़े. अगर ऐसा होता है, तो आपके कारोबार की परफ़ॉर्मेंस पर असर डालने के बाद, आप इस तरह के नतीजों पर भरोसा नहीं कर पाएंगे. ऐसा इसलिए, क्योंकि आपको पता नहीं चलेगा कि Analytics कोड की मौजूदगी से आपके कारोबार पर क्या खराब असर पड़ रहा है या नहीं.
अपनी प्रोडक्शन साइट पर RUM Analytics कोड को डिप्लॉय करते समय, हमेशा इन सिद्धांतों का पालन करें:
आंकड़ों को आगे बढ़ाएं
Analytics कोड हमेशा एसिंक्रोनस और ब्लॉक न किए गए तरीके से लोड किया जाना चाहिए. आम तौर पर, इसे आखिर में लोड किया जाना चाहिए. अगर Analytics कोड को ब्लॉक करने के तरीके से लोड किया जाता है, तो इससे एलसीपी पर बुरा असर पड़ सकता है.
वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली मेट्रिक को मेज़र करने के लिए, इस्तेमाल किए जाने वाले सभी एपीआई खास तौर पर, एसिंक्रोनस और डिफ़र्ड स्क्रिप्ट लोडिंग (buffered फ़्लैग के ज़रिए) को सपोर्ट करने के लिए डिज़ाइन किए गए हैं. इसलिए, अपनी स्क्रिप्ट को जल्दी लोड करने की ज़रूरत नहीं है.
अगर किसी ऐसी मेट्रिक को मेज़र किया जा रहा है जिसका आकलन पेज लोड होने की टाइमलाइन में नहीं किया जा सकता, तो आपको सिर्फ़ उस कोड को इनलाइन करना चाहिए जिसे आपके दस्तावेज़ के <head> में जल्दी चलाना है (इसलिए, यह रेंडरिंग ब्लॉक करने का अनुरोध नहीं है) और बाकी को टाल दें. अपने सभी आंकड़ों को शुरुआत में सिर्फ़ इसलिए लोड न करें, क्योंकि किसी एक मेट्रिक को इसकी ज़रूरत होती है.
लंबे टास्क न बनाएं
Analytics कोड अक्सर उपयोगकर्ता के इनपुट के जवाब में चलता है, लेकिन अगर आपका Analytics कोड बहुत ज़्यादा डीओएम मेज़रमेंट कर रहा है या दूसरे प्रोसेसर-इंटेसिव एपीआई का इस्तेमाल कर रहा है, तो Analytics कोड खुद ही इनपुट का रिस्पॉन्स खराब कर सकता है. इसके अलावा, अगर आपके Analytics कोड वाली JavaScript फ़ाइल बड़ी है, तो उस फ़ाइल को एक्ज़ीक्यूट करने से मुख्य थ्रेड ब्लॉक हो सकती है. इससे फ़र्स्ट इनपुट डिले (एफ़आईडी) या इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) पर बुरा असर पड़ सकता है.
नॉन-ब्लॉक करने वाले एपीआई का इस्तेमाल करना
sendBeacon() और requestIdleCallback() जैसे एपीआई को खास तौर पर, गैर-ज़रूरी टास्क को इस तरह से पूरा करने के लिए डिज़ाइन किया गया है कि वे लोगों के लिए अहम टास्क को ब्लॉक न करें.
ये एपीआई, RUM के आंकड़ों की लाइब्रेरी में इस्तेमाल करने के लिए बेहतरीन टूल हैं.
आम तौर पर, सभी ऐनलिटिक्स बीकन को sendBeacon() API (उपलब्ध होने पर) का इस्तेमाल करके भेजा जाना चाहिए. साथ ही, सभी पैसिव ऐनलिटिक्स मेज़रमेंट कोड को इस्तेमाल में न होने पर चालू होना चाहिए.
सिर्फ़ ज़रूरी जानकारी ट्रैक न करें
ब्राउज़र ढेर सारा प्रदर्शन डेटा दिखाता है, लेकिन डेटा उपलब्ध होने का मतलब यह नहीं है कि आपको उसे रिकॉर्ड करके अपने Analytics सर्वर पर भेजना चाहिए.
उदाहरण के लिए, Resource Timing API में आपके पेज पर लोड किए गए हर संसाधन के समय से जुड़ा पूरा डेटा मिलता है. हालांकि, इस बात की संभावना कम है कि संसाधन लोड की परफ़ॉर्मेंस को बेहतर बनाने में वह सारा डेटा ज़रूरी या काम का हो.
संक्षेप में, डेटा सिर्फ़ इसलिए ट्रैक न करें कि वह डेटा उपलब्ध है, बल्कि यह पक्का करें कि डेटा ट्रैक करने वाले संसाधनों का इस्तेमाल करने से पहले उसका इस्तेमाल किया जाए.