सॉफ़्ट नेविगेशन के मेज़रमेंट के साथ प्रयोग करना

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

लॉन्च के बाद से ही वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली पहल ने, वेबसाइट बनाने या लोड करने के तरीके के बारे में तकनीकी जानकारी के बजाय, वेबसाइट के उपयोगकर्ता अनुभव का आकलन करने की कोशिश की है. वेबसाइट की परफ़ॉर्मेंस की जानकारी देने वाली तीन मेट्रिक को उपयोगकर्ता को ध्यान में रखकर बनाई गई मेट्रिक के तौर पर बनाया गया था. यह DOMContentLoaded या load जैसी मौजूदा तकनीकी मेट्रिक से बेहतर है. इनमें ऐसे समय को मापा जाता है जो अक्सर उपयोगकर्ताओं के पेज की परफ़ॉर्मेंस के आकलन से अलग होते थे. इसलिए, साइट को बनाने में जिस टेक्नोलॉजी का इस्तेमाल किया गया है उसका असर साइट के स्कोर पर नहीं पड़ेगा. इससे साइट की परफ़ॉर्मेंस बेहतर होगी.

हालांकि, हकीकत में यह सबसे आम होता है और एक पेज के ऐप्लिकेशन का बेहद लोकप्रिय आर्किटेक्चर वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक पर कभी भी पूरी तरह से काम नहीं करता है. जब उपयोगकर्ता साइट के बारे में नेविगेट करता है, तो अलग-अलग वेब पेज लोड करने की बजाय, ये वेब पेज तथाकथित "सॉफ़्ट नेविगेशन" का इस्तेमाल करते हैं, जहां पेज की सामग्री को JavaScript से बदल दिया जाता है. इन ऐप्लिकेशन में, यूआरएल में बदलाव करके और पिछले यूआरएल को ब्राउज़र के इतिहास में पुश करके, पारंपरिक वेब पेज आर्किटेक्चर के भ्रम को बनाए रखा जाता है. ऐसा इसलिए, ताकि 'वापस जाएं' और 'आगे बढ़ें' बटन उपयोगकर्ता की उम्मीद के मुताबिक काम कर सकें.

कई JavaScript फ़्रेमवर्क इस मॉडल का इस्तेमाल करते हैं, लेकिन हर फ़्रेमवर्क को अलग तरीके से इस्तेमाल किया जाता है. यह उस पेज से बाहर है जिसे ब्राउज़र आम तौर पर "पेज" मानता है. इसलिए, इसे मेज़र करना हमेशा से मुश्किल रहा है: इसे नया पेज समझने की तुलना में, मौजूदा पेज पर हुए इंटरैक्शन के बीच क्या लाइन बनानी है?

Chrome टीम पिछले कुछ समय से इस चुनौती पर विचार कर रही है. साथ ही, यह तय करने की कोशिश कर रही है कि "सॉफ़्ट नेविगेशन" क्या होता है और इसके लिए वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी कैसे मापी जा सकती है. यह ठीक उसी तरह है जैसे किसी कंवेंशनल मल्टी-पेज आर्किटेक्चर (एमपीए) में लागू की गई वेबसाइटों को मेज़र किया जाता है. शुरुआती दौर में ही टीम, इस्तेमाल की जा सकने वाली जानकारी को साइटों के लिए पहले से ज़्यादा जगहों पर उपलब्ध कराने के लिए तैयार है. इससे साइटों को, अब तक किए गए तरीके के बारे में सुझाव, शिकायत या राय देने में मदद मिलेगी.

सॉफ़्ट नेविगेशन क्या है?

हमने सॉफ़्ट नेविगेशन की यह परिभाषा तैयार की है:

  • नेविगेशन, उपयोगकर्ता की कार्रवाई के बाद शुरू होता है.
  • नेविगेशन की वजह से, उपयोगकर्ता को अपने यूआरएल में बदलाव दिखता है. साथ ही, इतिहास भी बदल जाता है.
  • नेविगेशन से डीओएम बदल जाता है.

कुछ साइटों के लिए, इस तरह के अनुमान गलत पॉज़िटिव (जिसके बारे में उपयोगकर्ता "नेविगेशन" को ध्यान में नहीं रखता) या गलत नेगेटिव (जिसमें उपयोगकर्ता इन मानदंडों को पूरा न करने के बावजूद हुआ है) को "नेविगेशन" मानता है. हम अनुभव के बारे में, सॉफ़्ट नेविगेशन स्पेसिफ़िकेशन डेटा स्टोर करने की जगह पर आपके सुझाव, शिकायत या राय का स्वागत करते हैं.

Chrome, सॉफ़्ट नेविगेशन को कैसे लागू करता है?

सॉफ़्ट नेविगेशन के अनुभव की सुविधा चालू होने पर (अगले सेक्शन में इस बारे में ज़्यादा जानकारी दी गई है), Chrome परफ़ॉर्मेंस से जुड़ी कुछ मेट्रिक की रिपोर्ट करने का तरीका बदल देगा:

इन बदलावों से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी और इससे जुड़ी कुछ डाइग्नोस्टिक्स मेट्रिक को हर पेज नेविगेशन के हिसाब से मेज़र किया जा सकेगा. हालांकि, इसमें कुछ बारीकियों को ध्यान में रखना ज़रूरी है.

Chrome में सॉफ़्ट नेविगेशन की सुविधा चालू करने के क्या नतीजे हैं?

यह सुविधा चालू करने के बाद, साइटों के मालिकों को इन बदलावों को ध्यान में रखना होगा:

  • सॉफ़्ट नेविगेशन के लिए, अन्य एफ़पी, एफ़सीपी, और एलसीपी इवेंट फिर से भेजे जा सकते हैं. Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट (CrUX) में, इन अतिरिक्त वैल्यू को अनदेखा किया जाएगा. हालांकि, इससे आपकी साइट पर उपयोगकर्ता के असल मेज़रमेंट (आरयूएम) की मॉनिटरिंग की सुविधा पर असर पड़ सकता है. अगर आपको यह चिंता है कि इससे उन मेज़रमेंट पर असर पड़ेगा, तो RUM की सेवा देने वाली कंपनी से संपर्क करें. सॉफ़्ट नेविगेशन के लिए, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाला सेक्शन देखें.
  • आपकी परफ़ॉर्मेंस एंट्री में मौजूद नई (और वैकल्पिक) navigationID एट्रिब्यूट को इन एंट्री का इस्तेमाल करके, आपके ऐप्लिकेशन कोड में शामिल करने की ज़रूरत पड़ सकती है.
  • यह नया मोड, सिर्फ़ Chromium आधारित ब्राउज़र पर काम करेगा. हालांकि, कई नई मेट्रिक सिर्फ़ Chromium का इस्तेमाल करने वाले ब्राउज़र में उपलब्ध हैं. वहीं, कुछ मेट्रिक (एफ़सीपी, एलसीपी) अन्य ब्राउज़र में उपलब्ध हैं. ऐसा हो सकता है कि सभी उपयोगकर्ताओं ने Chromium का इस्तेमाल करने वाले ब्राउज़र के सबसे नए वर्शन पर अपग्रेड न किया हो. इसलिए, ध्यान रखें कि कुछ उपयोगकर्ता, सॉफ़्ट नेविगेशन वाली मेट्रिक का इस्तेमाल नहीं कर सकते.
  • प्रयोग के तौर पर शुरू की गई नई सुविधा के तौर पर, इसे डिफ़ॉल्ट रूप से चालू नहीं किया गया है. इसलिए, साइटों को इस सुविधा की जांच करनी चाहिए, ताकि यह पक्का किया जा सके कि इसकी वजह से अनचाहे खराब असर तो नहीं पड़ रहे.

सॉफ़्ट नेविगेशन की मेट्रिक को मेज़र करने के तरीके के बारे में ज़्यादा जानकारी के लिए, हर सॉफ़्ट नेविगेशन वाले सेक्शन के हिसाब से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाला सेक्शन देखें.

मैं Chrome में सॉफ़्ट नेविगेशन की सुविधा कैसे चालू करूं?

Chrome में सॉफ़्ट नेविगेशन की सुविधा, डिफ़ॉल्ट रूप से चालू नहीं होती. हालांकि, इस सुविधा को साफ़ तौर पर चालू करके एक्सपेरिमेंट किया जा सकता है.

डेवलपर के लिए, इसे chrome://flags/#enable-experimental-web-platform-features पर प्रयोग के तौर पर वेब प्लैटफ़ॉर्म सुविधाएं फ़्लैग चालू करके या Chrome लॉन्च करते समय --enable-experimental-web-platform-features कमांड लाइन तर्क का इस्तेमाल करके चालू किया जा सकता है.

मैं सॉफ़्ट नेविगेशन को कैसे मापूं?

सॉफ़्ट नेविगेशन एक्सपेरिमेंट चालू होने के बाद, हमेशा की तरह PerformanceObserver एपीआई का इस्तेमाल करके मेट्रिक रिपोर्ट की जाएंगी. हालांकि, इन मेट्रिक के लिए कुछ और चीज़ों का ध्यान रखना ज़रूरी होता है.

सॉफ़्ट नेविगेशन की शिकायत करें

सॉफ़्ट नेविगेशन पर नज़र रखने के लिए, PerformanceObserver का इस्तेमाल किया जा सकता है. नीचे एक कोड स्निपेट दिया गया है जो कंसोल में सॉफ़्ट नेविगेशन एंट्री को लॉग करता है. इसमें buffered विकल्प का इस्तेमाल करके, इस पेज पर पिछले सॉफ़्ट नेविगेशन भी शामिल हैं:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

इसका इस्तेमाल पिछले नेविगेशन की पूरी अवधि वाले पेज की मेट्रिक तय करने के लिए किया जा सकता है.

मेट्रिक को सही यूआरएल के हिसाब से रिपोर्ट करना

सॉफ़्ट नेविगेशन सिर्फ़ इसके बाद देखे जा सकते हैं. इसलिए, इस इवेंट के बाद कुछ मेट्रिक को तय करना और फिर पिछले यूआरएल के लिए रिपोर्ट करना ज़रूरी है, क्योंकि मौजूदा यूआरएल में अब नए पेज के लिए अपडेट किया गया यूआरएल दिखेगा.

सही PerformanceEntry की navigationId एट्रिब्यूट का इस्तेमाल करके, इवेंट को सही यूआरएल से जोड़ा जा सकता है. इसे PerformanceEntry एपीआई की मदद से खोजा जा सकता है:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

इस pageUrl का इस्तेमाल मेट्रिक की रिपोर्ट, सही यूआरएल के हिसाब से करने के लिए करना चाहिए. इसका इस्तेमाल उस मौजूदा यूआरएल के बजाय, सही यूआरएल के लिए किया जाना चाहिए जिसे उन्होंने पहले इस्तेमाल किया था.

सॉफ़्ट नेविगेशन वाले startTime फ़ेच किए जा रहे हैं

नेविगेशन के शुरू होने के समय की जानकारी इसी तरह से हासिल की जा सकती है:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime, सॉफ़्ट नेविगेशन शुरू करने वाले शुरुआती इंटरैक्शन का समय होता है. उदाहरण के लिए, बटन पर क्लिक करने का समय.

सॉफ़्ट नेविगेशन वाले समय सहित सभी परफ़ॉर्मेंस टाइम, शुरुआती "हार्ड" समय के तौर पर रिपोर्ट किए जाते हैं पेज नेविगेशन का समय. इसलिए, नेविगेशन में सॉफ़्ट नेविगेशन के शुरू होने के समय के मुकाबले सॉफ़्ट नेविगेशन लोड होने के मेट्रिक समय (उदाहरण के लिए, एलसीपी) को बेसलाइन के तौर पर सेट करने के लिए, सॉफ़्ट नेविगेशन शुरू होने के समय की ज़रूरत होती है.

सॉफ़्ट नेविगेशन के हिसाब से, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी का आकलन करना

सॉफ़्ट नेविगेशन मेट्रिक एंट्री को शामिल करने के लिए, आपको परफ़ॉर्मेंस ऑब्ज़र्वर के observe कॉल में includeSoftNavigationObservations: true को शामिल करना होगा.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

Chrome में सॉफ़्ट नेविगेशन की सुविधा को चालू करने के अलावा, observe तरीके पर अतिरिक्त includeSoftNavigationObservations फ़्लैग की ज़रूरत होती है. परफ़ॉर्मेंस ऑब्ज़र्वर लेवल पर इस ऑप्ट-इन की मदद से, यह पक्का किया जा सकेगा कि मौजूदा परफ़ॉर्मेंस मॉनिटर करने वाले लोग इन अतिरिक्त एंट्री से परेशान न हों. सॉफ़्ट नेविगेशन के लिए, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी का आकलन करते समय, कुछ दूसरी बातों का भी ध्यान रखना ज़रूरी है.

मूल "हार्ड" के लिए समय अब भी लौटाए जाएंगे नेविगेशन के शुरू होने का समय. उदाहरण के लिए, सॉफ़्ट नेविगेशन के लिए एलसीपी का हिसाब लगाने के लिए, आपको सॉफ़्ट नेविगेशन के शुरू होने का समय लेना होगा. इसके बाद, सॉफ़्ट नेविगेशन के शुरू होने के सही समय को पहले बताए गए के तौर पर घटाना होगा. इससे आपको सॉफ़्ट नेविगेशन के हिसाब से समय जानने में मदद मिलेगी. उदाहरण के लिए, एलसीपी के लिए:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

कुछ मेट्रिक, आम तौर पर पेज पर हमेशा रिकॉर्ड की जाती हैं. उदाहरण के लिए, एलसीपी में तब तक बदलाव हो सकता है, जब तक कोई इंटरैक्शन नहीं होता. सीएलएस और आईएनपी को तब तक अपडेट किया जा सकता है, जब तक पेज को कहीं और नहीं ले जाया जाता. इसलिए, हर "नेविगेशन" हर नया सॉफ़्ट नेविगेशन होने पर, (इसमें ओरिजनल नेविगेशन भी शामिल है) को पिछले पेज की मेट्रिक को पूरा करना पड़ सकता है. इसका मतलब है कि शुरुआती "हार्ड" नेविगेशन मेट्रिक को सामान्य रूप से पहले ही फ़ाइनल किया जा सकता है.

इसी तरह, अगर लंबे समय तक चलने वाली इन मेट्रिक के नए सॉफ़्ट नेविगेशन की मेट्रिक को मेज़र करना शुरू करना है, तो मेट्रिक को "रीसेट" करना होगा या "फिर से शुरू किया गया" और उसे नई मेट्रिक माना जाता है, जिसमें पिछले "पेज" के लिए सेट की गई वैल्यू की कोई मेमोरी नहीं होती.

नेविगेशन के बीच में एक जैसे रहने वाले कॉन्टेंट के साथ क्या किया जाना चाहिए?

सॉफ़्ट नेविगेशन के लिए एफ़पी, एफ़सीपी, और एलसीपी से सिर्फ़ नए पेंट को मापा जा सकता है. इसकी वजह से एलसीपी अलग हो सकती है. उदाहरण के लिए, उस सॉफ़्ट नेविगेशन के कोल्ड लोड से लेकर सॉफ़्ट लोड तक.

उदाहरण के लिए, ऐसा पेज लें जिसमें एक बड़ी बैनर इमेज हो, जो एलसीपी एलिमेंट हो, लेकिन हर सॉफ़्ट नेविगेशन वाले पेज के नीचे का टेक्स्ट बदलता है. शुरुआती पेज लोड होने पर, बैनर इमेज को एलसीपी एलिमेंट के तौर पर फ़्लैग किया जाएगा और उसी के आधार पर एलसीपी टाइम को आधार बनाया जाएगा. बाद में सॉफ़्ट नेविगेशन के लिए, इसके नीचे दिया गया टेक्स्ट, सॉफ़्ट नेविगेशन के बाद पेंट किया गया सबसे बड़ा एलिमेंट होगा. साथ ही, यह नया एलसीपी एलिमेंट होगा. हालांकि, अगर सॉफ़्ट नेविगेशन यूआरएल में डीप लिंक के साथ नया पेज लोड किया जाता है, तो बैनर इमेज एक नया पेंट होगी. इसलिए, इसे एलसीपी एलिमेंट माना जाएगा.

जैसा कि इस उदाहरण में दिखाया गया है, सॉफ़्ट नेविगेशन के लिए एलसीपी एलिमेंट की रिपोर्ट, अलग-अलग तरीके से की जा सकती है. यह इस बात पर निर्भर करता है कि पेज कैसे लोड होता है—ठीक वैसे ही जैसे पेज के और नीचे ऐंकर लिंक के साथ पेज को लोड करने पर, कोई दूसरा एलसीपी एलिमेंट बन सकता है.

टीटीएफ़बी को कैसे मेज़र करें?

कंवेंशनल पेज लोड के लिए टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी) से पता चलता है कि मूल अनुरोध की पहली बाइट के मिलने में कितना समय लगा.

सॉफ़्ट नेविगेशन के लिए यह ज़्यादा मुश्किल सवाल है. क्या हमें नए पेज के लिए किए गए पहले अनुरोध का आकलन करना चाहिए? अगर ऐप्लिकेशन में सारा कॉन्टेंट पहले से मौजूद है और कोई अन्य अनुरोध नहीं किया गया है, तो क्या होगा? अगर प्रीफ़ेच के ज़रिए पहले से अनुरोध किया जाता है, तो क्या होगा? क्या होगा अगर कोई अनुरोध उपयोगकर्ता के नज़रिए से सॉफ़्ट नेविगेशन से जुड़ा हुआ न हो (उदाहरण के लिए, वह आंकड़ों का अनुरोध)?

सॉफ़्ट नेविगेशन के लिए 0 टीटीएफ़बी को रिपोर्ट करना एक आसान तरीका है. यह ठीक उसी तरह है जैसे हम बैक/फ़ॉरवर्ड कैश मेमोरी को पहले जैसा करने का सुझाव देते हैं. web-vitals लाइब्रेरी, सॉफ़्ट नेविगेशन के लिए इस तरीके का इस्तेमाल करती है.

आने वाले समय में, हम सॉफ़्ट नेविगेशन के "नेविगेशन अनुरोध" के बारे में बेहतर तरीके से जान सकते हैं. इससे हमें यह जानने में मदद मिलेगी कि कौनसा अनुरोध और ज़्यादा सटीक TTFB माप कर पाएंगे. हालांकि, यह मौजूदा एक्सपेरिमेंट का हिस्सा नहीं है.

पुराने और नए, दोनों को कैसे मापें?

इस एक्सपेरिमेंट के दौरान, यह सुझाव दिया जाता है कि आप अपनी वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी को मौजूदा तरीके से मेज़र करते रहें. पेज नेविगेशन का इस्तेमाल किया जा सकता है, ताकि CrUX, कोर वेब वाइटल पहल के आधिकारिक डेटासेट के तौर पर,

इनके अलावा, सॉफ़्ट नेविगेशन को भी मेज़र किया जाना चाहिए. इससे यह पता लगाया जा सकता है कि आने वाले समय में इन्हें कैसे मेज़र किया जा सकता है. साथ ही, इससे आपको Chrome टीम को सुझाव/राय देने या शिकायत करने का मौका मिल सकता है कि यह तरीका कैसे काम करता है. इससे आपको और Chrome टीम को आगे एपीआई को बेहतर बनाने में मदद मिलेगी.

दोनों को मेज़र करने के लिए, आपको उन नए इवेंट की जानकारी होनी चाहिए जो सॉफ़्ट नेविगेशन मोड (उदाहरण के लिए, एक से ज़्यादा एफ़सीपी और अतिरिक्त एलसीपी इवेंट) में जारी किए जा सकते हैं. साथ ही, इन मेट्रिक को सही समय पर फ़ाइनल करके सही तरीके से मैनेज करें. साथ ही, आने वाले समय में सिर्फ़ सॉफ़्ट नेविगेशन पर लागू होने वाले इवेंट को अनदेखा करें.

सॉफ़्ट नेविगेशन की सुविधा के लिए, Core Web Vitals का आकलन करने के लिए, web-vitals लाइब्रेरी का इस्तेमाल करें

सभी बारीकियों को समझने का सबसे आसान तरीका, web-vitals JavaScript लाइब्रेरी का इस्तेमाल करना है, जो सॉफ़्ट नेविगेशन के लिए एक्सपेरिमेंटल सपोर्ट को एक अलग soft-navs branch में उपलब्ध है. यह npm और unpkg पर भी उपलब्ध है. इसे इस तरीके से मेज़र किया जा सकता है (doTraditionalProcessing और doSoftNavProcessing को ज़रूरत के हिसाब से बदलकर):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

पक्का करें कि जैसा कि ऊपर बताया गया है, मेट्रिक की रिपोर्ट सही यूआरएल के हिसाब से की गई हो.

सॉफ़्ट नेविगेशन के लिए, web-vitals लाइब्रेरी में इन मेट्रिक को रिपोर्ट किया जाता है:

मेट्रिक ब्यौरा
टीटीएफ़बी 0 के तौर पर रिपोर्ट किया गया.
एफ़सीपी पेज के लिए सिर्फ़ पहले एफ़सीपी को रिपोर्ट किया जाता है.
एलसीपी सॉफ़्ट नेविगेशन के शुरू होने के समय के मुकाबले, अगले सबसे बड़े कॉन्टेंटफ़ुल पेंट का समय. पिछले नेविगेशन से मौजूद पेंट पर ध्यान नहीं दिया जाएगा. इसलिए, एलसीपी >= 0 होगा. हमेशा की तरह, इसे इंटरैक्शन पर या पेज के बैकग्राउंड में चलने पर रिपोर्ट किया जाएगा. इसके बाद ही एलसीपी को फ़ाइनल किया जा सकेगा.
सीएलएस नेविगेशन के समय के बीच शिफ़्ट की सबसे बड़ी विंडो. हमेशा की तरह, ऐसा जब पेज के बैकग्राउंड में किया गया हो, तब ही सीएलएस को फ़ाइनल किया जा सकता है. अगर कोई बदलाव नहीं होता है, तो वैल्यू को 0 रिपोर्ट किया जाता है.
आईएनपी नेविगेशन के समय के बीच का आईएनपी. हमेशा की तरह, इसे इंटरैक्शन पर रिपोर्ट किया जाएगा या तब ही रिपोर्ट किया जाएगा, जब पेज को बैकग्राउंड में दिखाया जाएगा. इसके बाद ही आईएनपी को फ़ाइनल किया जा सकेगा. इंटरैक्शन न होने पर, 0 वैल्यू रिपोर्ट नहीं की जाती.

क्या ये बदलाव, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाले डेटा में शामिल किए जाएंगे?

सॉफ़्ट नेविगेशन की सुविधा वाला यह एक्सपेरिमेंट बिलकुल वैसा ही है—यह एक एक्सपेरिमेंट है. हम अनुभव से जुड़े डेटा का आकलन करना चाहते हैं. इससे हमें यह तय करने में मदद मिलती है कि उपयोगकर्ता अनुभव को बेहतर तरीके से दिखाया जा रहा है या नहीं. इसके बाद ही हम यह तय करते हैं कि इसे Core Web Vitals पहल में, शामिल किया जाएगा या नहीं. हम इस एक्सपेरिमेंट को लेकर बहुत उत्साहित हैं. हालांकि, हम इस बात की गारंटी नहीं दे सकते कि यह मौजूदा मेज़रमेंट की जगह लेगा या नहीं.

हम वेब डेवलपर को अहमियत देते हैं और इस्तेमाल किए गए अनुभव के बारे में आपके सुझाव, राय या शिकायत. सुझाव देने के लिए, सॉफ़्ट नेविगेशन GitHub रिपॉज़िटरी सबसे अच्छी जगह है. हालांकि, Chrome के लागू करने से जुड़ी अलग-अलग गड़बड़ियों के बारे में Chrome से जुड़ी समस्या को ट्रैक करने वाले टूल में बताया जाना चाहिए.

CrUX में, सॉफ़्ट नेविगेशन की रिपोर्ट कैसे दी जाएगी?

यह भी तय किया जाना बाकी है कि CrUX में, सॉफ़्ट नेविगेशन को किस तरह रिपोर्ट किया जाएगा. यह ज़रूरी नहीं है कि उन्हें मौजूदा "कठिन" ही माना जाएगा नेविगेशन का इस्तेमाल किया जाता है.

उपयोगकर्ताओं के सवाल के हिसाब से, कुछ वेब पेजों में पूरे पेज लोड की तरह ही सॉफ़्ट नेविगेशन होते हैं. साथ ही, सिंगल पेज ऐप्लिकेशन टेक्नोलॉजी का इस्तेमाल सिर्फ़ इन्हें लागू करने की जानकारी के तौर पर होता है. अन्य मामलों में, उनका कॉन्टेंट कुछ हद तक अतिरिक्त कॉन्टेंट से मिलता-जुलता हो सकता है.

इसलिए, हो सकता है कि हम इन सॉफ़्ट नेविगेशन को CrUX में अलग से रिपोर्ट करें. इसके अलावा, किसी पेज या पेजों के ग्रुप की वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी का हिसाब लगाते समय, हम इन सॉफ़्ट नेविगेशन को अलग से रिपोर्ट कर सकते हैं. ऐसा हो सकता है कि हम आंशिक रूप से लोड होने वाले सॉफ़्ट नेविगेशन वाले विज्ञापनों को पूरी तरह से बाहर कर पाएं. ऐसा इसलिए, क्योंकि इस क्षेत्र में इस बदलाव के नए तरीके उपलब्ध हैं.

टीम अनुभव के आधार पर और तकनीकी चीज़ों को लागू करने पर ध्यान दे रही है. इससे हमें इस प्रयोग की सफलता का आकलन करने में मदद मिलेगी, इसलिए इन पहलुओं पर कोई फ़ैसला नहीं लिया गया है.

सुझाव/राय दें या शिकायत करें

हम इन जगहों पर, इस एक्सपेरिमेंट के बारे में लगातार सुझाव मांग रहे हैं:

बदलावों का लॉग

इस एपीआई पर एक्सपेरिमेंट किया जा रहा है. इसलिए, इसमें कई बदलाव हो रहे हैं. ये बदलाव, स्टेबल एपीआई के मुकाबले काफ़ी ज़्यादा हैं. ज़्यादा जानकारी के लिए, सॉफ़्ट नेविगेशन हेयुरिस्टिक्स चेंजलॉग देखें.

नतीजा

सॉफ़्ट नेविगेशन एक्सपेरिमेंट, एक दिलचस्प तरीका है. इससे Core Web Vitals पहल के बारे में पता चलता है, ताकि आधुनिक वेब पर उस सामान्य पैटर्न को मेज़र किया जा सके जो हमारी मेट्रिक में मौजूद नहीं है. फ़िलहाल, यह एक्सपेरिमेंट शुरुआती दौर में है और इसमें अभी बहुत कुछ बाकी है. हालांकि, इसे अब तक बड़ी वेब कम्यूनिटी के लिए उपलब्ध कराना एक अहम कदम है. इस एक्सपेरिमेंट से सुझाव, शिकायत या राय इकट्ठा करना, इस एक्सपेरिमेंट का एक और अहम हिस्सा है. इसलिए, हमारा सुझाव है कि इस एक्सपेरिमेंट में दिलचस्पी रखने वाले लोग इस मौके का इस्तेमाल करके, एपीआई को बेहतर बनाने में मदद करें. इससे यह पक्का किया जा सकेगा कि एआई की मदद से हम क्या मेज़र कर सकते हैं.

स्वीकार की गई

Unस्प्लैश पर जॉर्डन मैड्रिड की थंबनेल इमेज