जानें कि RUM डेटा, CrUX से अलग Core Web Vitals की संख्या क्यों दिखा सकता है.
Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट (CrUX) में, उपयोगकर्ता अनुभव से जुड़ी मेट्रिक मिलती हैं. इस रिपोर्ट से पता चलता है कि असल दुनिया में Chrome इस्तेमाल करने वाले लोगों को वेब पर लोकप्रिय जगहों का अनुभव कैसा रहा. यह डेटा, Chrome उन उपयोगकर्ताओं से अपने-आप इकट्ठा करता है जिन्होंने इस सुविधा के लिए ऑप्ट-इन किया है. साथ ही, इसे CrUX की ज़रूरी शर्तों के आधार पर उपलब्ध कराया जाता है.
इसलिए, CrUX डेटा लाखों वेबसाइटों के लिए उपलब्ध है. कई साइट मालिकों के पास पहले फ़ील्ड डेटा का ऐक्सेस नहीं था. CrUX की मदद से, कई साइटों को पहली बार इसकी वैल्यू देखने की सुविधा मिली है. सार्वजनिक डेटासेट के तौर पर, CrUX का इस्तेमाल, प्रतिस्पर्धी विश्लेषण और उपयोगकर्ता अनुभव की मेट्रिक की तुलना करने के लिए भी किया जा सकता है.
असल उपयोगकर्ता निगरानी (आरयूएम), CrUX जैसा ही है. हालांकि, Chrome में उपयोगकर्ता अनुभव की मेट्रिक अपने-आप इकट्ठा नहीं होतीं. इसके लिए, वेबसाइटों पर कोड शामिल किया जाता है. साथ ही, आगे के विश्लेषण के लिए, इसे आरयूएम प्रोवाइडर या आंकड़ों के समाधान को फ़ीड किया जाता है.
दोनों सलूशन, उपयोगकर्ता अनुभव की मेट्रिक को मेज़र करते हैं. इसलिए, यह मानना स्वाभाविक है कि दोनों मेट्रिक एक जैसी होनी चाहिए. जब हमें अंतर दिखता है, तो यह भ्रमित करने वाला हो सकता है. इस गाइड में बताया गया है कि ऐसा क्यों हो सकता है. साथ ही, इसमें यह भी बताया गया है कि संख्याएं अलाइन न होने पर क्या करना चाहिए.
RUM समाधान के साथ CrUX को जोड़ने के फ़ायदे
CrUX एक बेहतरीन टूल है, जिसकी मदद से अलग-अलग साइटों पर एक जैसा व्यू मिलता है. वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाले प्रोग्राम का आधिकारिक डेटासेट, साइटें यह देखना चाहती हैं कि यह कॉन्टेंट किस तरह दिख रहा है. CrUX का मकसद, लाखों वेबसाइटों की परफ़ॉर्मेंस की तुलना करने के लिए, आंकड़ों के हिसाब से काम की खास जानकारी देना है.
हालांकि, डेटा में मौजूद संख्याएं क्यों दिख रही हैं, इसकी गहराई से जांच करने के लिए, CrUX के साथ काम करने वाले पूरे आरयूएम (रीयल यूज़र मेज़रमेंट) सलूशन का इस्तेमाल करें. इससे आपको ज़्यादा जानकारी मिल सकती है. यह जानकारी, सार्वजनिक तौर पर क्वेरी किए जा सकने वाले डेटासेट में उपलब्ध नहीं होती. इसकी मदद से, कई तरीकों से अपनी मेट्रिक को समझा जा सकता है और उन्हें बेहतर बनाया जा सकता है.
समस्याओं की जांच करने के लिए ज़्यादा जानकारी
CrUX का इस्तेमाल अक्सर यह बताने के लिए किया जाता है कि आपकी साइट पर कोई समस्या है या नहीं. हालांकि, इससे यह पता नहीं चलता कि आपकी साइट पर समस्या कहां है और क्यों है. आरयूएम के समाधान, इस अंतर को कम करने में मदद कर सकते हैं. भले ही, ये समाधान वेब-विटल्स लाइब्रेरी जैसी सुविधाओं के ज़रिए बनाए गए हों या कई व्यावसायिक प्रॉडक्ट के ज़रिए.
आरयूएम सलूशन का इस्तेमाल करने पर, आपको अपने सभी पेजों और सभी ब्राउज़र के लिए ज़्यादा बेहतर डेटा का ऐक्सेस मिलता है. इसकी मदद से, इस डेटा को अलग-अलग सेगमेंट में बांटा जा सकता है और उसका विश्लेषण किया जा सकता है. हालांकि, CrUX में ऐसा नहीं किया जा सकता. इससे, साइट के उन हिस्सों की जांच की जा सकती है जहां समस्याएं आ रही हैं. क्या उन पर उपयोगकर्ताओं के किसी खास सेगमेंट का असर पड़ा है? या ऐसे उपयोगकर्ता जो कुछ खास कार्रवाइयां करते हैं? समस्या कब शुरू हुई? इन सवालों के जवाब देने के लिए, RUM टूल से मिलने वाले अतिरिक्त डेटा का इस्तेमाल किया जा सकता है.
कारोबार की अन्य मेट्रिक से जोड़ें
RUM की मदद से, अपनी वेब परफ़ॉर्मेंस मेट्रिक की तुलना सीधे कारोबार की किसी भी मेट्रिक से की जा सकती है. इससे यह पता चलता है कि आपकी परफ़ॉर्मेंस कैसी रही और कौनसी नहीं. इस तरह के जुड़ाव को करने वाले कारोबारों के साथ हमारी कई केस स्टडी हैं, जैसे कि Farfetch या The Economic Times.
परफ़ॉर्मेंस का अन्य डेटा इकट्ठा करना
आरयूएम (रीयल यूज़र मेज़रमेंट) के समाधान की मदद से, सीधे आपके कारोबार से जुड़ी अन्य कस्टम मेट्रिक इकट्ठा की जा सकती हैं. ट्विटर की "पहला ट्वीट करने में लगने वाला समय" मेट्रिक, इस तरह की मेट्रिक का एक लोकप्रिय उदाहरण है. इसके बाद, साइट के हिसाब से इन मेज़रमेंट को वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक और कारोबार की मेट्रिक के साथ जोड़ा जा सकता है.
फ़ील्ड डेटा के दो सेट के बीच अंतर
जिसके पास स्मार्टवॉच होती है उसे पता होता है कि समय क्या है. जिसके पास दो स्मार्टवॉच होती हैं उसे कभी भी पक्के तौर पर नहीं पता होता.
सेगल का नियम
जब आपके पास डेटा के दो सोर्स होते हैं, तो अक्सर यह समझना मुश्किल हो जाता है कि दोनों में अंतर क्यों है. लैब और फ़ील्ड मेट्रिक के बीच के अंतर को समझना ज़रूरी है. इसी तरह, फ़ील्ड डेटा के दो सोर्स के बीच भी अंतर हो सकता है. आम तौर पर, दोनों डेटा एक जैसे होते हैं. हालांकि, इनमें अंतर होने की कई वजहें हो सकती हैं.
लैब डेटा बनाम फ़ील्ड डेटा
सबसे पहले यह देखें कि आपको लैब (सिंथेटिक) मेट्रिक या फ़ील्ड (आरयूएम) मेट्रिक देखनी है या नहीं. हालांकि, यह मानना मुश्किल है कि आरयूएम वाले प्रॉडक्ट सिर्फ़ फ़ील्ड डेटा में दिखते हैं, लेकिन कुछ प्रॉडक्ट में लैब कॉम्पोनेंट भी शामिल किया जाता है.
लैब डेटा काफ़ी काम का होता है, क्योंकि इसे तय की गई शर्तों के तहत मेज़र किया जाता है. इसका इस्तेमाल, प्रोडक्शन एनवायरमेंट में अचानक हुए बदलावों या रेग्रेशन को मॉनिटर करने के लिए किया जा सकता है. ऐसा करने पर, फ़ील्ड की बदलती हुई संख्या से जुड़ी गड़बड़ियां नहीं दिखती हैं. हालांकि, हो सकता है कि लैब डेटा, उपयोगकर्ता के असल अनुभव को न दिखाए. इसलिए, फ़ील्ड मेट्रिक से काफ़ी अलग नतीजे दिख सकते हैं.
जनसंख्या
CrUX और RUM समाधानों में इस्तेमाल किए गए डेटासेट अलग-अलग हो सकते हैं. इसकी वजह यह है कि किन ब्राउज़र, उपयोगकर्ताओं, साइटों, और डिवाइसों की तुलना की जा रही है, इसके आधार पर पेज विज़िट को मेज़र किया जा रहा है.
शामिल किए गए ब्राउज़र
Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट, सिर्फ़ Chrome के लिए उपलब्ध है. Chromium पर आधारित कई ब्राउज़र (जैसे, Edge, Opera, और Brave) हैं, जो Chrome की तरह ही मेट्रिक का इस्तेमाल करते हैं. ऐसा इसलिए है, क्योंकि इनमें भी Chrome के कोडबेस का इस्तेमाल किया जाता है. हालांकि, सिर्फ़ Chrome उपयोगकर्ता ही CrUX में डेटा फ़ीड करते हैं. इस पाबंदी का मतलब यह भी है कि iOS के Chrome उपयोगकर्ताओं को शामिल नहीं किया जाएगा, क्योंकि यह मौजूदा Webkit ब्राउज़र इंजन का इस्तेमाल करता है. Android वेबव्यू को भी "Chrome" नहीं माना जाता. इसलिए, इन उपयोगकर्ताओं का डेटा शामिल नहीं किया जाता. हालांकि, Chrome कस्टम टैब को शामिल किया जाता है.
Chrome दुनिया का सबसे लोकप्रिय ब्राउज़र है. इसलिए, ज़्यादातर मामलों में यह आपकी साइट की परफ़ॉर्मेंस के बारे में ज़्यादा जानकारी देता है. हालांकि, सिर्फ़ इस ब्राउज़र को मेज़र करने से, आपके सभी उपयोगकर्ताओं के बारे में पता नहीं चलता. इससे, RUM और CrUX के बीच के एक मुख्य अंतर के बारे में पता चल सकता है. यह बात खास तौर पर, परफ़ॉर्मेंस से जुड़ी उन तकनीकों के लिए ज़रूरी है जो सिर्फ़ Chrome में उपलब्ध एपीआई या इमेज फ़ॉर्मैट पर निर्भर करती हैं.
iOS डेटा की कमी की वजह से भी पक्षपात हो सकता है. उदाहरण के लिए, आम तौर पर iOS उपयोगकर्ताओं के पास बेहतर परफ़ॉर्म करने वाले डिवाइस होते हैं या वे बेहतर नेटवर्क इन्फ़्रास्ट्रक्चर वाले देशों से विज़िट करते हैं. इसलिए, इन उपयोगकर्ताओं को शामिल करने से परफ़ॉर्मेंस की कुल मेट्रिक बेहतर हो सकती हैं. दूसरी ओर, CrUX की तरह ही उन्हें शामिल न करने से, साइट पर आने वाले लोगों के डेटा में गड़बड़ी हो सकती है (उदाहरण के तौर पर केस स्टडी). आम तौर पर, Android के उपयोगकर्ताओं के पास कई तरह के डिवाइस, डिवाइस की सुविधाएं, और बाज़ार होते हैं.
आरयूएम सलूशन, Chrome के अलावा अन्य ब्राउज़र के लिए डेटा हासिल कर सकते हैं. खास तौर पर, Chromium पर काम करने वाले उन ब्राउज़र से डेटा मिल सकता है जिनमें अक्सर एक जैसी मेट्रिक (जैसे कि वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी) पहले से मौजूद होती है. Chromium के अलावा दूसरे ब्राउज़र को भी आरयूएम सलूशन की मदद से मेज़र किया जाता है. हालांकि, इनमें मेट्रिक का सेट सीमित हो सकता है. उदाहरण के लिए, लेआउट शिफ़्ट होने में लगने वाला समय (सीएलएस) और पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी) सिर्फ़ Chromium पर आधारित ब्राउज़र में उपलब्ध हैं. फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) जैसी कुछ दूसरी मेट्रिक को काफ़ी अलग तरीके से मापा जा सकता है (बाद में देखें).
ऑप्ट-इन करने वाले उपयोगकर्ता
CrUX सिर्फ़ Chrome के उपयोगकर्ताओं के लिए उपलब्ध है. साथ ही, इसमें सिर्फ़ Chrome के उपयोगकर्ताओं के एक सबसेट का डेटा मेज़र किया जाता है. यह डेटा, ब्राउज़र इंस्टॉल करते समय CrUX डेटा शेयर करने के लिए ऑप्ट इन करने वाले उपयोगकर्ताओं का होता है.
आरयूएम की सेवा देने वाली कंपनियां भी सिर्फ़ उपयोगकर्ताओं के सबसेट को देखते हैं. आम तौर पर, ऐसा कुकी बैनर प्रॉम्प्ट या ट्रैकिंग ब्लॉकर की वजह से होता है. कुकी बैनर प्रॉम्प्ट में, उपयोगकर्ताओं से आरयूएम डेटा इकट्ठा करने के लिए ऑप्ट-इन करने के लिए कहा जाता है. अगर पुष्टि दूसरे या उसके बाद के पेज तक नहीं की जाती है, तो शुरुआती कुछ पेजों के लोड होने पर इसका बुरा असर पड़ सकता है. ऐसा तब होता है, जब साइट की कुछ ऐसेट पहले से ही पिछले पेजों से कैश मेमोरी में सेव हो जाती हैं. अगर ऐसा बार-बार होता है, तो RUM में मेट्रिक असल मेट्रिक से ज़्यादा अच्छी दिख सकती हैं. ऐसा तब होता है, जब शुरुआती पेज लोड होने में लगने वाले ज़्यादा समय वाले मामलों को बाहर रखा जाता है.
शामिल की गई साइटें
CrUX का मकसद सिर्फ़ सार्वजनिक वेबसाइटों की रिपोर्टिंग करना है. इसलिए, इसमें ज़रूरी शर्तें भी शामिल हैं. इन शर्तों की वजह से, हो सकता है कि CrUX में डेटा लॉग न हो. इनमें से सबसे अहम शर्त यह है कि वेबसाइट सार्वजनिक तौर पर खोजी जा सकती हो और वह इतनी लोकप्रिय हो कि उससे कम से कम सैंपल साइज़ का डेटा मिल सके, ताकि काम के नतीजे निकाले जा सकें. ज़्यादातर मामलों में, इस वजह से CrUX में कोई डेटा उपलब्ध नहीं होगा. यह अंतर, डेटा उपलब्ध होने के बावजूद अलग होने की तुलना में कम भ्रमित करने वाला है. हालांकि, इससे यह पता चलता है कि ऐसा क्यों होता है.
हालांकि, अगर किसी साइट के कुछ पेजों को इंडेक्स किए जा सकने वाले पेजों के तौर पर मार्क किया गया है, लेकिन अन्य पेजों को नहीं, तो हो सकता है कि आपको CrUX में सिर्फ़ यूआरएल का सबसेट दिखे. अगर ऑरिजिन को सार्वजनिक तौर पर खोजा जा सकता है, तो उस ऑरिजिन में मौजूद सभी पेज व्यू को ऑरिजिन-लेवल के डेटा में शामिल किया जाएगा. हालांकि, हो सकता है कि यूआरएल-लेवल का डेटा उपलब्ध न हो.
डिवाइस
CrUX, डेटा को मोबाइल, डेस्कटॉप, और टैबलेट के हिसाब से सेगमेंट करता है. हालांकि, कई टूल पहले दो पर फ़ोकस करते हैं और हो सकता है कि वे टैबलेट का डेटा न दिखाएं या उसे मोबाइल या डेस्कटॉप में शामिल करें. मोबाइल और डेस्कटॉप पर परफ़ॉर्मेंस की विशेषताएं काफ़ी अलग-अलग हो सकती हैं. इनमें, डिलीवर किए गए कॉन्टेंट और उसे देखने वाले डिवाइसों की क्षमताएं, दोनों शामिल हैं.
आरयूएम डेटा की मदद से, ट्रैफ़िक को इसी तरह सेगमेंट में बांटा जा सकता है. हालांकि, यह डेटा डिफ़ॉल्ट रूप से इकट्ठा किया गया डेटा दिखाता है. RUM, सिर्फ़ डिवाइस टाइप (उदाहरण के लिए, मोबाइल) या ब्राउज़र (उदाहरण के लिए, Chrome) के हिसाब से सेगमेंट करने की अनुमति दे सकता है. हालांकि, सिर्फ़ मोबाइल Chrome ट्रैफ़िक देखने के लिए, दोनों के हिसाब से सेगमेंट नहीं किया जा सकता. CrUX डेटा की तुलना करते समय, पक्का करें कि आपने डिवाइस टाइप और Chrome ब्राउज़र के हिसाब से फ़िल्टर करके, एक जैसी तुलना की हो.
सैंपलिंग
आम तौर पर, आरयूएम (रियल यूज़र मेज़रमेंट) के समाधानों की मदद से, डेटा इकट्ठा करने के लिए ऑप्ट-इन करने वाले वेबसाइट पर आने वाले लोगों के सैंपलिंग रेट में बदलाव किया जा सकता है. इसका इस्तेमाल, विश्लेषण के लिए ज़रूरी डेटा के वॉल्यूम को कम करने और व्यावसायिक RUM सेवाओं की लागत को कम करने के लिए किया जा सकता है. अगर सैंपल साइज़ बहुत छोटा है और वह बड़ी डेटा सेट का प्रतिनिधि नहीं है, तो नतीजों वाली मीट्रिक भी इसी तरह गलत होंगी. अपनी साइट के लिए, सैंपलिंग का सही साइज़ तय करने के लिए, आरयूएम प्रोवाइडर से बात करें.
डेटा इकट्ठा करना
फ़ील्ड डेटा में, लैब डेटा की तुलना में एक ही मेट्रिक के कई डेटा पॉइंट शामिल होंगे. लैब डेटा से सिर्फ़ एक वैल्यू मिलेगी. अगर इस डेटा को रिपोर्टिंग के लिए अलग-अलग तरीके से एग्रीगेट किया जाता है, तो CrUX और RUM के बीच अंतर की दूसरी वजह हो सकती है.
समयावधि
CrUX डेटा, ट्रैफ़िक की 28 दिनों की स्लाइडिंग विंडो पर आधारित होता है. इस समयसीमा को बदला नहीं जा सकता. हालांकि, CrUX BigQuery डेटा हर महीने के लिए सेव किया जाता है, ताकि आप पिछले महीनों का डेटा देख सकें. साथ ही, CrUX History API भी हर हफ़्ते के हिसाब से पुराना डेटा दिखाता है. ये दोनों चार्ट, अब भी 28 दिनों की स्लाइडिंग विंडो के आधार पर डेटा देते हैं.
आम तौर पर, आरयूएम डेटा की मदद से जानकारी के बारे में ज़्यादा जानकारी मिलती है, ताकि बदलावों के असर को जल्द से जल्द देखा जा सके. हालांकि, छोटी अवधियों को चुनने पर, वेबसाइट ट्रैफ़िक और वेबसाइट पर आने वाले लोगों में होने वाले उतार-चढ़ाव से, आरयूएम डेटा पर गलत असर पड़ सकता है. RUM डेटा की तुलना CrUX डेटा से करते समय, हमेशा पक्का करें कि आप 28 दिनों की परफ़ॉर्मेंस देख रहे हों. डेटा एक जैसा होने की पुष्टि करने के बाद, RUM डेटा में ड्रिल-डाउन करने के लिए, अन्य टाइम फ़्रेम देखे जा सकते हैं.
आंकड़ों को इकट्ठा करना
CrUX मेट्रिक को 75वें पर्सेंटाइल पर मेज़र किया जाता है. इसका मतलब है कि 75% पेज व्यू की वैल्यू को देखा जाता है. फ़ील्ड डेटा में बहुत ज़्यादा अंतर होगा. इसलिए, सबसे खराब 25% अनुभवों को हटाकर, ऐसी वैल्यू दी जाएगी जिसे ज़्यादातर वेबसाइट पर आने वाले लोग हासिल कर सकते हैं.
RUM प्रॉडक्ट में, मेट्रिक को इकट्ठा करने के लिए अक्सर ज़्यादा विकल्प दिए जाते हैं. इनमें 75वां पर्सेंटाइल, मीडियन, और अन्य पर्सेंटाइल शामिल होते हैं. अगर RUM वैल्यू की तुलना CrUX डेटा से की जा रही है, तो यह पक्का करना ज़रूरी है कि आपने 75वें पर्सेंटाइल के डेटा की तुलना की हो, ताकि एक जैसी वैल्यू की तुलना की जा सके.
CrUX के हिस्टोग्राम डेटा में, सिर्फ़ 75वां पर्सेंटाइल ही नहीं, बल्कि उपलब्ध सभी डेटा शामिल होता है. साथ ही, यह हर रेटिंग में पेज व्यू की संख्या दिखाता है. हालांकि, कुल स्कोर 75वें पर्सेंटाइल पर आधारित होगा. CrUX का यह डेटा, PageSpeed Insights जैसे टूल में दिखता है:
मेट्रिक में अंतर
वेब की परफ़ॉर्मेंस को मापने के लिए कई मेट्रिक का इस्तेमाल किया जाता है. इसलिए, डेटा के दो अलग-अलग सेट की तुलना करते समय, यह समझना ज़रूरी है कि किन मेट्रिक को मेज़र किया जा रहा है और उन मेट्रिक का इस्तेमाल कैसे किया जा रहा है.
मेट्रिक मेज़र की गई
CrUX डेटा, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी से जुड़े इनिशिएटिव का आधिकारिक डेटासेट है. इसमें मुख्य रूप से इन मेट्रिक (एलसीपी, सीएलएस, और आईएनपी) का आकलन किया जाता है. साथ ही, इन मेट्रिक के साथ कुछ और मेट्रिक का भी इस्तेमाल किया जाता है.
आम तौर पर, आरयूएम टूल में ये Core Web Vitals शामिल होते हैं. हालांकि, इनमें अक्सर कई अन्य मेट्रिक भी शामिल होती हैं. आरयूएम की सेवा देने वाली कुछ कंपनियां, इन सभी मेट्रिक के अपने कॉम्बिनेशन का इस्तेमाल करके भी उपयोगकर्ता अनुभव का आकलन करती हैं. ऐसा शायद "खुशहाली इंडेक्स" या इस तरह की जानकारी देने के लिए किया जाता है. RUM डेटा की तुलना CrUX से करते समय, पक्का करें कि आप एक जैसे डेटा की तुलना कर रहे हों.
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट के पास या फ़ेल होने का आकलन करने वाले टूल को, किसी पेज के पास होने की जानकारी देनी चाहिए. ऐसा तब ज़रूरी है, जब वह पेज, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट के 75वें पर्सेंटाइल के लिए सुझाए गए टारगेट को पूरा करता हो. अगर बिना इंटरैक्शन वाले पेजों के लिए आईएनपी मौजूद नहीं है, तो सिर्फ़ एलसीपी और सीएलएस को पास करना ज़रूरी है.
अलग-अलग ब्राउज़र की मेट्रिक में अंतर
CrUX सिर्फ़ Chrome ब्राउज़र में मेज़र करता है. साथ ही, वेब विटल्स के बदलावों के लॉग देखकर यह पता लगाया जा सकता है कि Chrome के हर वर्शन के साथ ये मेज़रमेंट कैसे बदलते हैं.
हालांकि, RUM समाधान, कई तरह के ब्राउज़र के आधार पर मेज़र किए जाएंगे. Chromium पर आधारित ब्राउज़र (Edge, Opera वगैरह) Chrome जैसे ही होंगे. हालांकि, ऐसा तब तक होगा, जब तक Chrome में बदलावों की सूची में बताए गए नए बदलाव लागू नहीं किए जाते.
Chromium के अलावा किसी दूसरे ब्राउज़र का इस्तेमाल करने पर, यह अंतर ज़्यादा साफ़ तौर पर दिख सकता है. उदाहरण के लिए, फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी), Safari और Firefox में उपलब्ध है. हालांकि, इसे अलग तरीके से मेज़र किया जाता है. इस वजह से, रिपोर्ट किए गए समय में काफ़ी अंतर दिख सकता है. जैसा कि पहले बताया गया है, अगर आपको RUM की तुलना CrUX से करनी है, तो बेहतर होगा कि आप सिर्फ़ Chrome उपयोगकर्ताओं के हिसाब से फ़िल्टर करें, ताकि आप एक जैसी तुलना कर सकें.
मेट्रिक के लिए समय तय करना
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक, वेब ब्राउज़र एपीआई से मिलती हैं. हालांकि, इसका मतलब यह नहीं है कि इनका इस्तेमाल करके रिपोर्ट की गई वैल्यू में अंतर नहीं हो सकता. मेट्रिक मेज़रमेंट, पेज लोड होने या पूरे पेज के लाइफ़साइकल के दौरान कब किया जाता है. इससे डेटा में अंतर दिख सकता है. ऐसा हो सकता है कि आरयूएम टूल, डेटा पाने के लिए एक ही नाम और ब्राउज़र एपीआई का इस्तेमाल करने के बावजूद, मेट्रिक को हमेशा एक ही तरह से मेज़र न करें. इससे आपको भ्रम हो सकता है.
सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय (एलसीपी), पेज लोड होने में लगने वाले समय की मेट्रिक है. अगर शुरुआती रेंडर के बाद बड़े एलिमेंट लोड किए जाते हैं, तो वेब एपीआई कई एलसीपी एलिमेंट की रिपोर्ट कर सकता है. जब पेज लोड हो जाता है या उपयोगकर्ता पेज से इंटरैक्ट करता है, तब LCP का फ़ाइनल एलिमेंट दिखता है. इसलिए, अगर एलसीपी एलिमेंट को इन दोनों इवेंट से पहले रिपोर्ट किया जाता है, तो अंतर दिख सकता है.
इसके अलावा, फ़ील्ड डेटा में एलसीपी एलिमेंट अलग-अलग हो सकता है. यह इस बात पर निर्भर करता है कि पेज को कैसे लोड किया गया है. पेज के सबसे ऊपर मौजूद कॉन्टेंट को डिफ़ॉल्ट रूप से लोड करने पर, एलसीपी एलिमेंट मुख्य रूप से स्क्रीन साइज़ पर निर्भर करेगा. हालांकि, अगर पेज को दस्तावेज़ में नीचे मौजूद ऐंकर लिंक से खोला जाता है या इसी तरह किसी सिंगल पेज ऐप्लिकेशन (एसपीए) में डीप-लिंक से खोला जाता है—इस बारे में बाद में ज़्यादा जानकारी दी जाएगी—तो एलसीपी एलिमेंट अलग हो सकता है.
यह न मानें कि CrUX या RUM में दी गई एलसीपी टाइमिंग, लैब टूल के एक ही एलिमेंट पर आधारित हैं. CrUX आपको हर पेज या ऑरिजिन के लिए एलसीपी की कुल वैल्यू देगा. वहीं, RUM इस वैल्यू को अलग-अलग सेगमेंट में बांट सकता है, ताकि एलसीपी से जुड़ी समस्या वाले अलग-अलग सेशन की पहचान की जा सके.
कुल लेआउट शिफ़्ट (सीएलएस) को पेज के पूरे जीवनकाल के दौरान मेज़र किया जाता है. इसलिए, हो सकता है कि पेज लोड होने के शुरुआती समय में सीएलएस का जो डेटा दिखे वह उन पेजों के लिए सही न हो जिनमें पेज लोड होने और उपयोगकर्ता के इंटरैक्ट करने के बाद, ज़्यादा शिफ़्ट होती है. कई आरयूएम प्रॉडक्ट की तरह, सिर्फ़ पेज लोड होने के बाद सीएलएस वैल्यू लेने पर, उपयोगकर्ता के पेज से बाहर निकलने के बाद सीएलएस वैल्यू लेने से अलग नतीजा मिलेगा.
इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) रिस्पॉन्सिविटी मेट्रिक के लिए, इनपुट को मेज़र करना ज़रूरी है. साथ ही, यह सीएलएस की तरह ही पेज के पूरे लाइफ़साइकल के दौरान, सभी क्लिक, टैप, और कीबोर्ड इंटरैक्शन को मॉनिटर करती है. इसलिए, अगर उपयोगकर्ता ने पेज पर कई इंटरैक्शन करने के बाद मेज़र किया जाता है, तो आईएनपी की रिपोर्ट की गई वैल्यू बहुत अलग हो सकती है.
CrUX, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाले दस्तावेज़ के हिसाब से काम करता है और पेज के पूरे जीवनकाल तक इसका आकलन करता है. कई आरयूएम प्रोवाइडर, इन मेट्रिक को पेज लोड होने के बाद या किसी अन्य समय (उदाहरण के लिए, जब किसी मुख्य कॉल-टू-ऐक्शन पर क्लिक किया जाता है) मेज़र करने का विकल्प चुनते हैं. ऐसा कई वजहों से किया जाता है.
जब दो डेटा सोर्स के बीच कोई अंतर दिखे, तो यह समझना ज़रूरी है कि वेबसाइट की परफ़ॉर्मेंस की जानकारी कब मेज़र की जाती है. यह जानकारी, आरयूएम की सेवा देने वाली कंपनी से ली जा सकती है.
एक पेज वाले ऐप्लिकेशन
एक पेज वाले ऐप्लिकेशन (एसपीए), ब्राउज़र लेवल पर पेज नेविगेशन करने के बजाय, मौजूदा पेज पर कॉन्टेंट अपडेट करके काम करते हैं. इसका मतलब है कि उपयोगकर्ताओं को पेज नेविगेशन के तौर पर ये पेज नहीं दिखते. ब्राउज़र, इन्हें पेज नेविगेशन के तौर पर नहीं देखता. ब्राउज़र से मिलने वाले Core Web Vitals API, इन पेजों को ध्यान में नहीं रखेंगे. इसलिए, CrUX इन पेजों के नेविगेशन के साथ काम नहीं करता. इस समस्या को हल करने के लिए काम चल रहा है—ज़्यादा जानकारी के लिए सॉफ़्ट नेविगेशन को मापने के साथ प्रयोग करना पोस्ट देखें.
आरयूएम की सेवा देने वाली कुछ कंपनियां, एसपीए में "सॉफ़्ट नेविगेशन" का पता लगाने की कोशिश करती हैं. हालांकि, अगर वे "सॉफ़्ट नेविगेशन" को भी वेबसाइट कैसा परफ़ॉर्म कर रही है, इसके बारे में जानकारी देने वाली मेट्रिक में शामिल करती हैं, तो CrUX में अंतर दिखेगा. इसकी वजह यह है कि कई मेट्रिक के लिए, बुनियादी एपीआई इस सुविधा के साथ काम नहीं करते.
CrUX और वेब एपीआई के बीच अंतर
किस पेज व्यू को मेज़र किया जाता है और क्या मेज़र किया जाता है, इनके अलावा भी कुछ और स्थितियां हैं जिनके बारे में आपको पता होना चाहिए. इनकी वजह से, CrUX और RUM डेटा में अंतर हो सकता है. इनमें से कुछ समस्याएं, मेट्रिक को मेज़र करने के लिए इस्तेमाल किए जाने वाले वेब एपीआई की सीमाओं की वजह से होती हैं. वहीं, कुछ समस्याएं ऐसी होती हैं जिनमें एपीआई से मिले नतीजों को कुछ स्थितियों में अलग तरीके से इस्तेमाल करना पड़ता है. Core Web Vitals के दस्तावेज़ में, एलसीपी और सीएलएस के लिए ये अंतर बताए गए हैं. हालांकि, मुख्य अंतरों के बारे में यहां दिए गए सेक्शन में भी बताया गया है.
बैक/फ़ॉरवर्ड कैश मेमोरी
CrUX, बैक/फ़ॉरवर्ड कैश मेमोरी (या bfcache) को पेज नेविगेशन के तौर पर मानता है. भले ही, इससे पेज का सामान्य तरीके से लोड होना बंद हो जाता है. वेब एपीआई इन्हें पेज लोड नहीं मानते. इसलिए, आरयूएम सलूशन को CrUX से मेल खाने के लिए, इन पेजों की गिनती करने के लिए अतिरिक्त कदम उठाने होंगे. ये पेज काफ़ी तेज़ी से लोड होते हैं. इनकी वजह से, किसी साइट की परफ़ॉर्मेंस की रिपोर्ट बेहतर हो सकती है. इसलिए, इन्हें शामिल न करने पर, पेज की परफ़ॉर्मेंस की मेट्रिक खराब हो सकती हैं. अपने आरयूएम (रियल-टाइम यूज़र मेज़रमेंट) सलूशन को देखें और जानें कि क्या वे bfcache से वापस लाए गए पेजों को हैंडल करते हैं.
iframe
सुरक्षा और निजता की वजहों से, टॉप-लेवल पेजों के पास iframe में मौजूद कॉन्टेंट का ऐक्सेस नहीं होता. यहां तक कि, एक ही ऑरिजिन वाले iframe का भी ऐक्सेस नहीं होता. इसका मतलब है कि इनमें मौजूद कॉन्टेंट की परफ़ॉर्मेंस मेट्रिक को सिर्फ़ iframe से मेज़र किया जा सकता है, न कि फ़्रेमिंग पेज पर मौजूद वेब एपीआई से. अगर iframe कॉन्टेंट में LCP एलिमेंट या ऐसा कॉन्टेंट शामिल है जिससे उपयोगकर्ता के सीएलएस या आईएनपी पर असर पड़ता है, तो यह आरयूएम (इसमें Google वेब-विटल्स JavaScript लाइब्रेरी भी शामिल है) के समाधानों के लिए उपलब्ध नहीं होगा.
हालांकि, CrUX को पेज पर मौजूद JavaScript के बजाय, Chrome ब्राउज़र से मेज़र किया जाता है. इसलिए, इसमें ये सीमाएं नहीं होती हैं. साथ ही, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी की रिपोर्ट करते समय, यह iframe में मौजूद मेट्रिक को भी मेज़र करता है. यह उपयोगकर्ता के अनुभवों की ज़्यादा सटीक जानकारी देता है. हालांकि, यह iframe का इस्तेमाल करने वाली साइटों के लिए भी अलग-अलग वजहों से हो सकता है.
इसकी वजह से, CrUX और RUM में एलसीपी डेटा में अंतर हो सकता है. इसका एक उदाहरण <video> में जोड़ा गया है. अपने-आप चलने वाले playsinline <video> एलिमेंट का पहला पेंट किया गया फ़्रेम, एलसीपी के उम्मीदवार के तौर पर गिना जा सकता है. हालांकि, लोकप्रिय वीडियो स्ट्रीमिंग सेवाओं के एम्बेड, इन एलिमेंट को <iframe> में डाल सकते हैं. CrUX इसकी जानकारी दे सकता है, क्योंकि यह <iframe> कॉन्टेंट को ऐक्सेस कर सकता है, लेकिन RUM के समाधान नहीं कर सकते.
क्रॉस-ऑरिजिन रिसॉर्स
दूसरे डोमेन से दिखाए जाने वाले एलसीपी मीडिया, PerformanceObserver API में रेंडर होने में लगने वाला समय नहीं दिखाते. ऐसा तब तक होता है, जब तक Timing-Allow-Origin हेडर (टीएओ) नहीं दिया जाता. ऐसा, ब्राउज़र की सुरक्षा से जुड़ी पाबंदियों की वजह से होता है, ताकि टाइमिंग अटैक को कम किया जा सके. यह संसाधन के लोड होने में लगने वाले समय पर वापस आ जाता है. हालांकि, यह उस समय से काफ़ी अलग हो सकता है जब कॉन्टेंट को असल में पेंट किया गया था.
इससे ऐसा हो सकता है कि वेब एपीआई, एफ़सीपी से पहले ही एलसीपी की रिपोर्ट कर दें. ऐसा नहीं है, लेकिन ऐसा केवल इस सुरक्षा प्रतिबंध के कारण दिखाई देता है.
याद रखें कि CrUX, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली रिपोर्ट के लिए, रेंडर होने में लगने वाले समय का डेटा भी रिपोर्ट करता है. साइटों को ऐसा क्रॉस-ऑरिजिन कॉन्टेंट सीमित करने की सलाह दी जाती है जो वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक पर असर डालता है. साथ ही, अगर संभव हो, तो जहां संभव हो, साइटों के लिए टीएओ को इस तरह से चालू करें कि वे इसे ज़्यादा सटीक तरीके से मेज़र करना चाहें. अन्य क्रॉस-ऑरिजिन संसाधनों पर भी ऐसी ही पाबंदियां लागू हो सकती हैं.
बैकग्राउंड टैब
अगर किसी पेज को बैकग्राउंड टैब में नहीं खोला जाता है, तो भी उस पेज से वेब एपीआई का इस्तेमाल करके मेट्रिक निकलेगी. हालांकि, CrUX की ओर से इनकी रिपोर्ट नहीं की जाती, क्योंकि ये उपयोगकर्ता अनुभव के हिसाब से समय की जानकारी देते हैं. आरयूएम (रीयल यूज़र मेज़रमेंट) के समाधानों को भी इन पेजों को अनदेखा करना चाहिए या कम से कम यह बताना चाहिए कि इन पेज व्यू को कैसे माना जाता है.
तो हम इसके बारे में क्या कर सकते हैं?
हमने बताया है कि CrUX और RUM डेटा में अंतर क्यों हो सकता है. यह अंतर, दोनों के इस्तेमाल किए जाने वाले तरीके में अंतर की वजह से हो सकता है. इसके अलावा, यह भी हो सकता है कि उपयोगकर्ताओं और पेज व्यू को शामिल या बाहर रखा गया हो. आम तौर पर, डेटा के दोनों सेट आपकी साइट की परफ़ॉर्मेंस को बेहतर तरीके से दिखाएंगे. हालांकि, जो वजहें दी गई हैं उनमें यह बताया जाना चाहिए कि दोनों सेट में एक जैसा डेटा दिखने की संभावना क्यों नहीं है.
अगर अंतर थोड़ा है, तो दोनों डेटासेट काम के होंगे. उदाहरण के लिए, 2.0 सेकंड बनाम 2.2 सेकंड का एलसीपी रिपोर्ट करना. आम तौर पर, दोनों डेटासेट को सिंक किया जा सकता है.
जब डेटा में काफ़ी अंतर होने की वजह से, आपको डेटा की सटीक होने पर संदेह हो, तो आपको उन अंतरों को समझने की कोशिश करनी चाहिए. क्या इन अंतर को कम करने के लिए, RUM डेटा को फ़िल्टर करके CrUX के साथ ज़्यादा अलाइन किया जा सकता है? इसके लिए, सिर्फ़ Chrome के उन उपयोगकर्ताओं को देखें जो डेस्कटॉप या मोबाइल पर, 28 दिनों में 75वें पर्सेंटाइल की वैल्यू के साथ हैं.
अगर ऐसा है और आप डेटा को ज़्यादा बारीकी से मैच कर सकते हैं, तो आपको यह पूछना चाहिए कि आपको पूरे डेटा में ये अंतर क्यों दिख रहे हैं और इसका क्या मतलब है. क्या Chrome का इस्तेमाल न करने वाले उपयोगकर्ता, आपकी मेट्रिक को बेहतर या खराब कर रहे हैं? क्या इससे आपको इस बारे में ज़्यादा अहम जानकारी मिलती है कि आपके किन कामों पर परफ़ॉर्मेंस की समस्याओं को प्राथमिकता दी जा सकती है?
अगर Chrome का इस्तेमाल न करने वाले लोगों को अलग नतीजे मिल रहे हैं, तो RUM से मिली अहम जानकारी का इस्तेमाल करके, अलग तरीके से ऑप्टिमाइज़ किया जा सकता है. उदाहरण के लिए, कुछ ब्राउज़र पर कुछ एपीआई उपलब्ध नहीं हैं. हालांकि, उनके अनुभवों को बेहतर बनाने के लिए, काम न करने वाले ब्राउज़र के विकल्पों पर विचार किया जा सकता है. इसके अलावा, सीमित डिवाइसों या नेटवर्क पर उपयोगकर्ताओं को अलग, लेकिन बेहतर अनुभव दिया जा सकता है. CrUX, Chrome के डेटा तक ही सीमित है. हालांकि, आपको अपनी साइट पर आने वाले सभी लोगों के अनुभवों को ध्यान में रखना चाहिए, ताकि सुधारों को प्राथमिकता दी जा सके. आरयूएम डेटा से यह अंतर पूरा किया जा सकता है.
अंतर की वजहों को समझने के बाद, दोनों टूल आपकी वेबसाइट के उपयोगकर्ता अनुभव को समझने और उसे बेहतर बनाने में काफ़ी मददगार हो सकते हैं. भले ही, संख्याएं एक जैसी न हों. CrUX डेटा को बेहतर बनाने के लिए, अपने आरयूएम डेटा का इस्तेमाल करें. साथ ही, अपने ट्रैफ़िक को सेगमेंट करके, यह पता लगाएं कि CrUX आपको किस लेवल पर क्या बता रहा है. इससे आपको यह पता लगाने में मदद मिलेगी कि आपकी साइट या उपयोगकर्ताओं के आधार के किन खास हिस्सों पर ध्यान देने की ज़रूरत है.
अक्सर, दो डेटा सोर्स के बीच हर नंबर का पूरी तरह से मैच होने के बजाय, रुझानों को देखकर पता चलता है कि सुधारों की वजह से, उम्मीद के मुताबिक पॉज़िटिव असर पड़ रहा है. जैसा कि पहले बताया गया है, आरयूएम की मदद से अलग-अलग समयावधि देखी जा सकती है. इससे आपको यह जानने में मदद मिलती है कि 28 दिनों के CrUX स्कोर क्या होंगे. हालांकि, बहुत कम समयावधि देखने पर, गलत डेटा दिख सकता है. इसलिए, CrUX में 28 दिनों का डेटा इस्तेमाल किया जाता है.
अक्सर इन अलग-अलग मेट्रिक का कोई "सही" या "गलत" जवाब नहीं होता - ये आपके उपयोगकर्ताओं की तुलना में अलग-अलग होते हैं और यह भी कि वे आपकी साइट के बारे में क्या सोचते हैं. जब तक आपको यह समझ नहीं आ जाता कि ये अंतर क्यों होते हैं और इनसे फ़ैसले लेने में क्या मदद मिल सकती है, तब तक आपकी साइट पर आने वाले लोगों को बेहतर तरीके से सेवा नहीं दी जा सकती.
धन्यवाद
Unsplash पर स्टीवन लेहम की थंबनेल इमेज