Chrome 151 च्या Soft Navigations API मुळे आता single-page apps (SPAs) प्रत्येक in-app navigation साठी Core Web Vitals रिपोर्ट करू शकतात, परंतु Google चा CrUX डेटासेट अजूनही फक्त पहिल्या hard load ची नोंद करतो, ज्यामुळे डेव्हलपर्सना कामगिरीची (performance) दोन भिन्न चित्रे मिळतात.

SPA मेट्रिक्स मागे का राहिले होते

Core Web Vitals—Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) आणि Cumulative Layout Shift (CLS)—हे hard navigations च्या संदर्भात परिभाषित करण्यात आले होते. 'Hard navigation' मध्ये एक नवीन डॉक्युमेंट फेच केले जाते आणि मागील पेजची स्थिती (state) काढून टाकली जाते.

React, Vue, Next.js किंवा तत्सम फ्रेमवर्क्स वापरून तयार केलेल्या SPAs मध्ये क्वचितच hard navigations घडतात. लिंकवर क्लिक केल्यावर History API द्वारे URL अपडेट होते, बॅकग्राउंडमध्ये डेटा फेच केला जातो आणि पूर्ण रीलोड न होता कंटेंट बदलला जातो. सध्याची Performance API फक्त सुरुवातीचा पेज लोड कॅप्चर करते, त्यामुळे युजर्स जेव्हा एका रूटवरून दुसऱ्या रूटवर जातात, तेव्हा त्यांना जाणवणारा लॅटन्सी (latency) LCP आणि INP मध्ये कधीच दिसून येत नाही.

ही त्रुटी (blind spot) Performance Timeline किंवा Google च्या Chrome User Experience Report (CrUX) मधून डेटा घेणाऱ्या डॅशबोर्ड्सना चुकीचे निष्कर्ष दाखवते. ते अनेकदा "shell" पेजसाठी उत्कृष्ट LCP दाखवतात, परंतु ॲपच्या अंतर्गत भागातील संथ लोडिंगकडे दुर्लक्ष करतात, ज्यामुळे परफॉर्मन्स चांगला असल्याचा चुकीचा आभास निर्माण होतो.

Chrome चा Soft Navigations API

Chrome 151 ने Soft Navigations API सादर केले आहे, जे काही विशिष्ट SPA इंटरॅक्शन्सना 'रिअल नेव्हिगेशन' म्हणून मानणारे 'heuristics' (नियम) संच आहे. हे API तीन सिग्नलवर लक्ष ठेवते:

  • युजरने सुरू केलेले इंटरॅक्शन (click, tap, keyboard event)
  • History API द्वारे झालेला URL बदल
  • नवीन कंटेंट रेंडर करणारे पुढील paint events

जेव्हा हे तिन्ही घटक जुळतात, तेव्हा Chrome Performance Timeline मध्ये soft navigation ची नोंद करते आणि hard navigation प्रमाणेच त्या ट्रान्झिशनसाठी Core Web Vitals मोजले जातात. ओपन-सोर्स web-vitals लायब्ररीने २१ जुलै रोजी याला सपोर्ट जोडला आहे, त्यामुळे डेव्हलपर्स आता तेच API वापरून हे आकडे मिळवू शकतात जे ते आधीच वापरत आहेत.

प्रत्यक्ष व्यवहारात, आता तुम्हाला प्रत्येक रूट बदलासाठी LCP व्हॅल्यू, शेवटच्या युजर इनपुटचा खरा लॅटन्सी दर्शवणारा INP आणि soft navigation नंतरचे लेआउट शिफ्ट्स कॅप्चर करणारा CLS पाहायला मिळेल.

डेटाचे विभाजन: Chrome विरुद्ध CrUX

Google चा CrUX (Chrome User Experience Report) हा PageSpeed Insights, Search Console आणि अप्रत्यक्षपणे रँकिंग सिग्नलला आधार देतो. CrUX अजूनही फक्त hard-navigation डेटा एकत्रित करतो.

परिणामी, तुमच्याकडे दोन सुसंगत परंतु भिन्न डेटा स्ट्रीम्स तयार होतात:

  • Internal tools जे Performance Timeline वाचतात, ते आता रूट-लेव्हल LCP, INP आणि CLS दाखवतात, ज्यामुळे SPA मध्ये युजर्सना नेमका काय अनुभव येतो याचे वास्तववादी चित्र मिळते.
  • Google चे सार्वजनिक डेटासेट्स अजूनही फक्त पहिल्या पेज लोडसाठी मेट्रिक्स दाखवत आहेत, जे Search Console रिपोर्ट करते आणि ज्याचा संदर्भ Google चे रँकिंग अल्गोरिदम घेतात.

दोन्ही बरोबर आहेत; ते फक्त वेगवेगळ्या क्षणांचे मोजमाप करतात. केवळ Search Console वर अवलंबून राहिल्यामुळे सुरुवातीच्या लोड नंतर होणारे परफॉर्मन्स रिग्रेशन (performance regressions) लपले जाऊ शकतात, तर केवळ अंतर्गत डॅशबोर्ड Google SEO साठी वापरत असलेल्या बेसलाईनचे प्रतिबिंब दर्शवणार नाहीत.

डेव्हलपर्सनी कोणत्या गोष्टींकडे लक्ष दिले पाहिजे

  • Browser support – Soft Navigations API सध्या फक्त Chromium-आधारित ब्राउझर्समध्ये उपलब्ध आहे. Safari आणि Firefox मध्ये याला समकक्ष काहीही नाही, त्यामुळे तुम्हाला तुमच्या प्रेक्षकांच्या काही भागासाठी 'fallback logic' ठेवावा लागेल.
  • Heuristic limits – API काही संकेतांच्या आधारे soft navigation ठरवते. जर तुमचे ॲप URL न बदलता कंटेंट अपडेट करत असेल (उदा. modal overlays किंवा infinite scroll), तर API हे ट्रान्झिशन्स मिस करू शकते, ज्यामुळे डेटामध्ये त्रुटी राहू शकतात.
  • Testing before trusting – डिटेक्शन हे heuristic असल्यामुळे, तुमच्या ॲपवर रिअल-वर्ल्ड इंटरॅक्शन्सची एक सिरीज चालवा आणि रिपोर्ट केलेल्या मेट्रिक्सची तुलना मॅन्युअल टाइमिंगशी (उदा. performance.mark वापरून) करा. अचूकता निश्चित केल्यानंतरच नवीन आकडेवारीवर आधारित ऑप्टिमायझेशनचे निर्णय घ्या.

थोडक्यात सांगायचे तर

Chrome 151 SPA डेव्हलपर्सना प्रत्येक in-app रूट बदलासाठी LCP, INP आणि CLS मोजण्याची दीर्घकाळ प्रतीक्षित क्षमता देते, परंतु Google चा रँकिंग डेटा अजूनही फक्त पहिल्या hard load चे प्रतिबिंब दर्शवतो. जोपर्यंत CrUX यासोबत जुळवून घेत नाही, तोपर्यंत टीम्सना दोन समांतर डेटा सेट्स हाताळावे लागतील: एक जो युजरची खरी गोष्ट सांगतो आणि दुसरा जो सर्च रँकिंग ठरवतो. या दोन्हीचा समतोल राखणे—आणि व्यापक ब्राउझर सपोर्टसाठी तयार राहणे—स्पर्धात्मक वेब इकोसिस्टममध्ये 'performance-first' SPAs टिकवून ठेवण्यासाठी महत्त्वाचे ठरेल.