Chrome 151 యొక్క Soft Navigations API చివరకు single-page apps (SPAs) ప్రతి in-app navigation కోసం Core Web Vitals ని రిపోర్ట్ చేసేలా చేస్తోంది, కానీ Google యొక్క CrUX dataset ఇప్పటికీ మొదటి 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 ని చూపిస్తాయి, కానీ యాప్‌లో లోతైన భాగాలలో జరిగే నెమ్మదైన లోడ్‌లను విస్మరిస్తాయి, దీనివల్ల performance ఆరోగ్యం గురించి తప్పుడు అవగాహన కలుగుతుంది.

Chrome యొక్క Soft Navigations API

Chrome 151 Soft Navigations API ని పరిచయం చేసింది, ఇది కొన్ని SPA ఇంటరాక్షన్‌లను నిజమైన navigations గా పరిగణించే ఒక set of 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 విలువను, చివరి యూజర్ ఇన్‌పుట్ యొక్క నిజమైన latency ని ప్రతిబింబించే INP ని మరియు soft navigation తర్వాత లేఅవుట్ షిఫ్ట్‌లను క్యాప్చర్ చేసే CLS ని చూడవచ్చు.

డేటా విభజన: Chrome vs. CrUX

Google యొక్క CrUX (Chrome User Experience Report) అనేది PageSpeed Insights, Search Console మరియు పరోక్షంగా, ranking signals కి శక్తినిస్తుంది. CrUX ఇప్పటికీ కేవలం hard-navigation డేటాను మాత్రమే సేకరిస్తుంది.

దీని ఫలితంగా, మీకు రెండు స్థిరమైన కానీ భిన్నమైన డేటా స్ట్రీమ్‌లు లభిస్తాయి:

  • Performance Timeline ని చదివే Internal tools ఇప్పుడు రూట్-లెవల్ LCP, INP మరియు CLS ని చూపిస్తాయి, ఇది ఒక SPA లో వినియోగదారులు ఏమి అనుభవిస్తారో వాస్తవిక దృక్పథాన్ని అందిస్తుంది.
  • Google యొక్క public datasets మొదటి పేజీ లోడ్‌కు సంబంధించిన మెట్రిక్స్‌ను మాత్రమే చూపుతాయి, ఇవే Search Console నివేదికలు మరియు Google యొక్క ranking algorithms రిఫరెన్స్ చేసుకునేవి.

రెండూ సరైనవే; అవి కేవలం వేర్వేరు సమయాలను కొలుస్తాయి. కేవలం Search Console పై మాత్రమే ఆధారపడటం వల్ల ప్రారంభ లోడ్ తర్వాత జరిగే performance regressions ని గుర్తించలేకపోవచ్చు, అదే సమయంలో కేవలం internal dashboards మాత్రమే 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 ఉపయోగించి) పోల్చి చూడండి. ఖచ్చితత్వాన్ని ధృవీకరించిన తర్వాతే కొత్త నంబర్‌ల ఆధారంగా optimisation నిర్ణయాలు తీసుకోవాలి.

ముగింపు

Chrome 151 అనేది ప్రతి in-app route మార్పు కోసం LCP, INP మరియు CLS ని కొలిచేందుకు SPA డెవలపర్‌లకు ఎప్పటి నుంచో ఎదురుచూస్తున్న సామర్థ్యాన్ని అందిస్తుంది, కానీ Google యొక్క ranking డేటా ఇప్పటికీ మొదటి hard load ని మాత్రమే ప్రతిబింబిస్తుంది. CrUX దీనిని అందుకోవడానికి సమయం పడుతుంది కాబట్టి, టీమ్‌లు రెండు సమాంతర డేటా సెట్‌లను నిర్వహించాల్సి ఉంటుంది: ఒకటి వినియోగదారుడి నిజమైన అనుభవాన్ని తెలియజేస్తుంది, మరొకటి సెర్చ్ ర్యాంకింగ్‌లను నడిపిస్తుంది. ఈ రెండింటినీ సమతుల్యం చేయడం—మరియు విస్తృతమైన బ్రౌజర్ సపోర్ట్ కోసం సిద్ధంగా ఉండటం—పోటీతత్వంతో కూడిన వెబ్ ఎకోసిస్టమ్‌లో performance-first SPAs ని నిర్వహించడానికి కీలకం అవుతుంది.