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

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नतीजा

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

आभार

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