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