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

Barry Pollard

Michal Mocny

पब्लिश करने की तारीख: 1 फ़रवरी, 2023, पिछली बार अपडेट किए जाने की तारीख: 20 सितंबर, 2026

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

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

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

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

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

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

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

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

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

सॉफ़्ट नेविगेशन के लिए DevTools की सहायता

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

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

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

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

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

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

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

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

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

सॉफ़्ट नेविगेशन के लिए मेट्रिक को मेज़र करने के तरीके के बारे में ज़्यादा जानने के लिए, हर सॉफ़्ट नेविगेशन के लिए Core Web Vitals को मेज़र करने वाला सेक्शन देखें.

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

सॉफ़्ट नेविगेशन की सुविधा, Chrome 151 से डिफ़ॉल्ट रूप से चालू है.

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

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

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

इसके अलावा, यह तरीका भी अपनाया जा सकता है:

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

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

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

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

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

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

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

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

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

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

इसे हर soft-navigation एंट्री के तौर पर सेट किया जाना चाहिए. साथ ही, अगली soft-navigation एंट्री मिलने तक, मेट्रिक की रिपोर्ट करने के लिए इस्तेमाल किया जाना चाहिए.

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 एंट्री के getLargestInteractionContentfulPaint() फ़ंक्शन को पहले प्रोसेस करना चाहिए, ताकि soft-navigation entries के उत्सर्जित होने से पहले हुई interaction-contentful-paint एंट्री को मैनेज किया जा सके.

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

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

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

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

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

Core Web Vitals को मेज़र करने के लिए, soft-navigation एंट्री को सुनें. इन्हें पाने पर, मेट्रिक को रीसेट करें. presentationTime के आधार पर, एफ़सीपी को एमिट किया जा सकता है. साथ ही, एलसीपी को getLargestInteractionContentfulPaint() एंट्री के लिए शुरू किया जा सकता है. आईएनपी और सीएलएस को 0 पर शुरू किया जाना चाहिए, जैसा कि पेज लोड होने पर होता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

क्या आपको दोनों तरीकों से Core Web Vitals को मापना चाहिए?

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

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

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

इसके बाद, विश्लेषण के लिए मेट्रिक को दो बार बीकन और स्टोर करना होगा.

सॉफ़्ट नेविगेशन के लिए, Core Web Vitals को मेज़र करने के लिए web-vitals लाइब्रेरी का इस्तेमाल करें

सभी बारीकियों को ध्यान में रखने का सबसे आसान तरीका, web-vitals JavaScript लाइब्रेरी का इस्तेमाल करना है. इसमें v6.0.0 से सॉफ़्ट नेविगेशन की सुविधा काम करती है. इसे इस तरह से मेज़र किया जा सकता है (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 की मेट्रिक का हिस्सा बन जाएंगे?

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

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

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

अन्य ब्राउज़र में सॉफ़्ट नेविगेशन को कैसे मैनेज करें?

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

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

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

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

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

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

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

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

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

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

नतीजा

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

Acknowledgements

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

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