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

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

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

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

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

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

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

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

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

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

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

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

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

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

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

  • सॉफ़्ट नेविगेशन के लिए, अतिरिक्त FP, FCP, और LCP इवेंट फिर से भेजे जा सकते हैं. 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 की टीम को आने वाले समय में एपीआई को बेहतर बनाने में मदद मिलेगी.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नतीजा

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

स्वीकार की गई

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