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