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

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 लाइब्रेरी, सॉफ़्ट नेविगेशन के लिए इस तरीके का इस्तेमाल करती है.

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

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

इस एक्सपेरिमेंट के दौरान, यह सुझाव दिया जाता है कि आप अपनी वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी को मौजूदा समय में मेज़र करते रहें. इसके लिए, "हार्ड" पेज नेविगेशन का इस्तेमाल करें, ताकि 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 रिपोर्ट किया जाता है.
आईएनपी नेविगेशन के समय के बीच का INP. आम तौर पर, किसी इंटरैक्शन या पेज के बैकग्राउंड में होने पर इसकी रिपोर्ट की जाएगी. ऐसा इसलिए, क्योंकि सिर्फ़ तब ही आईएनपी को फ़ाइनल किया जा सकता है. अगर कोई इंटरैक्शन नहीं होता है, तो 0 वैल्यू रिपोर्ट नहीं की जाती.

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

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

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

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

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

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

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

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

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

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

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

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

नतीजा

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

धन्यवाद

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