जानें कि वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली मेट्रिक पर नज़र रखने वाले टूल, अलग-अलग आंकड़े क्यों रिपोर्ट कर सकते हैं और इन अंतर को कैसे समझा जा सकता है.
Google, कई टूल उपलब्ध कराता है. इनसे साइट के मालिकों को, अपनी वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाले स्कोर पर नज़र रखने में मदद मिलती है. इन टूल की दो मुख्य कैटगरी है:
- लैब डेटा को रिपोर्ट करने वाले टूल—पहले से तय डिवाइस और नेटवर्क सेटिंग के साथ, नियंत्रित माहौल में इकट्ठा किया गया डेटा.
- फ़ील्ड डेटा को रिपोर्ट करने वाले टूल—आपकी साइट पर आने वाले असल उपयोगकर्ताओं से इकट्ठा किया गया डेटा.
समस्या यह है कि कभी-कभी लैब टूल से रिपोर्ट किया गया डेटा, फ़ील्ड टूल से रिपोर्ट किए गए डेटा से काफ़ी अलग हो सकता है! आपके लैब डेटा से पता चल सकता है कि आपकी साइट की परफ़ॉर्मेंस बेहतरीन है, लेकिन आपके फ़ील्ड डेटा से पता चलता है कि इसमें सुधार की ज़रूरत है. इसके अलावा, आपका फ़ील्ड डेटा यह बता सकता है कि आपके सभी पेज अच्छे हैं, लेकिन आपका लैब डेटा बहुत कम स्कोर रिपोर्ट कर सकता है.
web.dev की PageSpeed Insights रिपोर्ट का उदाहरण देखें कि कुछ मामलों में, वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली सभी मेट्रिक में लैब और फ़ील्ड डेटा अलग-अलग हो सकते हैं:
टूल में अंतर होने से डेवलपर को आसानी से भ्रम हो सकता है. इस पोस्ट में उन मुख्य वजहों के बारे में बताया गया है जिनकी वजह से वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी में अंतर हो सकता है. इसमें वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली सभी मेट्रिक के उदाहरण शामिल किए गए हैं. साथ ही, यह भी बताया गया है कि पेजों में अंतर दिखने पर क्या करना चाहिए.
लैब डेटा बनाम फ़ील्ड डेटा
यह समझने के लिए कि लैब और फ़ील्ड टूल अलग-अलग वैल्यू क्यों रिपोर्ट कर सकते हैं—यहां तक कि एक ही वेब पेज के लिए भी—आपको लैब और फ़ील्ड डेटा के बीच के अंतर को समझना होगा.
लैब डेटा
लैब डेटा को, कंट्रोल एनवायरमेंट में वेब पेज को लोड करके तय किया जाता है. इसमें नेटवर्क और डिवाइस की शर्तों के पहले से तय सेट के साथ, वेब पेज को लोड किया जाता है. इन स्थितियों को लैब एनवायरमेंट कहा जाता है. कभी-कभी इन्हें सिंथेटिक एनवायरमेंट भी कहा जाता है.
लैब डेटा को रिपोर्ट करने वाले Chrome टूल, आम तौर पर Lighthouse इस्तेमाल करते हैं.
लैब टेस्ट का मकसद ज़्यादा से ज़्यादा फ़ैक्टर को कंट्रोल करना होता है, ताकि नतीजे लगातार (ज़्यादा से ज़्यादा) एक जैसे और रन से रन के बाद दोबारा जनरेट किए जा सकें.
फ़ील्ड डेटा
फ़ील्ड डेटा को किसी पेज पर जाने वाले सभी उपयोगकर्ताओं की निगरानी करके और उनमें से हर एक उपयोगकर्ता के अनुभव के लिए परफ़ॉर्मेंस मेट्रिक के दिए गए सेट का आकलन करके तय किया जाता है. फ़ील्ड डेटा, रीयल-टाइम में उपयोगकर्ता की विज़िट पर आधारित होता है. इसलिए, यह आपके उपयोगकर्ताओं के डिवाइस, नेटवर्क की स्थितियों, और भौगोलिक जगहों की जानकारी दिखाता है.
फ़ील्ड डेटा को आम तौर पर रीयल उपयोगकर्ता मॉनिटरिंग (आरयूएम) डेटा के नाम से भी जाना जाता है. दोनों शब्दों को आपस में बदला जा सकता है.
फ़ील्ड का डेटा रिपोर्ट करने वाले Chrome टूल को आम तौर पर, Chrome उपयोगकर्ता अनुभव रिपोर्ट (CrUX) से डेटा मिलता है. साइट के मालिक आम तौर पर फ़ील्ड का डेटा खुद इकट्ठा करते हैं. इसकी वजह यह है कि इससे सिर्फ़ CrUX का इस्तेमाल करने के बजाय, ज़्यादा अहम जानकारी मिल सकती है.
फ़ील्ड डेटा के बारे में समझने वाली सबसे ज़रूरी बात यह है कि यह सिर्फ़ एक संख्या नहीं होती, बल्कि यह संख्याओं का डिस्ट्रिब्यूशन होता है. इसका मतलब है कि आपकी साइट पर आने वाले कुछ लोगों के लिए, यह बहुत जल्दी लोड हो सकती है, जबकि कुछ लोगों के लिए यह बहुत धीरे लोड हो सकती है. आपकी साइट के लिए फ़ील्ड डेटा, उपयोगकर्ताओं से इकट्ठा किए गए परफ़ॉर्मेंस के सभी डेटा का पूरा सेट होता है.
उदाहरण के लिए, CrUX रिपोर्ट 28 दिनों की अवधि के दौरान, Chrome के असल उपयोगकर्ताओं से मिली परफ़ॉर्मेंस मेट्रिक का डिस्ट्रिब्यूशन दिखाती हैं. करीब-करीब किसी भी CrUX रिपोर्ट को देखने पर, आपको दिखेगा कि साइट पर आने वाले कुछ लोगों को बहुत अच्छा अनुभव मिल सकता है, जबकि दूसरों को बहुत खराब अनुभव मिल सकता है.
अगर कोई टूल किसी खास मेट्रिक के लिए एक ही संख्या रिपोर्ट करता है, तो आम तौर पर यह डिस्ट्रिब्यूशन का एक खास पॉइंट होगा. वेबसाइट की परफ़ॉर्मेंस के बारे में जानकारी देने वाले फ़ील्ड स्कोर को रिपोर्ट करने वाले टूल, 75वें पर्सेंटाइल का इस्तेमालकरते हैं.
ऊपर दिए गए स्क्रीनशॉट में फ़ील्ड डेटा से एलसीपी पर नज़र डालने पर, आपको डिस्ट्रिब्यूशन दिखेगा, जहां:
- 88% विज़िट का एलसीपी 2.5 सेकंड या उससे कम था (अच्छा).
- 8% विज़िट का एलसीपी 2.5 से 4 सेकंड के बीच था. इसमें सुधार की ज़रूरत है.
- 4% विज़िट का एलसीपी 4 सेकंड से ज़्यादा (खराब) था.
75वें पर्सेंटाइल पर, एलसीपी 1.8 सेकंड था:
एक ही पेज का लैब डेटा, 3.0 सेकंड की एलसीपी वैल्यू दिखाता है. यह वैल्यू, फ़ील्ड डेटा में दिखाए गए 1.8 सेकंड से ज़्यादा है. इसके बावजूद, यह इस पेज के लिए मान्य एलसीपी वैल्यू है. यह उन कई वैल्यू में से एक है जो लोड अनुभवों का पूरा डिस्ट्रिब्यूशन तय करती हैं.
लैब और फ़ील्ड डेटा अलग-अलग क्यों हैं
जैसा कि ऊपर दिया गया सेक्शन बताता है, लैब डेटा और फ़ील्ड डेटा असल में बहुत अलग-अलग चीज़ों को मेज़र करते हैं.
फ़ील्ड डेटा में कई तरह के नेटवर्क और डिवाइस की स्थितियों के साथ-साथ, अलग-अलग तरह के उपयोगकर्ता व्यवहार शामिल होते हैं. इसमें ऐसी अन्य बातें भी शामिल हैं जिनसे उपयोगकर्ता अनुभव पर असर पड़ता है, जैसे कि बैक/फ़ॉरवर्ड कैश मेमोरी (bfcache) जैसे ब्राउज़र ऑप्टिमाइज़ेशन या एएमपी कैश जैसे प्लैटफ़ॉर्म ऑप्टिमाइज़ेशन.
वहीं दूसरी ओर, लैब डेटा जान-बूझकर शामिल किए गए वैरिएबल की संख्या को सीमित करता है. लैब टेस्ट में ये चीज़ें शामिल होती हैं:
- सिर्फ़ एक डिवाइस...
- किसी एक नेटवर्क से कनेक्ट किया गया...
- एक ही भौगोलिक जगह से चलाया जाता है.
किसी भी लैब टेस्ट के ब्यौरे, किसी पेज या साइट के फ़ील्ड डेटा के 75वें पर्सेंटाइल को सही तरीके से दिखा भी सकते हैं या नहीं भी.
प्रोडक्शन में डिप्लॉय करने से पहले, समस्याओं या टेस्टिंग सुविधाओं को डीबग करते समय लैब का कंट्रोल किया गया एनवायरमेंट काम का होता है. हालांकि, इन फ़ैक्टर को कंट्रोल करने पर, सभी तरह के नेटवर्क, डिवाइस की सुविधाओं या भौगोलिक जगहों पर आपको दिखने वाले फ़र्क़ को साफ़ तौर पर नहीं दिखाया जा सकता. आम तौर पर, असली उपयोगकर्ता के व्यवहार की परफ़ॉर्मेंस पर पड़ने वाले असर को भी कैप्चर नहीं किया जाता है. जैसे- स्क्रोल करना, टेक्स्ट चुनना या पेज पर मौजूद एलिमेंट पर टैप करना.
लैब की स्थितियों और ज़्यादातर असल दुनिया के उपयोगकर्ताओं की स्थितियों के बीच डिसकनेक्ट होने के अलावा, कई ऐसे छोटे-छोटे अंतर भी होते हैं जिन्हें समझना ज़रूरी है. इससे लैब और फ़ील्ड डेटा को बेहतर तरीके से समझने में मदद मिलती है.
अगले कुछ सेक्शन में उन सबसे आम वजहों के बारे में बताया गया है जिनकी वजह से लैब डेटा और फ़ील्ड डेटा में अंतर हो सकता है.
एलसीपी
अलग-अलग एलसीपी एलिमेंट
यह ज़रूरी नहीं है कि लैब टेस्ट में एलसीपी एलिमेंट वही हो जो उपयोगकर्ताओं को आपके पेज पर आता है.
अगर किसी पेज के लिए लाइटहाउस रिपोर्ट चलाई जाती है, तो यह हर बार एक ही एलसीपी एलिमेंट दिखाएगा. हालांकि, एक ही पेज का फ़ील्ड डेटा देखने पर, आम तौर पर आपको अलग-अलग एलसीपी एलिमेंट दिखेंगे. ये एलिमेंट, हर पेज विज़िट के हिसाब से अलग-अलग स्थितियों पर निर्भर करते हैं.
उदाहरण के लिए, यहां दी गई सभी वजहें एक ही पेज के लिए, अलग-अलग एलसीपी एलिमेंट तय करने में योगदान दे सकती हैं:
- डिवाइस की स्क्रीन का अलग-अलग साइज़ होने की वजह से, व्यूपोर्ट में अलग-अलग एलिमेंट दिखते हैं.
- अगर किसी व्यक्ति ने लॉग इन किया है या उसके हिसाब से बनाया गया कॉन्टेंट किसी तरह से दिखाया जा रहा है, तो हर उपयोगकर्ता के लिए एलसीपी एलिमेंट काफ़ी अलग हो सकता है.
- पिछले बिंदु की तरह ही, अगर पेज पर A/B टेस्ट चल रहा है, तो बहुत अलग एलिमेंट दिख सकते हैं.
- उपयोगकर्ता के सिस्टम में इंस्टॉल किए गए फ़ॉन्ट के सेट से, पेज पर मौजूद टेक्स्ट के साइज़ पर असर पड़ सकता है. इसलिए, हो सकता है कि कौनसा एलिमेंट एलसीपी एलिमेंट हो.
- लैब टेस्ट आम तौर पर, पेज के "बेस" यूआरएल पर किए जाते हैं. इसमें किसी भी क्वेरी पैरामीटर या हैश फ़्रैगमेंट को नहीं जोड़ा जाता है. असल में, लोग अक्सर ऐसे यूआरएल शेयर करते हैं जिनमें फ़्रैगमेंट आइडेंटिफ़ायर या टेक्स्ट फ़्रैगमेंट होता है. इसलिए, एलसीपी एलिमेंट "पेज के ऊपर" के बजाय, पेज के बीच में या सबसे नीचे हो सकता है.
फ़ील्ड में मौजूद एलसीपी का हिसाब, किसी पेज पर आने वाले सभी लोगों के 75वें पर्सेंटाइल के तौर पर लगाया जाता है. इसलिए, अगर उन उपयोगकर्ताओं में से एक बड़े प्रतिशत का एलसीपी एलिमेंट बहुत तेज़ी से लोड होता है, उदाहरण के लिए, सिस्टम फ़ॉन्ट से रेंडर किए गए टेक्स्ट का पैराग्राफ़, तब भी हो सकता है कि उन कुछ उपयोगकर्ताओं के एलसीपी एलिमेंट के रूप में बड़ी और धीमी रफ़्तार से लोड होने वाली इमेज का इस्तेमाल हो. हालांकि, वेबसाइट पर आने वाले लोगों की संख्या 5% से कम होने पर, हो सकता है कि इससे पेज के स्कोर पर असर न पड़े.
वैकल्पिक रूप से, इसका विपरीत भी सच हो सकता है. लैब टेस्ट से टेक्स्ट के एक ब्लॉक की पहचान एलसीपी एलिमेंट के तौर पर की जा सकती है. ऐसा इसलिए, क्योंकि यह Moto G4 फ़ोन की नकल कर रहा है, जिसमें काफ़ी छोटा व्यूपोर्ट है और शुरुआत में आपके पेज की हीरो इमेज को ऑफ़-स्क्रीन दिखाया जाता है. हालांकि, आपके फ़ील्ड डेटा में ज़्यादातर Pixel XL इस्तेमाल करने वाले लोग शामिल हो सकते हैं, जिनकी स्क्रीन काफ़ी बड़ी होती है. इसलिए, उनके लिए धीरे-धीरे लोड होने वाली हीरो इमेज उनका एलसीपी एलिमेंट है.
एलसीपी पर कैश मेमोरी की स्थिति का असर
लैब टेस्ट आम तौर पर, कोल्ड कैश मेमोरी वाले पेज को लोड करते हैं, लेकिन जब असली उपयोगकर्ता उस पेज पर जाते हैं, तो हो सकता है कि उनके कुछ संसाधन पहले से कैश मेमोरी में सेव हों.
जब कोई उपयोगकर्ता पहली बार पेज लोड करता है, तो हो सकता है कि वह धीरे लोड हो. हालांकि, अगर पेज को कैश मेमोरी में सही तरीके से कॉन्फ़िगर किया गया हो, तो अगली बार जब वह उपयोगकर्ता पेज पर वापस होगा, तो यह तुरंत लोड हो सकता है.
कुछ लैब टूल में, एक ही पेज को कई बार प्रोसेस किया जा सकता है. इससे, वेबसाइट पर आने वाले लोगों के अनुभव को बेहतर बनाने में मदद मिलती है. हालांकि, लैब टूल के लिए यह पता नहीं लगाना संभव नहीं है कि नए बनाम लौटने वाले उपयोगकर्ताओं ने असल दुनिया में कितने प्रतिशत विज़िट किए.
अच्छी तरह ऑप्टिमाइज़ की गई कैश कॉन्फ़िगरेशन वाली साइटें और वेबसाइट पर बार-बार आने वाले कई लोगों को यह पता चल सकता है कि असल दुनिया का एलसीपी, उनके लैब डेटा से कहीं ज़्यादा तेज़ है.
एएमपी या साइन किए हुए एक्सचेंज का ऑप्टिमाइज़ेशन
एएमपी या साइन किए हुए एक्सचेंज (एसएक्सजी) का इस्तेमाल करने वाली साइटों को Google Search जैसे कॉन्टेंट एग्रीगेटर, पहले से लोड कर सकते हैं. इससे उन प्लैटफ़ॉर्म से आपके पेजों पर आने वाले उपयोगकर्ताओं के लिए, लोड की परफ़ॉर्मेंस काफ़ी बेहतर हो सकती है.
क्रॉस-ऑरिजिन पहले से लोड करने के अलावा, साइटें खुद ही अपनी साइट पर बाद के पेजों के लिए कॉन्टेंट पहले से लोड कर सकती हैं. इससे उन पेजों का एलसीपी भी बेहतर हो सकता है.
लैब टूल, इन ऑप्टिमाइज़ेशन से होने वाले फ़ायदे को सिम्युलेट नहीं करते. भले ही, उन्होंने ऐसा किया हो, लेकिन उन्हें यह पता नहीं चल सकता कि दूसरे सोर्स की तुलना में Google Search जैसे प्लैटफ़ॉर्म से कितना ट्रैफ़िक आता है.
एलसीपी पर बैक-फ़ॉरवर्ड कैश मेमोरी के असर
जब पेजों को bfcache से वापस लाया जाता है, तो पेजों को तुरंत लोड किया जाता है. साथ ही, ये अनुभव आपके फ़ील्ड डेटा में शामिल होते हैं.
लैब टेस्ट को bfcache के तौर पर नहीं देखा जाता है. इसलिए, अगर आपके पेज bfcache-फ़्रेंडली हैं, तो फ़ील्ड में एलसीपी स्कोर तेज़ी से रिपोर्ट हो सकते हैं.
एलसीपी पर उपयोगकर्ता के इंटरैक्शन का असर
एलसीपी, व्यूपोर्ट में सबसे बड़े इमेज या टेक्स्ट ब्लॉक को रेंडर होने में लगने वाले समय की पहचान करता है. हालांकि, पेज लोड होने या व्यूपोर्ट में नया कॉन्टेंट जोड़े जाने पर, यह एलिमेंट बदल सकता है.
लैब में, ब्राउज़र, पेज के पूरी तरह लोड होने तक इंतज़ार करेगा. इसके बाद ही एलसीपी एलिमेंट का पता चलेगा. हालांकि, फ़ील्ड में उपयोगकर्ता के स्क्रोल करने या पेज से इंटरैक्ट करने के बाद, ब्राउज़र बड़े एलिमेंट की मॉनिटरिंग करना बंद कर देगा.
इसका मतलब यह है (और यह ज़रूरी है), क्योंकि लोगों को पेज के "न दिखने" तक इंतज़ार करना होगा. एलसीपी मेट्रिक, पेज के "दिखने" के बाद ही उसका पता लगाती है. उपयोगकर्ता के इंटरैक्ट करने के बाद, व्यूपोर्ट में जोड़े गए एलिमेंट को खरीदने का कोई फ़ायदा भी नहीं होता, क्योंकि हो सकता है कि वे एलिमेंट सिर्फ़ उपयोगकर्ता के किए गए काम की वजह से लोड हुए हों.
हालांकि, इससे यह भी पड़ता है कि किसी पेज के लिए फ़ील्ड डेटा तेज़ी से एलसीपी रिपोर्ट कर सकता है. यह इस बात पर निर्भर करता है कि पेज पर उपयोगकर्ताओं का व्यवहार कैसा है.
आईएनपी
आईएनपी के लिए, असल उपयोगकर्ता से इंटरैक्शन की ज़रूरत होती है
आईएनपी मेट्रिक से पता चलता है कि कोई पेज, उपयोगकर्ता के इंटरैक्शन के हिसाब से कितना रिस्पॉन्सिव है. जब उपयोगकर्ता ने किसी पेज से इंटरैक्ट करने का विकल्प चुना था, तब उसे आईएनपी मेट्रिक से पता चलता है.
इस वाक्य का दूसरा हिस्सा अहम है क्योंकि लैब टेस्ट से भी इस बारे में सटीक अनुमान नहीं लगाया जा सकता कि उपयोगकर्ता किसी पेज से कब इंटरैक्ट करेंगे. इसलिए, लैब टेस्ट भी नहीं कर सकते. इन टेस्ट में स्क्रिप्ट उपयोगकर्ता के व्यवहार के बारे में भी जानकारी मौजूद होती है. इस तरह, वे सटीक तरीके से एफ़आईडी को नहीं माप सकते.
TBT उपयोगकर्ता के व्यवहार पर विचार नहीं करता
टोटल ब्लॉकिंग टाइम (TBT) लैब मेट्रिक का मकसद, आईएनपी से जुड़ी समस्याओं का पता लगाना है. इससे यह पता चलता है कि पेज लोड होने के दौरान, मुख्य थ्रेड कितनी बार ब्लॉक हुआ है.
समस्या यह है कि जब उपयोगकर्ता पहली बार इंटरैक्ट करता है, तब ऐसे पेज में ब्लॉक किया गया मुख्य थ्रेड होने की संभावना ज़्यादा होती है जिनमें सिंक्रोनस JavaScript या अन्य गहन रेंडरिंग टास्क होते हैं. हालांकि, अगर उपयोगकर्ता JavaScript के प्रोसेस होने तक, पेज से इंटरैक्ट करने का इंतज़ार करते हैं, तो हो सकता है कि आईएनपी बहुत कम हो.
उपयोगकर्ता किसी पेज से कब इंटरैक्ट करेंगे, यह काफ़ी हद तक इस बात पर निर्भर करता है कि वह पेज इंटरैक्टिव दिखेगा या नहीं. इसे TBT से नहीं मापा जा सकता.
TBT, टैप डिले पर ध्यान नहीं देता.
अगर किसी साइट को मोबाइल पर देखने के लिए ऑप्टिमाइज़ नहीं किया गया है, तो इवेंट हैंडलर चलाने से पहले किसी भी टैप करने के बाद, ब्राउज़र 300 मि॰से॰ की देरी जोड़ेंगे. ऐसा इसलिए किया जाता है, क्योंकि उन्हें यह तय करना होता है कि उपयोगकर्ता, दो बार टैप करके ज़ूम करने की कोशिश कर रहा है. इसके बाद ही, वह माउस चालू कर सकता है या इवेंट पर क्लिक कर सकता है.
इस देरी को पेज की आईएनपी में गिना जाता है, क्योंकि यह उपयोगकर्ता को मिलने वाले इनपुट इंतज़ार का समय तय करती है. यह देरी तकनीकी रूप से ज़्यादा टास्क नहीं है. इसलिए, पेज के टीबीटी पर इसका कोई असर नहीं पड़ता. इसका मतलब है कि किसी पेज का TBT स्कोर अच्छा होने के बावजूद, उसका आईएनपी खराब हो सकता है.
आईएनपी पर कैश मेमोरी की स्थिति और बैक-फ़ॉरवर्ड कैश मेमोरी के असर
जिस तरह सही कैशिंग से फ़ील्ड में एलसीपी को बेहतर बनाया जा सकता है, उसी तरह आईएनपी को भी बेहतर किया जा सकता है.
असल में, हो सकता है कि उपयोगकर्ता के कैश में किसी साइट का JavaScript पहले से मौजूद हो. इसलिए, इसे प्रोसेस करने में कम समय लग सकता है और इसमें थोड़ी देरी हो सकती है.
यही बात bfcache से वापस लाए गए पेजों पर भी लागू होती है. उन मामलों में, JavaScript को मेमोरी से वापस लाया जाता है. इसलिए, हो सकता है कि उसे प्रोसेस करने में बहुत कम या बिलकुल भी समय न लगे.
सीएलएस
सीएलएस पर उपयोगकर्ता के इंटरैक्शन का असर
लैब में मापा गया सीएलएस, सिर्फ़ उन लेआउट शिफ़्ट को ध्यान में रखता है जो पेज के ऊपरी हिस्से में और पेज लोड होने के दौरान होते हैं. हालांकि, यह सीएलएस, असल में चीज़ों को मापता है, इसका सिर्फ़ एक सबसेट है.
फ़ील्ड में, सीएलएस, अचानक बने सभी लेआउट शिफ़्ट को ध्यान में रखता है. ये बदलाव पेज पर बने रहने के दौरान होते हैं. इसमें, वह कॉन्टेंट भी शामिल है जो उपयोगकर्ता के इंटरैक्शन के बाद, जब उपयोगकर्ता स्क्रोल करता है या धीमे नेटवर्क वाले अनुरोध की वजह से, शिफ़्ट हो जाता है.
उदाहरण के लिए, पेजों के लिए डाइमेंशन के बिना इमेज या iframe लेज़ी-लोड होना आम बात है. इसकी वजह से, जब उपयोगकर्ता पेज के उन सेक्शन पर स्क्रोल करता है, तब लेआउट शिफ़्ट हो सकते हैं. हालांकि, ये शिफ़्ट सिर्फ़ तब हो सकते हैं, जब उपयोगकर्ता नीचे की ओर स्क्रोल करता है और अक्सर लैब टेस्ट में शामिल नहीं होता.
व्यक्तिगत सामग्री
आपके हिसाब से बनाए गए कॉन्टेंट से, पेज पर लोड होने वाले एलिमेंट पर असर पड़ता है. इसमें टारगेट किए गए विज्ञापन और A/B टेस्ट शामिल हैं. इससे इन पेजों के लोड होने के तरीके पर भी असर पड़ता है, क्योंकि आपके हिसाब से बनाया गया कॉन्टेंट अक्सर बाद में लोड होता है और उसे पेज के मुख्य कॉन्टेंट में शामिल किया जाता है. इस वजह से, लेआउट में बदलाव होता है.
लैब में, आम तौर पर पेज या तो मनमुताबिक कॉन्टेंट के बिना लोड होता है या सामान्य "टेस्ट उपयोगकर्ता" के लिए कॉन्टेंट के साथ लोड होता है. हो सकता है कि इस बदलाव की वजह से, असल में उपयोगकर्ताओं को कोई पेज न दिखे.
फ़ील्ड डेटा में सभी उपयोगकर्ताओं के अनुभव शामिल होते हैं. इसलिए, किसी पेज पर लेआउट शिफ़्ट में हुए बदलावों की संख्या (और डिग्री) इस बात पर निर्भर करती है कि कौनसा कॉन्टेंट लोड किया गया है.
सीएलएस पर कैश मेमोरी की स्थिति और बैक-फ़ॉरवर्ड कैश मेमोरी का असर
लोड के दौरान लेआउट शिफ़्ट होने की दो सबसे आम वजहें हैं, बिना डाइमेंशन वाली इमेज और iframe (जैसा कि ऊपर बताया गया है) और धीमे लोड होने वाले वेब फ़ॉन्ट. ये दोनों समस्याएं, कैश मेमोरी खाली होने पर उपयोगकर्ता के पहली बार साइट पर जाने पर, उसके अनुभव पर असर डाल सकती हैं.
अगर किसी पेज के रिसॉर्स, कैश मेमोरी में सेव किए जाते हैं या पेज को बैक-फ़ॉरवर्ड कैश मेमोरी से वापस लाया जाता है, तो ब्राउज़र आम तौर पर इमेज और फ़ॉन्ट के डाउनलोड होने का इंतज़ार किए बिना तुरंत इमेज और फ़ॉन्ट रेंडर कर सकता है. इससे फ़ील्ड में सीएलएस की वैल्यू, लैब टूल की रिपोर्ट से कम हो सकती हैं.
नतीजे अलग होने पर क्या करें
सामान्य नियम के तौर पर, अगर आपके पास किसी पेज के लिए फ़ील्ड डेटा और लैब डेटा, दोनों हैं, तो फ़ील्ड डेटा का इस्तेमाल करके आपको प्राथमिकता देनी चाहिए. फ़ील्ड डेटा से पता चलता है कि असल लोग कैसा अनुभव कर रहे हैं. इसलिए, सही मायनों में यह समझने का सबसे सही तरीका है कि आपके उपयोगकर्ताओं को क्या समस्या आ रही है और किस चीज़ में सुधार की ज़रूरत है.
दूसरी तरफ़, अगर आपके फ़ील्ड डेटा से पूरे बोर्ड में अच्छे स्कोर दिखते हैं, लेकिन आपके लैब डेटा से पता चलता है कि अब भी सुधार की संभावना है, तो बेहतर होगा कि आगे क्या सुधार किए जा सकते हैं.
हालांकि, फ़ील्ड डेटा से उपयोगकर्ताओं के असल अनुभव की जानकारी मिलती है, लेकिन यह सिर्फ़ उन उपयोगकर्ताओं के लिए है जो आपकी साइट को लोड कर पाते हैं. कभी-कभी लैब डेटा से, आपकी साइट की पहुंच बढ़ाने वाले अवसरों की पहचान करने में मदद मिलती है. साथ ही, इससे साइट को धीमे नेटवर्क या कम सुविधाओं वाले डिवाइस का इस्तेमाल करने वाले लोगों के लिए भी उपलब्ध कराया जा सकता है.
कुल मिलाकर, लैब डेटा और फ़ील्ड डेटा, दोनों ही परफ़ॉर्मेंस को मेज़र करने के अहम हिस्से हैं. इन दोनों की अपनी-अपनी खूबियां और सीमाएं हैं. अगर सिर्फ़ किसी एक का इस्तेमाल किया जा रहा है, तो शायद आप अपने उपयोगकर्ताओं के लिए अनुभव को बेहतर बनाने का मौका न खो दें.