Chrome 151-ലെ Soft Navigations API ഒടുവിൽ single-page apps (SPAs)-ന് ഓരോ in-app navigation-നും Core Web Vitals റിപ്പോർട്ട് ചെയ്യാൻ അവസരം നൽകുന്നു. എന്നാൽ Google-ന്റെ CrUX ഡാറ്റാസെറ്റ് ഇപ്പോഴും ആദ്യത്തെ hard load മാത്രമേ രേഖപ്പെടുത്തുന്നുള്ളൂ, ഇത് ഡെവലപ്പർമാർക്ക് രണ്ട് വ്യത്യസ്ത പെർഫോമൻസ് ചിത്രങ്ങൾ നൽകുന്നു.

SPA മെട്രിക്സ് എന്തുകൊണ്ട് പിന്നിലായി

Core Web Vitals—Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP), Cumulative Layout Shift (CLS)—എന്നിവ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത് hard navigations അടിസ്ഥാനമാക്കിയാണ്. ഒരു hard navigation പുതിയൊരു ഡോക്യുമെന്റ് ഫെച്ച് ചെയ്യുകയും മുൻപത്തെ പേജിന്റെ സ്റ്റേറ്റ് ഒഴിവാക്കുകയും ചെയ്യുന്നു.

React, Vue, Next.js അല്ലെങ്കിൽ സമാനമായ ഫ്രെയിംവർക്കുകൾ ഉപയോഗിച്ച് നിർമ്മിച്ച SPAs അപൂർവ്വമായിട്ടേ hard navigations ട്രിഗർ ചെയ്യാറുള്ളൂ. ഒരു ലിങ്കിൽ ക്ലിക്ക് ചെയ്യുമ്പോൾ History API വഴി URL മാറുന്നു, ബാക്ക്ഗ്രൗണ്ടിൽ ഡാറ്റ ഫെച്ച് ചെയ്യുന്നു, കൂടാതെ പേജ് പൂർണ്ണമായി റീലോഡ് ചെയ്യാതെ തന്നെ ഉള്ളടക്കം മാറ്റുന്നു. നിലവിലുള്ള Performance API ആദ്യത്തെ പേജ് ലോഡ് മാത്രമേ ക്യാപ്ചർ ചെയ്യുന്നുള്ളൂ, അതിനാൽ ഉപയോക്താക്കൾ ഒരു റൂട്ടിൽ നിന്ന് മറ്റൊന്നിലേക്ക് മാറുമ്പോൾ അനുഭവപ്പെടുന്ന ലേറ്റൻസി (latency) LCP-യും INP-യും കാണുന്നില്ല.

ഈ പോരായ്മ 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 ലൈബ്രറി ജൂലൈ 21-ന് ഇതിനുള്ള പിന്തുണ ചേർത്തു, അതിനാൽ ഡെവലപ്പർമാർക്ക് നിലവിൽ ഉപയോഗിക്കുന്ന അതേ API ഉപയോഗിച്ച് ഈ വിവരങ്ങൾ ശേഖരിക്കാൻ കഴിയും.

പ്രായോഗികമായി, ഇപ്പോൾ ഓരോ റൂട്ട് മാറ്റത്തിനും നിങ്ങൾക്ക് ഒരു LCP മൂല്യം കാണാം, അവസാനത്തെ യൂസർ ഇൻപുട്ടിന്റെ യഥാർത്ഥ ലേറ്റൻസി പ്രതിഫലിപ്പിക്കുന്ന ഒരു INP, കൂടാതെ ഒരു soft navigation-ന് ശേഷമുള്ള ലേഔട്ട് ഷിഫ്റ്റുകൾ രേഖപ്പെടുത്തുന്ന ഒരു CLS എന്നിവ ലഭ്യമാണ്.

ഡാറ്റാ വിഭജനം: Chrome vs. CrUX

Google-ന്റെ CrUX (Chrome User Experience Report) ആണ് PageSpeed Insights, Search Console എന്നിവയ്ക്കും പരോക്ഷമായി റാങ്കിംഗ് സിഗ്നലുകൾക്കും കരുത്ത് പകരുന്നത്. CrUX ഇപ്പോഴും hard-navigation ഡാറ്റ മാത്രമേ സംഗ്രഹിക്കുന്നുള്ളൂ.

തൽഫലമായി, നിങ്ങൾക്ക് ഒരേസമയം എന്നാൽ വ്യത്യസ്തമായ രണ്ട് ഡാറ്റാ സ്ട്രീമുകൾ ലഭിക്കുന്നു:

  • Performance Timeline വായിക്കുന്ന Internal tools ഇപ്പോൾ റൂട്ട്-ലെവൽ 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 – ഇത് ഹ്യൂറിസ്റ്റിക് ആയതുകൊണ്ട്, നിങ്ങളുടെ ആപ്പിൽ യഥാർത്ഥ ഇന്ററാക്ഷനുകൾ നടത്തി അവ റിപ്പോർട്ട് ചെയ്യുന്ന മെട്രിക്സുമായി performance.mark പോലുള്ള രീതികൾ ഉപയോഗിച്ച് താരതമ്യം ചെയ്യുക. കൃത്യത ഉറപ്പുവരുത്തിയതിന് ശേഷം മാത്രം പുതിയ കണക്കുകൾ അടിസ്ഥാനമാക്കി ഒപ്റ്റിമൈസേഷൻ തീരുമാനങ്ങൾ എടുക്കുക.

ചുരുക്കത്തിൽ

Chrome 151 SPA ഡെവലപ്പർമാർക്ക് ഓരോ in-app route change-നും LCP, INP, CLS എന്നിവ അളക്കാനുള്ള കാത്തിരുന്ന കഴിവ് നൽകുന്നു, എന്നാൽ Google-ന്റെ റാങ്കിംഗ് ഡാറ്റ ഇപ്പോഴും ആദ്യത്തെ hard load മാത്രമേ പ്രതിഫലിപ്പിക്കുന്നുള്ളൂ. CrUX ഇതിനോട് പൊരുത്തപ്പെടുന്നത് വരെ, ടീമുകൾക്ക് രണ്ട് സമാന്തര ഡാറ്റാ സെറ്റുകൾ കൈകാര്യം ചെയ്യേണ്ടി വരും: ഒന്ന് യഥാർത്ഥ ഉപയോക്തൃ അനുഭവം പറയുന്നതും, മറ്റൊന്ന് സെർച്ച് റാങ്കിംഗിനെ സ്വാധീനിക്കുന്നതും. ഇവ രണ്ടും സന്തുലിതമായി കൊണ്ടുപോകുന്നതും കൂടുതൽ ബ്രൗസർ പിന്തുണയ്ക്കായി തയ്യാറെടുക്കുന്നതും മത്സരബുദ്ധിയുള്ള വെബ് ഇക്കോസിസ്റ്റത്തിൽ പെർഫോമൻസ് മുൻഗണന നൽകുന്ന SPAs നിലനിർത്തുന്നതിന് പ്രധാനമാണ്.