Chrome 151 का Soft Navigations API आखिरकार सिंगल-पेज ऐप्स (SPAs) को हर इन-ऐप नेविगेशन के लिए Core Web Vitals रिपोर्ट करने की सुविधा देता है, लेकिन Google का CrUX डेटासेट अभी भी केवल पहले हार्ड लोड को ही रिकॉर्ड करता है, जिससे डेवलपर्स के पास परफॉरमेंस की दो अलग-अलग तस्वीरें रह जाती हैं।

SPA मेट्रिक्स पीछे क्यों रह गए हैं

Core Web Vitals—Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) और Cumulative Layout Shift (CLS)—hard navigations के इर्द-गिर्द परिभाषित किए गए थे। एक हार्ड नेविगेशन एक बिल्कुल नया डॉक्यूमेंट फेच करता है और पिछले पेज की स्टेट (state) को हटा देता है।

React, Vue, Next.js, या इसी तरह के फ्रेमवर्क के साथ बने SPAs शायद ही कभी हार्ड नेविगेशन ट्रिगर करते हैं। किसी लिंक पर क्लिक करने से History API के माध्यम से URL अपडेट हो जाता है, बैकग्राउंड में डेटा फेच किया जाता है, और बिना फुल रीलोड के कंटेंट बदल दिया जाता है। मौजूदा Performance API केवल शुरुआती पेज लोड को ही कैप्चर करता है, इसलिए LCP और INP उस लेटेंसी को कभी नहीं देख पाते जो यूजर्स को एक रूट से दूसरे रूट पर जाने पर महसूस होती है।

यह ब्लाइंड स्पॉट उन डैशबोर्ड्स को प्रभावित करता है जो Performance Timeline या Google के Chrome User Experience Report (CrUX) से डेटा निकालते हैं। वे अक्सर "शेल" पेज के लिए एक बेहतरीन LCP दिखाते हैं, जबकि ऐप के अंदर होने वाले धीमे लोड को नजरअंदाज कर देते हैं, जिससे परफॉरमेंस हेल्थ का एक गलत अहसास होता है।

Chrome का Soft Navigations API

Chrome 151 ने Soft Navigations API पेश किया है, जो ह्यूरिस्टिक्स (heuristics) का एक सेट है जो कुछ SPA इंटरैक्शन को वास्तविक नेविगेशन के रूप में मानता है। यह API तीन संकेतों पर नज़र रखता है:

  • एक यूजर-इनिशिएटेड इंटरैक्शन (क्लिक, टैप, कीबोर्ड इवेंट)
  • History API के माध्यम से URL में बदलाव
  • नए कंटेंट को रेंडर करने वाले बाद के पेंट इवेंट्स (paint events)

जब ये तीनों मेल खाते हैं, तो Chrome Performance Timeline में एक soft navigation लॉग करता है, और Core Web Vitals की गणना भी उसी तरह की जाती है जैसे हार्ड नेविगेशन के लिए की जाती है। ओपन-सोर्स web-vitals लाइब्रेरी ने 21 जुलाई को इसका सपोर्ट जोड़ दिया है, ताकि डेवलपर्स उसी API का उपयोग करके इन नंबरों को निकालना शुरू कर सकें जिसका वे पहले से उपयोग कर रहे हैं।

व्यवहार में, अब आप प्रत्येक रूट परिवर्तन के लिए एक LCP वैल्यू, एक INP जो पिछले यूजर इनपुट की वास्तविक लेटेंसी को दर्शाता है, और एक CLS जो सॉफ्ट नेविगेशन के बाद लेआउट शिफ्ट को कैप्चर करता है, देख सकते हैं।

डेटा का विभाजन: Chrome बनाम CrUX

Google का CrUX (Chrome User Experience Report) PageSpeed Insights, Search Console और परोक्ष रूप से रैंकिंग सिग्नल्स को शक्ति प्रदान करता है। CrUX अभी भी केवल हार्ड-नेविगेशन डेटा को ही एकत्रित करता है।

परिणामस्वरूप, आपके पास दो सुसंगत लेकिन अलग-अलग डेटा स्ट्रीम होती हैं:

  • इंटरनल टूल्स जो Performance Timeline को पढ़ते हैं, वे अब रूट-लेवल LCP, INP और CLS दिखाते हैं, जो एक SPA में यूजर्स के अनुभव का वास्तविक दृश्य प्रदान करते हैं।
  • Google के पब्लिक डेटासेट्स केवल पहले पेज लोड के मेट्रिक्स दिखाना जारी रखते हैं, जो Search Console रिपोर्ट करता है और जिसे Google के रैंकिंग एल्गोरिदम संदर्भ (reference) के रूप में उपयोग करते हैं।

दोनों सही हैं; वे बस अलग-अलग क्षणों को मापते हैं। केवल Search Console पर भरोसा करने से उन परफॉरमेंस रिग्रेशन (regressions) का पता नहीं चल पाएगा जो शुरुआती लोड के बाद होते हैं, जबकि केवल इंटरनल डैशबोर्ड Google द्वारा SEO के लिए उपयोग किए जाने वाले बेसलाइन को नहीं दर्शाएंगे।

डेवलपर्स को किन बातों का ध्यान रखना चाहिए

  • ब्राउज़र सपोर्ट – Soft Navigations API आज केवल Chromium-आधारित ब्राउज़रों में उपलब्ध है। Safari और Firefox में इसके समकक्ष सुविधा नहीं है, इसलिए आपको अपने दर्शकों के एक हिस्से के लिए फॉलबैक लॉजिक (fallback logic) बनाए रखना होगा।
  • ह्यूरिस्टिक सीमाएं – API संकेतों के एक सेट के आधार पर सॉफ्ट नेविगेशन का निर्णय लेता है। यदि आपका ऐप URL बदले बिना कंटेंट अपडेट करता है (जैसे, मोडल ओवरले या इन्फिनिट स्क्रॉल), तो API उन ट्रांज़िशन को मिस कर सकता है, जिससे डेटा में अंतराल रह सकता है।
  • भरोसा करने से पहले टेस्टिंग – क्योंकि डिटेक्शन ह्यूरिस्टिक है, इसलिए अपने ऐप पर वास्तविक दुनिया के इंटरैक्शन का एक सेट चलाएं और रिपोर्ट किए गए मेट्रिक्स की तुलना मैन्युअल टाइमिंग (जैसे, performance.mark का उपयोग करके) से करें। सटीकता की पुष्टि करने के बाद ही आपको नए नंबरों के आधार पर ऑप्टिमाइज़ेशन के निर्णय लेने चाहिए।

निष्कर्ष

Chrome 151 SPA डेवलपर्स को हर इन-ऐप रूट परिवर्तन के लिए LCP, INP और CLS मापने की लंबे समय से प्रतीक्षित क्षमता देता है, लेकिन Google का रैंकिंग डेटा अभी भी केवल पहले हार्ड लोड को ही दर्शाता है। जब तक CrUX इसके बराबर नहीं पहुँच जाता, टीमों को दो समानांतर डेटा सेट के साथ तालमेल बिठाना होगा: एक जो वास्तविक यूजर स्टोरी बताता है, और दूसरा जो सर्च रैंकिंग को संचालित करता है। एक प्रतिस्पर्धी वेब इकोसिस्टम में परफॉरमेंस-फर्स्ट SPAs को बनाए रखने के लिए दोनों को संतुलित करना—और व्यापक ब्राउज़र सपोर्ट के लिए तैयार रहना—महत्वपूर्ण होगा।