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

Barry Pollard

Michal Mocny

पब्लिश करने की तारीख: 1 फ़रवरी, 2023, पिछली बार अपडेट करने की तारीख: 30 मार्च, 2026

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

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

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

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

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

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

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

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

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

सॉफ़्ट नेविगेशन के लिए DevTools की सुविधा

हमने DevTools के परफ़ॉर्मेंस पैनल के ट्रेस व्यू में, सॉफ्ट नेविगेशन के लिए सहायता जोड़ी है:

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

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

Chrome, वेब डेवलपर के लिए सॉफ्ट नेविगेशन कैसे लागू करता है?

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

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

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

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

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

• soft-navigation एंट्री को मॉनिटर करने से, परफ़ॉर्मेंस एंट्री को हर "नेविगेशन" में "स्लाइस" किया जा सकता है.
• सीएलएस और आईएनपी मेट्रिक को पहले से ही अपनी ज़रूरत के हिसाब से स्लाइस किया जा सकता है. इन्हें पूरे पेज के लाइफ़साइकल के दौरान मेज़र करने के बजाय, अपनी ज़रूरत के हिसाब से मेज़र किया जा सकता है. हालांकि, Soft Navigation API से यह पता चलता है कि ऐसा कब होता है. इससे कोई फ़र्क़ नहीं पड़ता कि इस्तेमाल की गई टेक्नोलॉजी कौनसी है.
• largest-contentful-paint एंट्री, इंटरैक्शन के आधार पर तय की जाती है. इंटरैक्शन, सॉफ्ट नेविगेशन शुरू करने के लिए ज़रूरी है. इसलिए, इसका इस्तेमाल सिर्फ़ शुरुआती "हार्ड" नेविगेशन एलसीपी को मेज़र करने के लिए किया जा सकता है. इसका मतलब है कि सॉफ्ट नेविगेशन को मेज़र करते समय, इसमें कोई बदलाव नहीं होगा. इसलिए, शुरुआती हार्ड नेविगेशन के लिए एलसीपी को हमेशा की तरह मेज़र किया जा सकता है.
• इंटरैक्शन से निकलने वाली नई interaction-contentful-paint एंट्री का इस्तेमाल, सॉफ्ट नेविगेशन के लिए एलसीपी को मेज़र करने के लिए किया जा सकता है. हालांकि, इस एंट्री का इस्तेमाल करने के लिए कुछ बातों का ध्यान रखना होता है. इनके बारे में हम इस लेख में बताएंगे.
• ध्यान दें कि सभी उपयोगकर्ता इस सॉफ्ट नेविगेशन एपीआई का इस्तेमाल नहीं कर पाएंगे. खास तौर पर, Chrome के पुराने वर्शन और अन्य ब्राउज़र का इस्तेमाल करने वाले लोग. ध्यान रखें कि कुछ उपयोगकर्ता, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने वाली मेट्रिक की रिपोर्ट करने के बावजूद, सॉफ्ट नेविगेशन पर आधारित मेट्रिक की रिपोर्ट नहीं कर सकते.
• यह सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है और डिफ़ॉल्ट रूप से चालू नहीं होती. इसलिए, साइटों को इस सुविधा को आज़माना चाहिए, ताकि वे इसके अनचाहे साइड इफ़ेक्ट के बारे में जान सकें.

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

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

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

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

डेवलपर के लिए, chrome://flags/#soft-navigation-heuristics पर मौजूद फ़्लैग को चालू करके इस सुविधा को चालू किया जा सकता है. इसके अलावा, Chrome लॉन्च करते समय --enable-features=SoftNavigationHeuristics कमांड लाइन आर्ग्युमेंट का इस्तेमाल करके भी इसे चालू किया जा सकता है. chrome://flags/#enable-experimental-web-platform-features फ़्लैग को चालू करने से, सॉफ्ट नेविगेशन भी चालू हो जाते हैं.

अगर किसी वेबसाइट को यह सुविधा सभी लोगों के लिए चालू करनी है, तो Chrome 147 से एक ओरिजिन ट्रायल शुरू होगा. इस ट्रायल के लिए साइन अप करके, इसे चालू किया जा सकता है. इसके अलावा, एचटीएमएल या एचटीटीपी हेडर में ओरिजिन ट्रायल टोकन के साथ एक मेटा एलिमेंट शामिल करके भी इसे चालू किया जा सकता है. ज़्यादा जानकारी के लिए, ऑरिजिन ट्रायल का इस्तेमाल शुरू करना पोस्ट देखें.

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

सॉफ़्ट नेविगेशन एपीआई के साथ काम करने की सुविधा का पता लगाना

यह जांच करने के लिए कि एपीआई काम करता है या नहीं, यहां दिया गया कोड इस्तेमाल करें:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

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

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

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

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

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

सॉफ़्ट नेविगेशन की रिपोर्ट करना

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

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

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

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

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

सही soft-navigation एंट्री के name एट्रिब्यूट में, मेट्रिक रिपोर्ट करने के लिए नया यूआरएल शामिल होगा. साथ ही, 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;

interaction-contentful-paint के लिए सही यूआरएल की शिकायत करें

interaction-contentful-paint एंट्री से एलसीपी का हिसाब लगाने के लिए, कुछ और बातों का ध्यान रखना ज़रूरी है. ऐसा इसलिए, क्योंकि सभी interaction-contentful-paint एंट्री को navigationId का इस्तेमाल करके मैप नहीं किया जाना चाहिए. साथ ही, उस यूआरएल के लिए एलसीपी के तौर पर रिपोर्ट नहीं किया जाना चाहिए:

• पहली समस्या यह है कि अगर यूआरएल अपडेट होने से पहले पेंट होता है, तो interaction-contentful-paint एंट्री, सॉफ़्ट नेविगेशन से पहले ही दिख सकती हैं. ऐसे मामलों में, navigationId पुराने यूआरएल के लिए होगा. अगर यूआरएल को पहले अपडेट किया जाता है, तो पेंट, सॉफ़्ट नेविगेशन को पूरा करेगा. ऐसे में, soft-navigation एंट्री पहले दिखेगी और interaction-contentful-paint में नया यूआरएल होगा.
• दूसरी समस्या यह है कि interaction-contentful-paint, नई इंटरैक्शन के लिए एंट्री जारी रहेंगी. ऐसा इसलिए, क्योंकि इस परफ़ॉर्मेंस मेट्रिक का दायरा, सॉफ्ट नेविगेशन के लिए सिर्फ़ एलसीपी से आगे तक फैला हुआ है. हमें एलसीपी के लिए, सिर्फ़ सॉफ्ट नेविगेशन लोड के पेंट को शामिल करना है. इसके बाद के इंटरैक्शन के पेंट को शामिल नहीं करना है.

इसलिए, सही यूआरएल पाने के लिए, interaction-contentful-paint एंट्री को soft-navigation-entries से मैप करने के लिए, navigationId के बजाय interactionId का इस्तेमाल किया जाना चाहिए. इससे पुरानी navigationId वाली सभी एंट्री मैनेज हो जाएंगी. साथ ही, ऐसी interaction-contentful-paint एंट्री फ़िल्टर हो जाएंगी जिन्हें एलसीपी के लिए नहीं माना जाना चाहिए.

इसके अलावा, आपको soft-navigation एंट्री की largestInteractionContentfulPaint एंट्री को भी प्रोसेस करना चाहिए, ताकि soft-navigation entries के चालू होने से पहले होने वाली interaction-contentful-paint एंट्री को आसानी से मैनेज किया जा सके.

सॉफ्ट नेविगेशन की startTime को पाना

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

नेविगेशन शुरू होने का समय भी इसी तरह से पता लगाया जा सकता है. इसके लिए, सही soft-navigation एंट्री को मैप करें और उसके startTime का इस्तेमाल करें.

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

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

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

इसके बाद, एलसीपी, आईएनपी, और सीएलएस को सामान्य तरीके से मेज़र और मॉनिटर किया जा सकता है. हालांकि, एलसीपी के लिए interaction-contentful-paint का इस्तेमाल नहीं किया जा सकता, क्योंकि interactionId मैच होते हैं. interactionId और navigationId का इस्तेमाल, यूआरएल की एंट्री के नाम रखने के लिए किया जा सकता है. इसके बारे में पहले बताया जा चुका है.

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

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

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

नेविगेशन के दौरान, एक जैसा कॉन्टेंट कैसे दिखाया जाना चाहिए?

सॉफ़्ट नेविगेशन के लिए एलसीपी (interaction-contentful-paint से कैलकुलेट किया गया) सिर्फ़ नए पेंट को मेज़र करेगा. साथ ही, सिर्फ़ उन पेंट को मेज़र करेगा जो नेविगेशन की वजह से हुए इंटरैक्शन से जुड़े हैं. इससे एलसीपी अलग हो सकता है. उदाहरण के लिए, उस सॉफ़्ट नेविगेशन के कोल्ड लोड से सॉफ़्ट लोड तक.

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

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

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

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

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

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

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

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

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

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

एलसीपी के लिए, इसका मतलब है कि मौजूदा तरीके के लिए सिर्फ़ largest-contentful-paint एंट्री और नए तरीके के लिए largest-contentful-paint और interaction-contentful-paint, दोनों एंट्री पर विचार किया जाएगा.

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

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

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

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 लाइब्रेरी यह भी पक्का करती है कि मेट्रिक को सही यूआरएल के हिसाब से रिपोर्ट किया गया हो. जैसा कि पहले बताया गया है, ऐसा इसलिए होता है, क्योंकि ये लाइब्रेरी, कॉलबैक को दी गई एंट्री में navigationId और navigationURL, दोनों को शामिल करती हैं.

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

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

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

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

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

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

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

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

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

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

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

• एपीआई के बारे में सुझाव/राय देने या शिकायत करने के लिए, GitHub पर समस्याएं सबमिट करें.
• अगर Chromium को लागू करने से जुड़ी कोई समस्या है, तो Chrome के इश्यू ट्रैकर पर इसकी शिकायत करें. हालांकि, ऐसा तब करें, जब यह समस्या पहले से मौजूद समस्याओं में शामिल न हो.
• वेब वाइटल्स के बारे में सामान्य सुझाव, शिकायत या राय web-vitals-feedback@googlegroups.com पर शेयर की जा सकती है.

अगर आपको कोई समस्या आ रही है, तो ज़्यादा परेशान न हों. हमें किसी भी जगह पर सुझाव/राय दें या शिकायत करें. हम दोनों जगहों पर समस्याओं को प्राथमिकता देंगे और उन्हें सही जगह पर भेजेंगे.

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

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

नतीजा

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

Acknowledgements

Unsplash पर जॉर्डन मैड्रिड ने थंबनेल इमेज बनाई है

यह काम, Yoav Weiss ने Google में काम करते समय शुरू किया था. हम इस एपीआई पर काम करने के लिए योआव का धन्यवाद करते हैं.