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

Barry Pollard

Michal Mocny

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

मार्च 2026 का अपडेट: सॉफ़्ट नेविगेशन का नया ऑरिजिन ट्रायल Chrome 147 से शुरू होगा. उम्मीद है कि यह आखिरी ऑरिजिन ट्रायल होगा. डेवलपर, Chrome 147 में जाकर chrome://flags/#soft-navigation-heuristics को चालू करके भी इस सुविधा को आज़मा सकते हैं.

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

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

सॉफ़्ट नेविगेशन के हिसाब से, Core Web Vitals को मेज़र करना

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

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

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

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

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

नेविगेशन के बीच एक जैसा रहने वाला कॉन्टेंट कैसे मैनेज किया जाना चाहिए?

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

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

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

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

अहम जानकारी:: आरयूएम डेटा इकट्ठा करते समय, आपको navigationType को शामिल करना चाहिए. इससे एलसीपी (साथ ही, आईएनपी और सीएलएस) को सॉफ्ट नेविगेशन के लिए अलग-अलग सेगमेंट में बांटा जा सकता है. ऐसा इसलिए, क्योंकि इनकी विशेषताएं अलग-अलग हो सकती हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

हम इस एपीआई के बारे में यहां सुझाव/राय मांग रहे हैं:

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

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

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

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

नतीजा

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

Acknowledgements

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

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