इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

Barry Pollard

Yoav Weiss

अगस्त 2024 का अपडेट: सॉफ़्ट नेविगेशन के ऑरिजिन ट्रायल का दूसरा चरण 29 मई को खत्म हो गया. Chrome की टीम, एक्सपेरिमेंट के सुझावों और राय की समीक्षा कर रही है. साथ ही, इस एपीआई के लिए अगले कदमों पर विचार कर रही है. हम सटीक जानकारी से जुड़ी कुछ समस्याओं को हल करना चाहते हैं. साथ ही, हमें लगता है कि इस सुविधा को आगे बढ़ाने से पहले, एक और ऑरिजिन ट्रायल की ज़रूरत होगी. इस दौरान, डेवलपर chrome://flags/#enable-experimental-web-platform-features को चालू करके, इस सुविधा को आज़मा सकते हैं.

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

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

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

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

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

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

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

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

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

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

हर बार सॉफ्ट नेविगेशन का पता चलने के बाद, soft-navigation PerformanceTiming इवेंट उत्सर्जित किया जाएगा.
परफ़ॉर्मेंस एपीआई, soft-navigation PerformanceTiming इवेंट से उत्सर्जित soft-navigation टाइमिंग एंट्री का ऐक्सेस देगा.
फ़र्स्ट पेंट (FP), फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी), सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय (एलसीपी) मेट्रिक को रीसेट कर दिया जाएगा. साथ ही, इनकी अगली बार सही तरीके से होने पर इन्हें फिर से भेजा जाएगा. (ध्यान दें: FP और FCP लागू नहीं किए गए हैं.)
परफ़ॉर्मेंस के हर समय (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event, और layout-shift) में navigationId एट्रिब्यूट जोड़ा जाएगा. यह एट्रिब्यूट, उस नेविगेशन एंट्री से जुड़ा होगा जिससे इवेंट जुड़ा था. इससे कुल लेआउट शिफ़्ट (सीएलएस) और इंटरैक्शन टू नेक्स्ट पेंट (आईएनपी) का हिसाब लगाया जा सकेगा.

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

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

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

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

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

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

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

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

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

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

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

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

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

सॉफ़्ट नेविगेशन के लिए हेयुरिस्टिक्स और स्टैंडर्डाइज़ेशन.
उन हेयुरिस्टिक्स के Chrome में लागू करने से जुड़ी समस्याएं.
वेबसाइट की परफ़ॉर्मेंस की जानकारी से जुड़े सामान्य सुझाव, शिकायत या राय देने के लिए, web-vitals-feedback@googlegroups.com पर संपर्क करें.

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

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

नतीजा

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

धन्यवाद

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