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

Barry Pollard

Michal Mocny

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

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

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

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

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

हमने डेवलपर के सुझावों के आधार पर, इस प्रस्ताव में कई सुधार किए हैं. हमारा लक्ष्य, Chrome 151 से दो नए परफ़ॉर्मेंस एपीआई उपलब्ध कराना है, ताकि इस समस्या को हल किया जा सके.

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

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

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

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

सॉफ़्ट नेविगेशन के लिए 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 को भी FCP के तौर पर शामिल किया जाएगा.
• ध्यान दें कि आगे की इंटरैक्शन के बाद भी interaction-contentful-paint एंट्री जनरेट होंगी. हालांकि, किसी यूआरएल के लिए एलसीपी को interaction-contentful-paint एंट्री तक सीमित रखना चाहिए. ये एंट्री, सॉफ्ट नेविगेशन interactionId से मेल खाती हैं. ऐसा इसलिए, ताकि इन एंट्री को शामिल न किया जा सके. साथ ही, ऐसा सिर्फ़ उस यूआरएल के largestContentfulPaint प्रॉपर्टी के लिए किया जा सके.

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

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

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

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

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

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

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

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

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

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

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

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

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 });

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

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

सॉफ़्ट नेविगेशन दिखने पर, पिछले पेज की 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 एंट्री सुनें. साथ ही, इन्हें पाने पर मेट्रिक रीसेट करें. FCP को presentationTime के आधार पर ट्रिगर किया जा सकता है. साथ ही, LCP को 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, दोनों एंट्री पर विचार किया जाएगा.

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

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

सॉफ़्ट नेविगेशन के लिए, web-vitals लाइब्रेरी का इस्तेमाल करके Core 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 पर जाएं.

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

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

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

नतीजा

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

Acknowledgements

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

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