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