एसपीए, Core Web Vitals, और Core Web Vitals में एसपीए को मेज़र करने के तरीके के बारे में अक्सर पूछे जाने वाले सवालों के जवाब.
पब्लिश होने की तारीख: 14 सितंबर, 2021, आखिरी अपडेट: 11 अगस्त, 2026
Chrome की टीम ने मई 2020 में, Web Vitals लॉन्च की थी. तब से हमें इस प्रोग्राम के बारे में कई बेहतरीन सवाल और सुझाव मिले हैं.
हमें सबसे ज़्यादा सवाल, सिंगल-पेज ऐप्लिकेशन (एसपीए) में Core Web Vitals को मेज़र करने के तरीके के बारे में मिले हैं. साथ ही, यह सवाल भी पूछा गया है कि एसपीए आर्किटेक्चर, Core Web Vitals के स्कोर पर कैसे असर डालते हैं. शायद इन सवालों का जवाब देना सबसे मुश्किल है.
इन सवालों का जवाब देना मुश्किल है, क्योंकि यह समस्या काफ़ी पेचीदा है. इसलिए, इस पोस्ट में हम सबसे आम सवालों के जवाब देने की पूरी कोशिश करेंगे. साथ ही, हम ज़्यादा से ज़्यादा जानकारी और कॉन्टेक्स्ट उपलब्ध कराएंगे.
हालांकि, खास जानकारी देने से पहले, यह बताना ज़रूरी है कि Google को इस बात से कोई फ़र्क़ नहीं पड़ता कि किसी साइट को बनाने के लिए किस आर्किटेक्चर या टेक्नोलॉजी का इस्तेमाल किया गया है. हमारा मानना है कि एसपीए और मल्टी-पेज ऐप्लिकेशन (एमपीए), दोनों ही उपयोगकर्ताओं को अच्छी क्वालिटी का अनुभव दे सकते हैं. वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली मेट्रिक लॉन्च करने का हमारा मकसद, ऐसी मेट्रिक उपलब्ध कराना है जिनसे टेक्नोलॉजी के हिसाब से अलग-अलग अनुभव को मेज़र किया जा सके.
अक्सर पूछे जाने वाले सवाल
यहां इस विषय के बारे में अक्सर पूछे जाने वाले कुछ सवाल दिए गए हैं. हमारा सुझाव है कि आप अपनी राय या सुझाव, राय या सुझाव देने वाले हमारे ग्रुप में दें या कोई समस्या सबमिट करें. हम आपकी राय या सुझाव को इस अक्सर पूछे जाने वाले सवालों वाले पेज में शामिल करेंगे.
क्या Core Web Vitals मेट्रिक में, एसपीए के रूट ट्रांज़िशन शामिल होते हैं?
जब Core Web Vitals मेट्रिक लॉन्च की गई थीं, तब इनमें से हर मेट्रिक को मौजूदा, टॉप-लेवल पेज नेविगेशन के हिसाब से मेज़र किया जाता था. अगर कोई पेज, डाइनैमिक तरीके से नया कॉन्टेंट लोड करता है और पता बार में पेज का यूआरएल अपडेट करता है, तो इससे वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक को मेज़र करने के तरीके पर कोई असर नहीं पड़ता था.
मेट्रिक की वैल्यू रीसेट नहीं की जाती थीं. साथ ही, हर मेट्रिक मेज़रमेंट से जुड़ा यूआरएल, वह यूआरएल होता था जिस पर उपयोगकर्ता ने नेविगेट किया था और जिसकी वजह से पेज लोड हुआ था.
Chrome 151 में नए एपीआई लॉन्च किए गए हैं. इनकी मदद से, एसपीए के रूट ट्रांज़िशन के दौरान, Core Web Vitals को मेज़र किया जा सकता है. अगस्त 2026 तक, इन एपीआई का इस्तेमाल, मेज़रमेंट लाइब्रेरी में शुरू हो गया है. जैसे, web-vitals, RUM सलूशन, और Chrome DevTools जैसे टूल. Chrome ने अब तक, इन्हें Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट (CrUX) में इंटिग्रेट करने की टाइमलाइन पब्लिश नहीं की है. इसके अलावा, अन्य ब्राउज़र इंजन अब तक इन नए एपीआई को सपोर्ट नहीं करते. इसलिए, इन ब्राउज़र के लिए, Core Web Vitals को सिर्फ़ पूरे पेज लोड होने के दौरान मेज़र किया जा सकता है.
इस समस्या को हल करना मुश्किल क्यों था?
आजकल एसपीए बनाने का कोई स्टैंडर्ड तरीका नहीं है. साथ ही, लोकप्रिय एसपीए और राउटिंग लाइब्रेरी में भी, उपयोगकर्ता अनुभव अलग-अलग हो सकता है:
- कुछ एसपीए, नया "पूरा पेज" कॉन्टेंट लोड करने पर ही यूआरएल अपडेट करते हैं. वहीं, अन्य साइटें, कॉन्टेंट में छोटे-मोटे बदलावों या सिर्फ़ यूआई की स्थिति में बदलाव होने पर भी यूआरएल अपडेट करती हैं.
- कुछ एसपीए, History API का इस्तेमाल करके यूआरएल अपडेट करते हैं. वहीं, अन्य एसपीए, पुराने ब्राउज़र को सपोर्ट करने के लिए हैश में बदलाव करते हैं. कुछ एसपीए, यूआरएल को अपडेट नहीं करते.
- कुछ एसपीए, कॉन्टेंट लोड करने के बाद यूआरएल अपडेट करते हैं. वहीं, अन्य एसपीए, कॉन्टेंट लोड करने से पहले यूआरएल अपडेट करते हैं.
- कुछ एसपीए, एक ही JavaScript टास्क में, सिंक्रोनस तरीके से एक साथ कॉन्टेंट लोड करते हैं. वहीं, अन्य एसपीए, एसिंक्रोनस तरीके से, एक से ज़्यादा टास्क में कॉन्टेंट ट्रांज़िशन करते हैं. इनमें ट्रांज़िशन खत्म होने का कोई साफ़ इवेंट नहीं होता.
- कुछ एसपीए, हमेशा नेटवर्क से कॉन्टेंट लोड करते हैं. वहीं, अन्य एसपीए, सारा कॉन्टेंट पहले से लोड कर लेते हैं, ताकि रूट में बदलाव होने पर, कॉन्टेंट तुरंत मेमोरी से लोड हो जाए.
इन अंतरों की वजह से, एसपीए के रूट में बदलाव या एसपीए की पहचान करना और यह तय करना कि एसपीए के रूट में बदलाव क्या है, बड़े पैमाने पर बहुत मुश्किल है.
कुछ मामलों में, एसपीए के रूट में बदलाव, लॉजिक के हिसाब से एमपीए के पेज लोड होने जैसा होता है. ऐसे मामलों में, मौजूदा Core Web Vitals मेट्रिक को लागू किया जा सकता है.
हालांकि, यूआरएल में होने वाले अन्य बदलावों से, "असल" रूट में होने वाले बदलावों की पहचान करने के लिए, भरोसेमंद तरीके से काम करने वाले सॉलिड ह्यूरिस्टिक के बिना, इन मामलों में Core Web Vitals मेट्रिक की रिपोर्टिंग करने से, डेटा में गड़बड़ी हो सकती है. साथ ही, यह साइट पर उपयोगकर्ता के असल अनुभव को कम उपयोगी या कम दिखाने वाला हो सकता है. इसके अलावा, ऐसे ट्रांज़िशन की शुरुआत और खत्म होने के बारे में साफ़ सिग्नल भी नहीं मिलते.
सॉफ्ट नेविगेशन की सुविधा से, इस समस्या का समाधान मिला है. इसके लिए, परफ़ॉर्मेंस के दो नए एपीआई लॉन्च किए गए हैं:
PerformanceSoftNavigation, जिससे यह मेज़र किया जाता है कि उपयोगकर्ता के इंटरैक्शन की वजह से, कब पेंट और यूआरएल में बदलाव होता है. इन तीनों चीज़ों के कॉम्बिनेशन से, "सॉफ्ट नेविगेशन" की स्टैंडर्ड परिभाषा मिलती है. इससे कोई फ़र्क़ नहीं पड़ता कि किस फ़्रेमवर्क का इस्तेमाल किया गया है और पहले बताए गए कुछ अंतरों से भी कोई फ़र्क़ नहीं पड़ता. इससे, परफ़ॉर्मेंस की टाइमलाइन को अलग-अलग "नेविगेशन" में बांटा जा सकता है. इससे, हर नेविगेशन के लिए सीएलएस और आईएनपी को मेज़र किया जा सकता है.InteractionContentfulPaint, जिससे इंटरैक्शन के बाद "कॉन्टेंटफ़ुल पेंट" को मेज़र किया जाता है. इससे, इन सॉफ्ट नेविगेशन के लिए एफ़सीपी और एलसीपी को मेज़र किया जा सकता है.
इन दोनों एपीआई के कॉम्बिनेशन से, Core Web Vitals को पूरे पेज लोड होने और सॉफ्ट नेविगेशन, दोनों के दौरान मेज़र किया जा सकता है.
क्या एसपीए के रूट में होने वाले बदलाव, Core Web Vitals के लिए, पूरे पेज लोड होने के बराबर होते हैं?
नहीं, इन दोनों तरह के नेविगेशन में अब भी कई अंतर हैं. इनकी वजह से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक अलग-अलग हो सकती हैं.
सॉफ्ट नेविगेशन में, पेज पर कॉन्टेंट होता है. साथ ही, नया "पेज" दिखाने के लिए, उस कॉन्टेंट के कुछ या सभी हिस्से को अपडेट किया जाता है. कई मामलों में, यह उस अंतर जैसा होता है जो बिना कैश मेमोरी में सेव किए गए पूरे पेज के लोड होने और पेज लोड होने के बीच होता है. ऐसा तब होता है, जब पेज के कुछ या सभी रिसॉर्स कैश मेमोरी में सेव होते हैं. हालांकि, यह अंतर और भी ज़्यादा हो सकता है, क्योंकि कुछ कॉन्टेंट रेंडर किया जा सकता है.
सैद्धांतिक तौर पर, मुख्य अंतर यह होगा कि सॉफ्ट नेविगेशन, ज़्यादा तेज़ी से हो सकते हैं. हालांकि, इनमें अन्य, ज़्यादा पेचीदा अंतर भी होते हैं.
सॉफ्ट नेविगेशन के नए एपीआई, सिर्फ़ नए कॉन्टेंट को ध्यान में रखते हैं. इसलिए, अगर कोई पेज <h1> और टेक्स्ट कॉन्टेंट को अपडेट करता है, लेकिन पेजों के बीच एक ही हीरो इमेज रखता है, तो हीरो इमेज को एलसीपी कैंडिडेट के तौर पर नहीं माना जाएगा. ऐसा तब होगा, जब वह फिर से पेंट नहीं हुई होगी. इससे, एलसीपी टाइम का हिसाब लगाने के लिए इस्तेमाल किए जाने वाले एलिमेंट में अंतर होगा. यह अंतर इस बात पर निर्भर करेगा कि एक ही पेज, पूरे पेज के लोड होने के तौर पर लोड किया गया है या किसी अन्य मौजूदा पेज से सॉफ्ट नेविगेशन के तौर पर लोड किया गया है.
इसी तरह, सॉफ्ट नेविगेशन के लिए आईएनपी कम हो सकता है, क्योंकि साइट को चलाने के लिए ज़रूरी ज़्यादातर JavaScript पहले से ही लोड हो जाएगी. इसी तरह, सॉफ्ट नेविगेशन में सीएलएस कम (या ज़्यादा!) हो सकता है. ऐसा तब होगा, जब एक ही कॉन्टेंट की वजह से, पूरे पेज के लोड होने पर सीएलएस होता है, लेकिन सॉफ्ट नेविगेशन पर उसे लोड या फिर से रेंडर करने की ज़रूरत नहीं होती.
इसके अलावा, पूरे पेज के लोड होने (नेविगेशन इंटरैक्शन प्रोसेसिंग के बाद मेज़र किया गया) और सॉफ्ट नेविगेशन (इंटरैक्शन शुरू होने के समय से मेज़र किया गया) के दौरान, मेज़रमेंट लेने के समय में भी थोड़ा अंतर होता है.
जैसा कि पहले बताया गया है, इनमें से कई अंतर, कैश मेमोरी में सेव किए गए और कैश मेमोरी में सेव नहीं किए गए पेजों के अंतर जैसे ही हैं. साथ ही, Core Web Vitals, जिन चीज़ों को मेज़र करने की कोशिश करती है उनका कॉन्सेप्ट अब भी लागू होता है. हालांकि, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी से जुड़ी समस्याओं की जांच करते समय, इन पेचीदा अंतरों को समझना ज़रूरी है.
क्या एसपीए के लिए, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के स्कोर बेहतर करना, एमपीए के मुकाबले ज़्यादा मुश्किल है?
एसपीए आर्किटेक्चर में ऐसा कुछ नहीं है जिसकी वजह से, एसपीए में मौजूद कोई पेज, एमपीए में मौजूद किसी मिलते-जुलते पेज की तुलना में, ज़्यादा तेज़ी से लोड न हो पाए. साथ ही, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली सभी मेट्रिक में, बेहतर स्कोर न कर पाए.
हालांकि, अच्छी तरह से ऑप्टिमाइज़ किए गए एमपीए के पास, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के थ्रेशोल्ड को पूरा करने के कुछ ऐसे फ़ायदे हैं जो एसपीए के पास नहीं हैं. सॉफ्ट नेविगेशन की सुविधा से, इस समस्या को काफ़ी हद तक कम किया गया है. हालांकि, ऐसा तब भी हो सकता है, जब इन नए एपीआई का इस्तेमाल न किया गया हो. इसकी वजह यह है कि एमपीए आर्किटेक्चर में, हर "पेज" को पूरे पेज के नेविगेशन के तौर पर लोड किया जाता है. इसके बजाय, डाइनैमिक तरीके से कॉन्टेंट फ़ेच करके, उसे मौजूदा पेज में डाला जाता है. इसका मतलब है कि एमपीए पर आने वाले लोग, साइट से एक से ज़्यादा पेज लोड कर सकते हैं. इसका मतलब यह है कि एमपीए के लिए, सभी पेज लोड के डिस्ट्रिब्यूशन का ज़्यादा प्रतिशत, कुछ या सभी सब-रिसॉर्स को कैश मेमोरी में सेव करने से जुड़ा होगा.
यह माना जाता है कि किसी एसपीए की तुलना में, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक में, एमपीए की परफ़ॉर्मेंस बेहतर होने के लिए, कुछ चीज़ें ज़रूरी हैं:
- एमपीए में, सब-रिसॉर्स कैश मेमोरी में सेव करने की सुविधा ऑप्टिमाइज़ होनी चाहिए, ताकि यह पक्का किया जा सके कि 75वें पर्सेंटाइल पर, सेम-ऑरिजिन पेज लोड, क्रॉस-ऑरिजिन पेज लोड की तुलना में ज़्यादा तेज़ी से लोड हों.
- एमपीए पर आने वाले लोगों को, एक से ज़्यादा पेज पर जाना होगा, ताकि साइट को कैश मेमोरी में सेव करने के फ़ायदे मिल सकें. इससे पेज ज़्यादा तेज़ी से लोड होते हैं.
वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के आकलन में, पेज विज़िट के 75वें पर्सेंटाइल को ध्यान में रखा जाता है. इसलिए, डेटासेट में बेहतर परफ़ॉर्मेंस वाली ज़्यादा पेज विज़िट होने से, इस बात की संभावना बढ़ जाएगी कि डिस्ट्रिब्यूशन के 75वें पर्सेंटाइल पर विज़िट, सुझाए गए थ्रेशोल्ड के अंदर होगी.
ध्यान दें कि वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के स्कोर की तुलना करते समय, यह समझना ज़रूरी है कि डेटा को कैसे एग्रीगेट किया जाता है. इसका मतलब है कि डिस्ट्रिब्यूशन में मौजूद डेटासेट में, आपकी साइट या ऑरिजिन के सभी पेज शामिल हैं या सिर्फ़ किसी खास पेज यूआरएल के लिए पेज लोड शामिल हैं.
किसी ऑरिजिन के सभी पेजों के स्कोर को एग्रीगेट करते समय, तेज़ी से लोड होने वाले अलग-अलग पेज, पूरे ऑरिजिन के लिए 75वें पर्सेंटाइल को बेहतर बना सकते हैं. हालांकि, अलग-अलग पेजों के हिसाब से एग्रीगेट करते समय, एक पेज के स्कोर का असर दूसरे पेज के स्कोर पर नहीं पड़ेगा. दूसरे शब्दों में, पेज के हिसाब से एमपीए के स्कोर को एग्रीगेट करते समय, चेकआउट पेज पर कैश मेमोरी में सेव किए गए कॉन्टेंट के तेज़ी से लोड होने से, साइट के लैंडिंग पेज पर शुरुआती लोड के धीमे होने के स्कोर बेहतर नहीं होंगे.
PageSpeed Insights या Chrome उपयोगकर्ता अनुभव रिपोर्ट एपीआई का इस्तेमाल करके, एग्रीगेशन के अलग-अलग तरीकों के लिए अपनी साइट का स्कोर देखा जा सकता है. यह एपीआई, अलग-अलग पेज यूआरएल और पूरे ऑरिजिन, दोनों के लिए स्कोर की रिपोर्ट करता है.
एसपीए आर्किटेक्चर, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के स्कोर पर एक और तरीके से असर डाल सकता है. यह उन मेट्रिक के लिए होता है जो किसी पेज के पूरे लाइफ़स्पैन को ध्यान में रखती हैं. एसपीए पर आने वाले लोग, पूरे सेशन के दौरान एक ही "पेज" पर बने रहते हैं. इसलिए, समय के साथ इकट्ठा होने वाली मेट्रिक, एमपीए की तुलना में एसपीए पर ज़्यादा असर डाल सकती हैं.
सॉफ्ट नेविगेशन की सुविधा से, हमारा मानना है कि Core Web Vitals को मेज़र करने के तरीके के मामले में, एसपीए को कोई नुकसान नहीं होना चाहिए. हालांकि, इन एपीआई को सभी टूलिंग और रिपोर्टिंग सलूशन में पूरी तरह से इंटिग्रेट करने में समय लगेगा.
अगर एसपीए आर्किटेक्चर से उपयोगकर्ता अनुभव बेहतर होता है, तो क्या यह सुधार मेट्रिक में नहीं दिखना चाहिए?
हां, दिखना चाहिए. एसपीए को आज वेब पर अलग-अलग तरीकों से लागू किया जाता है. इसलिए, यह तय करना मुश्किल था कि अनुभव में कितना सुधार हुआ है. अब हमारे पास, मेज़रमेंट की समस्या का समाधान है. साथ ही, इन नए एपीआई का इस्तेमाल करने पर, एसपीए पर माइग्रेट करने से होने वाले सुधार, मेट्रिक में दिखने चाहिए.
असल में, वेब परफ़ॉर्मेंस इंडस्ट्री (Google भी शामिल है) ने, पेज लोड होने के बाद की परफ़ॉर्मेंस के लिए, उपयोगकर्ता के हिसाब से मेट्रिक डेवलप करने में, पेज लोड होने के दौरान की परफ़ॉर्मेंस के मुकाबले, काफ़ी कम समय और मेहनत लगाई है. ऐसा इसलिए नहीं है, क्योंकि पेज लोड होने के बाद की परफ़ॉर्मेंस ज़रूरी नहीं है. ऐसा इसलिए है, क्योंकि पेज लोड होने के बाद का यूएक्स और इंटरैक्शन, ज़्यादा अलग-अलग और कम तय होता है. इसलिए, इनके लिए मेट्रिक डिज़ाइन करना मुश्किल है.
हालांकि, अब हमारे पास एसपीए की परफ़ॉर्मेंस को मेज़र करने के लिए, पेज लोड होने के बाद की ज़्यादा मेट्रिक हैं. फिर भी, हम सिर्फ़ इसलिए लोड होने के अनुभव को नज़रअंदाज़ नहीं करना चाहेंगे, क्योंकि पेज लोड होने के बाद का अनुभव बेहतर हो गया है.
Web Vitals पहल का एक लक्ष्य, वेब पेज को लोड करने और इस्तेमाल करने के ज़्यादा से ज़्यादा पहलुओं में, उपयोगकर्ता को बेहतर अनुभव देना है. हम ऐसे मामलों को बढ़ावा नहीं देना चाहते जहां खराब अनुभवों को सही ठहराया जा सके. ऐसा तब होगा, जब आपके पास उन्हें पूरा करने के लिए, अच्छे अनुभव मौजूद हों. उपयोगकर्ता चाहते हैं कि पेज तेज़ी से लोड हों और नए कॉन्टेंट पर तेज़ी से ट्रांज़िशन करें. हमने ऐसी मेट्रिक डिज़ाइन करने की कोशिश की है जो इस तरह के अनुभवों को बढ़ावा दें.
हमने अपनी साइट को एमपीए से एसपीए पर माइग्रेट किया है और हमारे स्कोर कम हो गए हैं. क्या ऐसा होना चाहिए?
यह कई बातों पर निर्भर करता है. आर्किटेक्चर को बड़े पैमाने पर माइग्रेट करने के बाद, आपके स्कोर में बदलाव होने की कई वजहें हो सकती हैं. हालांकि, वॉर्म कैश मेमोरी में सेव किए गए कॉन्टेंट के लोड होने की संख्या में कमी, कुछ बदलावों की वजह हो सकती है.
यह देखने के लिए, Lighthouse की मदद से, अपने किसी लैंडिंग पेज के एमपीए और एसपीए, दोनों वर्शन की जांच करें . अगर एसपीए वर्शन के लिए, Core Web Vitals मेट्रिक का Lighthouse स्कोर कम है, तो ऐसा हो सकता है कि अपडेट के बाद, लोड होने का अनुभव खराब हो गया हो.
क्या मुझे अपनी साइट को एसपीए से एमपीए पर माइग्रेट करना चाहिए, ताकि Core Web Vitals के स्कोर बेहतर हो सकें?
शायद नहीं. आपको एसपीए से एमपीए पर सिर्फ़ तब माइग्रेट करना चाहिए, जब आपको अपने एसपीए स्टैक से संतुष्टि न मिले और आपके पास यह मानने की वजह हो कि एमपीए, उपयोगकर्ता को बेहतर अनुभव देगा.
सॉफ्ट नेविगेशन की सुविधा से, हमारा मानना है कि हमने मेज़रमेंट की समस्याओं को हल कर लिया है. इसलिए, सिर्फ़ इस वजह से माइग्रेट करना सही नहीं है.
हालांकि, अगर आपके पास यह दिखाने की वजह है कि परफ़ॉर्मेंस बेहतर होगी, न कि सिर्फ़ मेज़रमेंट बेहतर होंगे, तो एसपीए से एमपीए (या इसके उलट) पर माइग्रेट किया जा सकता है.
अगर वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी के स्कोर, सिर्फ़ एसपीए के लैंडिंग पेजों के लिए रिपोर्ट किए जाते हैं, तो रूट ट्रांज़िशन के बाद "पेजों" पर होने वाली समस्याओं को कैसे डीबग किया जा सकता है?
Google के ऐसे टूल जो Core Web Vitals मेट्रिक के लिए फ़ील्ड डेटा की रिपोर्ट करते हैं (जैसे, Search Console और PageSpeed Insights), अपना डेटा Chrome उपयोगकर्ता अनुभव रिपोर्ट (CrUX) से पाते हैं. CrUX, डेटा को ऑरिजिन या पेज यूआरएल (यानी, लोड होने के समय का पेज यूआरएल) के हिसाब से एग्रीगेट करता है.
हम CrUX को, एग्रीगेट किए गए डेटा में, एसपीए रूट के हिसाब से डेटा शामिल करने की अनुमति देने पर काम कर रहे हैं. हालांकि, साइट के मालिक के तौर पर, अब नए एपीआई का इस्तेमाल करके, एसपीए रूट के हिसाब से Core Web Vitals को पहले से मेज़र किया जा सकता है. इससे यह समझा जा सकता है कि आपके स्कोर कैसे बदल सकते हैं.
इस बारे में ज़्यादा जानकारी और सबसे सही तरीकों के लिए, सॉफ्ट नेविगेशन को मेज़र करना देखें.
Google, यह पक्का करने के लिए क्या कर रहा है कि एसपीए की तुलना में, एमपीए को कोई अनुचित फ़ायदा न मिले?
जैसा कि पहले बताया गया है, सॉफ्ट नेविगेशन की सुविधा से, हमारा मानना है कि अब तक किए गए काम से, इस मामले में एसपीए को कोई नुकसान नहीं होना चाहिए. हालांकि, सभी टूलिंग और रिपोर्टिंग सलूशन में पूरी तरह से इंटिग्रेट करने में समय लगेगा.
क्रॉस-ऑरिजिन और सेम-ऑरिजिन पेज विज़िट का आकलन अलग-अलग करें
आजकल, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक, सभी पेज विज़िट को एक ही बकेट में एग्रीगेट करती हैं. ये मेट्रिक, नई और वापस आने वाली विज़िट या लैंडिंग पेजों और चेकआउट पेजों या एग्रीगेशन के किसी अन्य टाइप के बीच अंतर नहीं करतीं. इनमें कैश मेमोरी की स्थिति का असर परफ़ॉर्मेंस पर पड़ सकता है.
एसपीए और एमपीए की परफ़ॉर्मेंस के बीच के अंतर को सामान्य करने का एक तरीका यह है कि अलग-अलग तरह की विज़िट के लिए अलग-अलग वेटिंग लागू की जाए. यहां तक कि पूरी तरह से अलग थ्रेशोल्ड के सुझाव भी दिए जा सकते हैं.
हम कैश मेमोरी में सेव करने की सुविधा को बेहतर तरीके से लागू करने के लिए, इनाम देना चाहते हैं. हालांकि, हम यह नहीं चाहते कि साइट के अंदर तेज़ी से नेविगेट करने की सुविधा, लैंडिंग पेज के धीमे लोड होने की समस्या को छिपा सके. हम साइटों को, सिर्फ़ मेट्रिक स्कोर बेहतर करने के लिए, लंबे पेजों को छोटे पेजों के कलेक्शन में बांटने के लिए भी बढ़ावा नहीं देना चाहते.
क्रॉस-ऑरिजिन और सेम-ऑरिजिन पेज विज़िट का आकलन अलग-अलग करके, हम यह पक्का करने में मदद कर सकते हैं कि दोनों तरह के अनुभव ज़रूरी हैं. साथ ही, किसी दी गई साइट पर किसी एक टाइप की लोकप्रियता की वजह से, किसी खास मेट्रिक के डिस्ट्रिब्यूशन में गड़बड़ी न हो.
आखिर में कुछ ज़रूरी बातें
Google, Web Vitals मेट्रिक को बेहतर बनाने के लिए पूरी तरह से प्रतिबद्ध है. साथ ही, यह पक्का करता है कि ये मेट्रिक, उपयोगकर्ताओं के लिए ज़रूरी अच्छी क्वालिटी के अनुभवों को मेज़र करें और उन्हें बढ़ावा दें. हालांकि, हम यह मानते हैं कि आज मेज़रमेंट में कमियां मौजूद हैं. अब मेट्रिक, एसपीए के रूट ट्रांज़िशन को कवर कर सकती हैं. इससे, मुख्य कमियों में से एक को दूर किया गया है.
हमारा मानना है कि इन नए एपीआई (खास तौर पर InteractionContentfulPaint) के अन्य इस्तेमाल और संभावित फ़ायदे भी हैं. ये फ़ायदे, सॉफ्ट नेविगेशन के लिए Core Web Vitals को मेज़र करने के अलावा भी मिल सकते हैं. हमें इन एपीआई को आगे बढ़ाने में बहुत खुशी हो रही है, क्योंकि इन्हें लॉन्च करने की मुख्य वजह को दूर कर दिया गया है.
मुझे उम्मीद है कि इस पोस्ट से, इस पेचीदा और बारीकी से समझने वाले विषय के बारे में कुछ जानकारी मिली होगी. अगर आपके पास, वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली मौजूदा या आने वाली मेट्रिक के बारे में कोई राय या सुझाव है, तो web-vitals-feedback@googlegroups.com पर ईमेल करें.