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

Barry Pollard

Michal Mocny

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

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

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

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

सॉफ़्ट नेविगेशन की 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, दोनों एंट्री पर विचार किया जाएगा.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नतीजा

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

Acknowledgements

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

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