अपने मौजूदा Analytics टूल की मदद से, वेबसाइट की परफ़ॉर्मेंस से जुड़ी अहम जानकारी का आकलन करने का तरीका.
समय के साथ परफ़ॉर्मेंस का पता लगाने और उसे बेहतर बनाने के लिए, अपने पेजों की असल परफ़ॉर्मेंस को मेज़र करना और उसकी रिपोर्ट बनाना ज़रूरी है. फ़ील्ड डेटा के बिना, यह पक्का तौर पर नहीं जाना जा सकता कि आपकी साइट में किए जा रहे बदलावों से, असल में आपको मनमुताबिक नतीजे मिल रहे हैं या नहीं.
असल उपयोगकर्ता को मॉनिटर करने (RUM) से जुड़े कई लोकप्रिय आंकड़े देने वाली कंपनियां, अपने टूल में वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी वाली मेट्रिक के साथ-साथ, वेबसाइट की परफ़ॉर्मेंस से जुड़ी कई अन्य अहम जानकारी वाली मेट्रिक का इस्तेमाल पहले से ही कर रही हैं. अगर आरयूएम के आंकड़ों वाले इन टूल में से किसी एक का इस्तेमाल किया जा रहा है, तो यह आकलन किया जा सकता है कि आपकी साइट के पेज, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली सुझाई गई थ्रेशोल्ड को कितनी अच्छी तरह से पूरा करते हैं. साथ ही, आने वाले समय में इस टूल में रिग्रेशन को रोका जा सकता है.
हमारा सुझाव है कि आप ऐसे आंकड़े इकट्ठा करने वाले टूल का इस्तेमाल करें जो मुख्य वेब विटल्स मेट्रिक के साथ काम करता हो. हालांकि, अगर आपका मौजूदा आंकड़े इकट्ठा करने वाला टूल इन मेट्रिक के साथ काम नहीं करता है, तो आपको किसी दूसरे टूल पर स्विच करने की ज़रूरत नहीं है. ज़्यादातर आंकड़ों के टूल, कस्टम मेट्रिक या इवेंट को तय करने और मेज़र करने का तरीका उपलब्ध कराते हैं. इसका मतलब है कि वेबसाइट की परफ़ॉर्मेंस से जुड़ी अहम जानकारी वाली मेट्रिक को मेज़र करने के लिए, अपने मौजूदा आंकड़ों के सप्लायर का इस्तेमाल किया जा सकता है. साथ ही, उन्हें अपनी मौजूदा आंकड़ों की रिपोर्ट और डैशबोर्ड में जोड़ा जा सकता है.
इस गाइड में, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक या किसी भी कस्टम मेट्रिक को मेज़र करने के सबसे सही तरीकों के बारे में बताया गया है. इसके लिए, तीसरे पक्ष या इन-हाउस ऐनलिटिक्स टूल का इस्तेमाल किया जा रहा है. यह उन आंकड़ों से जुड़ी सेवा देने वाली कंपनियों के लिए भी एक गाइड के तौर पर काम कर सकती है जो अपनी सेवा में वेबसाइट की परफ़ॉर्मेंस की जानकारी (कोर वेब वाइटल) से जुड़ी सहायता जोड़ना चाहती हैं.
कस्टम मेट्रिक या इवेंट का इस्तेमाल करना
जैसा कि ऊपर बताया गया है, आंकड़ों से जुड़े ज़्यादातर टूल आपको कस्टम डेटा मेज़र करने की सुविधा देते हैं. अगर आपका आंकड़ों का टूल इस सुविधा के साथ काम करता है, तो इस तरीके का इस्तेमाल करके, वेबसाइट की परफ़ॉर्मेंस से जुड़ी हर मेट्रिक को मेज़र किया जा सकता है.
आम तौर पर, Analytics टूल में कस्टम मेट्रिक या इवेंट को मेज़र करने की प्रोसेस तीन चरणों में होती है:
- अपने टूल के एडमिन पेज पर कस्टम मेट्रिक तय करें या रजिस्टर करें (अगर ज़रूरी हो). (ध्यान दें: Analytics की सभी कंपनियों को पहले से कस्टम मेट्रिक तय करने की ज़रूरत नहीं होती.)
- अपने फ़्रंटएंड JavaScript कोड में मेट्रिक की वैल्यू का हिसाब लगाएं.
- मेट्रिक की वैल्यू को अपने 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 कोड की प्रतिक्रिया देर से मिल सकती है. इसके अलावा, अगर आपके Analytics कोड वाली JavaScript फ़ाइल का साइज़ बड़ा है, तो उस फ़ाइल को चलाने से मुख्य थ्रेड ब्लॉक हो सकता है. साथ ही, पेज के इंटरैक्शन टू नेक्स्ट पेंट (INP) पर भी बुरा असर पड़ सकता है.
नॉन-ब्लॉकिंग एपीआई का इस्तेमाल करना
sendBeacon() और requestIdleCallback() जैसे एपीआई, खास तौर पर गैर-ज़रूरी टास्क को चलाने के लिए डिज़ाइन किए गए हैं. ये ऐसे टास्क हैं जो उपयोगकर्ताओं के लिए ज़रूरी टास्क को ब्लॉक नहीं करते.
ये एपीआई, आरयूएम ऐनलिटिक्स लाइब्रेरी में इस्तेमाल करने के लिए बेहतरीन टूल हैं.
आम तौर पर, सभी आंकड़े बीकन को sendBeacon() एपीआई (अगर उपलब्ध हो) का इस्तेमाल करके भेजा जाना चाहिए. साथ ही, सभी पैसिव आंकड़े मेज़रमेंट कोड को, इंतज़ार के समय चलाया जाना चाहिए.
अपनी ज़रूरत के हिसाब से ज़्यादा जानकारी ट्रैक न करें
ब्राउज़र, परफ़ॉर्मेंस का काफ़ी डेटा दिखाता है. हालांकि, डेटा उपलब्ध होने का मतलब यह नहीं है कि आपको उसे रिकॉर्ड करके अपने Analytics सर्वर पर भेजना चाहिए.
उदाहरण के लिए, Resource Timing API में, आपके पेज पर लोड किए गए हर रिसॉर्स के समय की ज़्यादा जानकारी वाला डेटा मिलता है. हालांकि, संसाधन लोड की परफ़ॉर्मेंस को बेहतर बनाने के लिए, हो सकता है कि यह पूरा डेटा ज़रूरी या काम का न हो.
कम शब्दों में, सिर्फ़ इसलिए डेटा ट्रैक न करें, क्योंकि वह उपलब्ध है. डेटा को ट्रैक करने के लिए संसाधनों का इस्तेमाल करने से पहले, पक्का करें कि डेटा का इस्तेमाल किया जाएगा.