Chrome 147 में, फ़ाइनल सॉफ़्ट नेविगेशन का ऑरिजिन ट्रायल शुरू हो रहा है

Barry Pollard

Michal Mocny

पब्लिश होने की तारीख: 20 अप्रैल, 2026

Chrome, इस साल के आखिर तक Soft Navigations API को शिप करने का प्लान बना रहा है. हम पहले इस API को आज़मा चुके हैं. इसके लिए, हम Chrome 147 से लेकर Chrome 149 तक एक और ऑरिजिन ट्रायल ऑफ़र कर रहे हैं. इस ट्रायल में, पिछले ट्रायल से मिले सुझाव/राय को शामिल किया गया है. इससे एपीआई को बेहतर बनाने में मदद मिलेगी. हम इस सुविधा में दिलचस्पी रखने वाले वेबसाइट मालिकों को यह सुझाव देते हैं कि वे एपीआई के रिलीज़ होने से पहले, उसके फ़ाइनल वर्शन का आखिरी टेस्ट कर लें.

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

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

सॉफ़्ट नेविगेशन एपीआई की ज़रूरत

Soft Navigations API, सॉफ्ट नेविगेशन का पता लगाने के लिए सुझाया गया एक एपीआई है. इसका इस्तेमाल सिंगल पेज ऐप्लिकेशन (एसपीए) साइटें करती हैं. सॉफ़्ट नेविगेशन के लिए, पेज पर नेविगेट नहीं किया जाता है. इसलिए, JavaScript को मैन्युअल तरीके से कुछ ऐसी कार्रवाइयां मैनेज करनी होती हैं जो आम तौर पर नेविगेशन के लिए होती हैं. मौजूदा एपीआई की मदद से, नेविगेशन के इतिहास को मैनेज करने जैसी कुछ कार्रवाइयां की जा सकती हैं. हालांकि, इन नेविगेशन के लिए अन्य कार्रवाइयां नहीं की जा सकतीं. जैसे, वेबसाइट की परफ़ॉर्मेंस की मेट्रिक मेज़र करना.

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

वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी और एसपीए

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

JavaScript फ़्रेमवर्क, एसपीए के लिए वेबसाइट की परफ़ॉर्मेंस की कुछ मेट्रिक को मेज़र कर सकते हैं. खास तौर पर, पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी) और लेआउट शिफ़्ट (सीएलएस), प्रिमिटिव पर आधारित होते हैं. जैसे, Event Timing API और Layout Instability API. इन प्रिमिटिव को किसी भी समयावधि में मेज़र किया जा सकता है, ताकि इन मेट्रिक का हिसाब लगाया जा सके. हालांकि, सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय (एलसीपी) जैसी अन्य मेट्रिक सिर्फ़ ब्राउज़र से मिलती हैं. ये मेट्रिक, पेज नेविगेशन के आधार पर तय होती हैं और उपयोगकर्ता के इंटरैक्शन के बाद फ़ाइनल होती हैं.

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

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

• यह एक SoftNavigationEntry एंट्री है. यह तब दिखती है, जब सॉफ्ट नेविगेशन से जुड़ी सभी ज़रूरी शर्तें पूरी हो जाती हैं. इसमें, सॉफ्ट नेविगेशन की वजह बनने वाले इंटरैक्शन के लिए interactionId, एक यूनीक navigationId, और नए यूआरएल पर सेट किया गया name शामिल है. साथ ही, इसमें पेंट करने के अलग-अलग समय शामिल हैं. इनका इस्तेमाल, सॉफ्ट नेविगेशन के पहले कॉन्टेंटफ़ुल पेंट को मेज़र करने के लिए किया जा सकता है.
• एक InteractionContentfulPaint एंट्री, जो इंटरैक्शन के बाद कई, ज़्यादा साइज़ वाले कॉन्टेंटफ़ुल पेंट को मेज़र करने की अनुमति देती है, ताकि सॉफ्ट नेविगेशन के लिए एलसीपी को मेज़र किया जा सके.

इन नई एंट्री को PerformanceObserver का इस्तेमाल करके देखा जा सकता है. इसके लिए, soft-navigation और interaction-contentful-paint टाइप का इस्तेमाल करें.

एपीआई, largest-contentful-paint, interaction-contentful-paint, event-timing, और layout-shift परफ़ॉर्मेंस एंट्री (और अन्य) में भी बदलाव करता है, ताकि उनमें एक आइडेंटिफ़ायर, navigationId शामिल किया जा सके. यह आइडेंटिफ़ायर, उस नेविगेशन को दिखाता है जिसके लिए एंट्री की गई है. PerformanceObserver, पेज के आइडल होने तक परफ़ॉर्मेंस एंट्री को मॉनिटर नहीं करते हैं. इसलिए, परफ़ॉर्मेंस एंट्री बनाने वाले इवेंट और उसे मॉनिटर करने के बीच कुछ समय लग सकता है. ऐसा खास तौर पर तब होता है, जब पेज पर बहुत ज़्यादा गतिविधि हो रही हो. जैसे, सॉफ़्ट नेविगेशन के दौरान. navigationId वैल्यू से, एंट्री को सही नेविगेशन में एट्रिब्यूट करने में मदद मिलती है.

कुछ interaction-contentful-paint एंट्री, नेविगेशन से पहले और कुछ बाद में हो सकती हैं. सॉफ़्ट नेविगेशन की वजह से होने वाले सभी पेंट को ट्रैक करने के बजाय, soft-navigation एंट्री में largestInteractionContentfulPaint एंट्री शामिल होती है. यह अब तक का सबसे बड़ा पेंट होता है.

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

• LCP: पेज के शुरुआती लोड के लिए largest-contentful-paint का इस्तेमाल किया जाता है. साथ ही, सॉफ्ट नेविगेशन के लिए नई interaction-contentful-paint और soft-navigation एंट्री का इस्तेमाल किया जाता है.
• CLS: सॉफ़्ट नेविगेशन के लिए, soft-navigation एंट्री के आधार पर layout-shift एंट्री का इस्तेमाल करना और उन्हें स्लाइस करना.
• आईएनपी: सॉफ़्ट नेविगेशन के लिए, soft-navigation एंट्री के आधार पर event एंट्री का इस्तेमाल करना और उन्हें स्लाइस करना.
• FCP: शुरुआती पेज लोड के लिए first-contentful-paint का इस्तेमाल करना. साथ ही, सॉफ़्ट नेविगेशन के लिए नई soft-navigation एंट्री पर पेंट टाइमिंग की जानकारी देना.

ज़्यादा जानकारी के लिए, सॉफ़्ट नेविगेशन का दस्तावेज़ देखें.

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

Soft Navigation API, इन स्थितियों में सॉफ्ट नेविगेशन को ट्रिगर करता है:

• उपयोगकर्ता का इंटरैक्शन होता है,
• … जिससे उपयोगकर्ता को कॉन्टेंट दिखता है,
• … और यूआरएल अपडेट हो जाता है.

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

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

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

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

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

सॉफ़्ट नेविगेशन एपीआई की जांच करने के लिए मदद चाहिए

हमें Soft Navigations API को टेस्ट करने में आपकी मदद चाहिए. साथ ही, हमें यह पता लगाना है कि यह आपकी उम्मीदों के मुताबिक काम करता है या नहीं. क्या एपीआई, सॉफ्ट नेविगेशन के होने पर उनकी रिपोर्ट नहीं करता है? इसके उलट, क्या एपीआई उन नेविगेशन को भी रिपोर्ट करता है जिन्हें नेविगेशन नहीं माना जाता?

पिछले ऑरिजिन ट्रायल के बाद से क्या बदलाव हुए हैं

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

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

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

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

जांच करने का तरीका

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

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

इसके अलावा, web-vitals लाइब्रेरी का एक्सपेरिमेंटल सॉफ़्ट नेविगेशन वर्शन, GitHub और npm पर उपलब्ध है.

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

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

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