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