Chrome 151-ன் Soft Navigations API இறுதியாக single-page apps (SPAs)-களுக்கு ஒவ்வொரு in-app navigation-க்கும் Core Web Vitals-ஐப் புகாரளிக்க அனுமதிக்கிறது, ஆனால் Google-ன் CrUX dataset இன்னும் முதல் hard load-ஐ மட்டுமே பதிவு செய்கிறது, இது டெவலப்பர்களுக்கு இரண்டு மாறுபட்ட செயல்திறன் காட்சிகளை (performance pictures) வழங்குகிறது.

ஏன் SPA அளவீடுகள் (metrics) பின்தங்கியுள்ளன

Core Web Vitals—Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) மற்றும் Cumulative Layout Shift (CLS)—hard navigations-ஐச் சுற்றியே வரையறுக்கப்பட்டன. ஒரு hard navigation என்பது ஒரு புதிய ஆவணத்தைப் (document) பெற்று, முந்தைய பக்கத்தின் நிலையை (state) நீக்கிவிடும்.

React, Vue, Next.js அல்லது அது போன்ற frameworks மூலம் உருவாக்கப்பட்ட SPAs அரிதாகவே hard navigations-ஐத் தூண்டுகின்றன. ஒரு இணைப்பைக் (link) கிளிக் செய்வது History API மூலம் URL-ஐப் புதுப்பிக்கிறது, பின்னணியில் தரவைப் பெறுகிறது மற்றும் முழு ரீலோட் (reload) இல்லாமலேயே உள்ளடக்கத்தை மாற்றுகிறது. தற்போதுள்ள Performance API ஆரம்பக்கட்ட பக்கப் பதிவை (initial page load) மட்டுமே பதிவு செய்கிறது, எனவே பயனர்கள் ஒரு route-லிருந்து மற்றொரு route-க்கு மாறும்போது உணரும் தாமதத்தை (latency) LCP மற்றும் INP கண்டுகொள்வதில்லை.

அந்தத் தெரியாத பகுதி (blind spot), Performance Timeline அல்லது Google-ன் Chrome User Experience Report (CrUX)-லிருந்து தரவைப் பெறும் dashboards-களைத் தவறாகக் காட்டுகிறது. அவை பெரும்பாலும் "shell" பக்கத்திற்குச் சிறந்த LCP-ஐக் காட்டுகின்றன, ஆனால் ஆப்-ன் ஆழமான பகுதிகளில் நடக்கும் மெதுவான பதிவுகளைப் புறக்கணிப்பதன் மூலம், செயல்திறன் ஆரோக்கியம் குறித்த தவறான உணர்வைத் தருகின்றன.

Chrome-ன் Soft Navigations API

Chrome 151, சில SPA தொடர்புகளை (interactions) உண்மையான navigations ஆகக் கருதும் Soft Navigations API என்ற heuristic தொகுப்பை அறிமுகப்படுத்தியுள்ளது. இந்த API மூன்று சிக்னல்களைக் கண்காணிக்கிறது:

  • பயனர் தொடங்கிய ஒரு interaction (click, tap, keyboard event)
  • History API மூலம் ஒரு URL மாற்றம்
  • புதிய உள்ளடக்கத்தை உருவாக்கும் அடுத்தடுத்த paint events

இவை மூன்றும் சரியாகப் பொருந்தும்போது, Chrome Performance Timeline-இல் ஒரு soft navigation-ஐப் பதிவு செய்கிறது, மேலும் ஒரு hard navigation போலவே அந்த மாற்றத்திற்கும் Core Web Vitals கணக்கிடப்படுகின்றன. ஓப்பன் சோர்ஸ் web-vitals library ஜூலை 21 அன்று இதற்கான ஆதரவைச் சேர்த்தது, எனவே டெவலப்பர்கள் தாங்கள் ஏற்கனவே பயன்படுத்தும் அதே API மூலம் இந்த எண்களைப் பெறத் தொடங்கலாம்.

நடைமுறையில், இப்போது ஒவ்வொரு route மாற்றத்திற்கும் ஒரு LCP மதிப்பையும், கடைசி பயனர் உள்ளீட்டின் (user input) உண்மையான தாமதத்தைப் பிரதிபலிக்கும் ஒரு INP மதிப்பையும், மற்றும் soft navigation-க்குப் பிறகு ஏற்படும் layout மாற்றங்களைப் பதிவு செய்யும் ஒரு CLS மதிப்பையும் நீங்கள் காணலாம்.

தரவுப் பிரிவு: Chrome vs. CrUX

Google-ன் CrUX (Chrome User Experience Report) என்பது PageSpeed Insights, Search Console மற்றும் மறைமுகமாக, ranking signals ஆகியவற்றிற்குத் தேவையான தரவை வழங்குகிறது. CrUX இன்னும் hard-navigation தரவை மட்டுமே ஒருங்கிணைக்கிறது.

இதன் விளைவாக, உங்களுக்கு இரண்டு நிலையான ஆனால் வேறுபட்ட தரவு ஓட்டங்கள் (data streams) கிடைக்கின்றன:

  • Performance Timeline-ஐப் படிக்கும் Internal tools, இப்போது route-நிலை LCP, INP மற்றும் CLS ஆகியவற்றைக் காட்டுகின்றன, இது ஒரு SPA-வில் பயனர்கள் எதை அனுபவிக்கிறார்கள் என்பதன் யதார்த்தமான பார்வையை வழங்குகிறது.
  • Google-ன் பொதுத் தரவுத் தொகுப்புகள் (public datasets), முதல் பக்கப் பதிவிற்கான அளவீடுகளை மட்டுமே தொடர்ந்து காட்டுகின்றன; இதுதான் Search Console அறிக்கையிடுவது மற்றும் Google-ன் ranking algorithms குறிப்பிடுவதுமாகும்.

இரண்டுமே சரியானவை; அவை வெவ்வேறு தருணங்களை அளவிடுகின்றன. Search Console-ஐ மட்டுமே நம்பியிருப்பது, ஆரம்பப் பதிவிற்குப் பிறகு ஏற்படும் செயல்திறன் குறைபாடுகளை (performance regressions) மறைக்கக்கூடும், அதே சமயம் internal dashboards மட்டும் Google SEO-விற்காகப் பயன்படுத்தும் அடிப்படை அளவை (baseline) பிரதிபலிக்காது.

டெவலப்பர்கள் கவனிக்க வேண்டியவை

  • Browser support – Soft Navigations API தற்போது Chromium சார்ந்த browsers-களில் மட்டுமே உள்ளது. Safari மற்றும் Firefox ஆகியவற்றில் இதற்கு இணையான வசதி இல்லை, எனவே உங்கள் பயனர்களில் ஒரு பகுதிக்காக நீங்கள் fallback logic-ஐ வைத்திருக்க வேண்டும்.
  • Heuristic limits – API சில குறிப்புகளை (cues) அடிப்படையாகக் கொண்டு ஒரு soft navigation-ஐத் தீர்மானிக்கிறது. உங்கள் ஆப் URL-ஐ மாற்றாமல் உள்ளடக்கத்தைப் புதுப்பித்தால் (உதாரணமாக, modal overlays அல்லது infinite scroll), API அந்த மாற்றங்களைக் கவனிக்காமல் போகலாம், இது தரவுகளில் இடைவெளிகளை ஏற்படுத்தும்.
  • Testing before trusting – கண்டறிதல் (detection) என்பது heuristic முறையில் இருப்பதால், உங்கள் ஆப்பில் சில நிஜ உலகத் தொடர்புகளை (real-world interactions) இயக்கி, அறிக்கையிடப்பட்ட அளவீடுகளை கைமுறை நேரத்துடன் (manual timing - எ.கா., performance.mark பயன்படுத்துதல்) ஒப்பிட்டுப் பார்க்கவும். துல்லியத்தன்மையை உறுதிப்படுத்திய பின்னரே புதிய எண்களின் அடிப்படையில் optimisation முடிவுகளை எடுக்க வேண்டும்.

சுருக்கம்

Chrome 151, SPA டெவலப்பர்களுக்கு ஒவ்வொரு in-app route மாற்றத்திற்கும் LCP, INP மற்றும் CLS ஆகியவற்றை அளவிடும் நீண்டகாலமாக எதிர்பார்க்கப்பட்டத் திறனை வழங்குகிறது, ஆனால் Google-ன் ranking தரவு இன்னும் முதல் hard load-ஐ மட்டுமே பிரதிபலிக்கிறது. CrUX இதைச் சரிசெய்யும் வரை, குழுக்கள் இரண்டு இணையாகச் செல்லும் தரவுத் தொகுப்புகளைக் கையாள வேண்டும்: ஒன்று உண்மையான பயனர் அனுபவத்தைச் சொல்லும், மற்றொன்று search rankings-ஐத் தீர்மானிக்கும். இரண்டையும் சமநிலைப்படுத்துவதும்—மற்றும் பரந்த அளவிலான browser ஆதரவிற்குத் தயாராக இருப்பதும்—போட்டி நிறைந்த web ecosystem-இல் செயல்திறன் சார்ந்த SPAs-களைப் பராமரிக்க முக்கியமானது.