Chrome 151 ਦੀ Soft Navigations API ਆਖਰਕਾਰ single-page apps (SPAs) ਨੂੰ ਹਰ in-app navigation ਲਈ Core Web Vitals ਰਿਪੋਰਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਪਰ Google ਦਾ CrUX dataset ਅਜੇ ਵੀ ਸਿਰਫ਼ ਪਹਿਲੇ hard load ਨੂੰ ਹੀ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ developers ਕੋਲ performance ਦੀਆਂ ਦੋ ਵੱਖਰੀਆਂ ਤਸਵੀਰਾਂ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ।

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 ਨੂੰ trigger ਕਰਦੇ ਹਨ। ਕਿਸੇ ਲਿੰਕ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਨਾਲ History API ਰਾਹੀਂ URL ਅਪਡੇਟ ਹੋ ਜਾਂਦਾ ਹੈ, background ਵਿੱਚ data fetch ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪੂਰੇ reload ਤੋਂ ਬਿਨਾਂ content ਬਦਲ ਜਾਂਦਾ ਹੈ। ਮੌਜੂਦਾ Performance API ਸਿਰਫ਼ ਸ਼ੁਰੂਆਤੀ page load ਨੂੰ ਹੀ ਕੈਪਚਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ LCP ਅਤੇ INP ਉਸ latency ਨੂੰ ਕਦੇ ਨਹੀਂ ਦੇਖ ਪਾਉਂਦੇ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇੱਕ route ਤੋਂ ਦੂਜੇ route 'ਤੇ ਜਾਣ ਵੇਲੇ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।

ਉਹ blind spot ਉਹਨਾਂ dashboards ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਜੋ Performance Timeline ਜਾਂ Google ਦੇ Chrome User Experience Report (CrUX) ਤੋਂ data ਲੈਂਦੇ ਹਨ। ਉਹ ਅਕਸਰ “shell” ਪੇਜ ਲਈ ਇੱਕ ਵਧੀਆ LCP ਦਿਖਾਉਂਦੇ ਹਨ ਪਰ app ਦੇ ਅੰਦਰੂਨੀ ਹਿੱਸਿਆਂ ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਹੌਲੀ loads ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ performance ਦੀ ਸਿਹਤ ਬਾਰੇ ਇੱਕ ਗਲਤ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ।

Chrome ਦੀ Soft Navigations API

Chrome 151 ਨੇ Soft Navigations API ਪੇਸ਼ ਕੀਤੀ ਹੈ, ਜੋ ਕਿ heuristics ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜੋ ਕੁਝ ਖਾਸ SPA interactions ਨੂੰ ਅਸਲੀ navigations ਵਜੋਂ ਮੰਨਦਾ ਹੈ। API ਤਿੰਨ ਸੰਕੇਤਾਂ (signals) 'ਤੇ ਨਜ਼ਰ ਰੱਖਦੀ ਹੈ:

  • ਇੱਕ user-initiated interaction (click, tap, keyboard event)
  • History API ਰਾਹੀਂ URL ਵਿੱਚ ਤਬਦੀਲੀ
  • ਅਗਲੇ paint events ਜੋ ਨਵਾਂ content render ਕਰਦੇ ਹਨ

ਜਦੋਂ ਇਹ ਤਿੰਨੋਂ ਮਿਲਦੇ ਹਨ, ਤਾਂ Chrome Performance Timeline ਵਿੱਚ ਇੱਕ soft navigation log ਕਰਦਾ ਹੈ, ਅਤੇ Core Web Vitals ਦੀ ਗਣਨਾ ਉਸ transition ਲਈ ਵੀ ਉਵੇਂ ਹੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਿਵੇਂ hard navigation ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। open-source web-vitals library ਨੇ 21 ਜੁਲਾਈ ਨੂੰ ਇਸਦਾ support ਜੋੜ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਜੋ developers ਉਸੇ API ਨਾਲ ਇਹ ਅੰਕੜੇ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਣ ਜਿਸਦੀ ਉਹ ਪਹਿਲਾਂ ਹੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ।

ਅਸਲ ਵਿੱਚ, ਹੁਣ ਤੁਸੀਂ ਹਰ route change ਲਈ ਇੱਕ LCP value, ਇੱਕ INP ਜੋ ਆਖਰੀ user input ਦੀ ਅਸਲੀ latency ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ CLS ਦੇਖ ਸਕਦੇ ਹੋ ਜੋ soft navigation ਤੋਂ ਬਾਅਦ layout shifts ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ।

Data ਦਾ ਵੰਡ: Chrome ਬਨਾਮ CrUX

Google ਦਾ CrUX (Chrome User Experience Report) PageSpeed Insights, Search Console ਅਤੇ ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ranking signals ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। CrUX ਅਜੇ ਵੀ ਸਿਰਫ਼ hard-navigation data ਨੂੰ ਹੀ ਇਕੱਠਾ ਕਰਦਾ ਹੈ।

ਨਤੀਜੇ ਵਜੋਂ, ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਇਕਸਾਰ ਪਰ ਵੱਖਰੇ data streams ਹੁੰਦੇ ਹਨ:

  • Internal tools ਜੋ Performance Timeline ਨੂੰ ਪੜ੍ਹਦੇ ਹਨ, ਹੁਣ route-level LCP, INP ਅਤੇ CLS ਦਿਖਾਉਂਦੇ ਹਨ, ਜੋ ਕਿ ਇੱਕ SPA ਵਿੱਚ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਅਨੁਭਵ ਦਾ ਇੱਕ ਯਥਾਰਥਕ ਦ੍ਰਿਸ਼ ਦਿੰਦੇ ਹਨ।
  • Google ਦੇ public datasets ਅਜੇ ਵੀ ਸਿਰਫ਼ ਪਹਿਲੇ page load ਲਈ metrics ਦਿਖਾਉਂਦੇ ਹਨ, ਜੋ ਕਿ Search Console ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਅਤੇ ਜਿਸਦਾ Google ਦੇ ranking algorithms ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ।

ਦੋਵੇਂ ਸਹੀ ਹਨ; ਉਹ ਸਿਰਫ਼ ਵੱਖ-ਵੱਖ ਸਮੇਂ ਨੂੰ ਮਾਪਦੇ ਹਨ। ਸਿਰਫ਼ Search Console 'ਤੇ ਨਿਰਭਰ ਰਹਿਣ ਨਾਲ ਉਹ performance regressions ਛੁਪ ਸਕਦੇ ਹਨ ਜੋ ਸ਼ੁਰੂਆਤੀ load ਤੋਂ ਬਾਅਦ ਹੁੰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਸਿਰਫ਼ internal dashboards ਉਹ baseline ਨਹੀਂ ਦਿਖਾਉਣਗੇ ਜੋ Google SEO ਲਈ ਵਰਤਦਾ ਹੈ।

Developers ਨੂੰ ਕਿਸ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ

  • Browser support – Soft Navigations API ਅੱਜ ਸਿਰਫ਼ Chromium-ਅਧਾਰਤ browsers ਵਿੱਚ ਹੀ ਉਪਲਬਧ ਹੈ। Safari ਅਤੇ Firefox ਵਿੱਚ ਇਸਦੇ ਬਰਾਬਰ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਆਪਣੇ ਕੁਝ ਉਪਭੋਗਤਾਵਾਂ ਲਈ fallback logic ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।
  • Heuristic limits – API ਕੁਝ ਸੰਕੇਤਾਂ ਦੇ ਅਧਾਰ 'ਤੇ soft navigation ਦਾ ਫੈਸਲਾ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੀ app URL ਬਦਲੇ ਬਿਨਾਂ content ਨੂੰ ਅਪਡੇਟ ਕਰਦੀ ਹੈ (ਜਿਵੇਂ ਕਿ modal overlays ਜਾਂ infinite scroll), ਤਾਂ API ਉਹਨਾਂ transitions ਨੂੰ miss ਕਰ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ data ਵਿੱਚ ਕਮੀਆਂ ਰਹਿ ਸਕਦੀਆਂ ਹਨ।
  • Testing before trusting – ਕਿਉਂਕਿ detection heuristic ਹੈ, ਇਸ ਲਈ ਆਪਣੀ app 'ਤੇ ਅਸਲ-ਦੁਨੀਆ ਦੇ interactions ਦਾ ਇੱਕ ਸੈੱਟ ਚਲਾਓ ਅਤੇ reported metrics ਦੀ ਤੁਲਨਾ manual timing (ਜਿਵੇਂ ਕਿ performance.mark ਦੀ ਵਰਤੋਂ ਕਰਕੇ) ਨਾਲ ਕਰੋ। ਸਿਰਫ਼ ਸਹੀ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀ ਤੁਹਾਨੂੰ ਨਵੇਂ ਅੰਕੜਿਆਂ ਦੇ ਅਧਾਰ 'ਤੇ optimisation ਦੇ ਫੈਸਲੇ ਲੈਣੇ ਚਾਹੀਦੇ ਹਨ।

ਨਿਚੋੜ (Bottom line)

Chrome 151 SPA developers ਨੂੰ ਹਰ in-app route change ਲਈ LCP, INP ਅਤੇ CLS ਨੂੰ ਮਾਪਣ ਦੀ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਉਡੀਕੀ ਜਾ ਰਹੀ ਸਮਰੱਥਾ ਦਿੰਦਾ ਹੈ, ਪਰ Google ਦਾ ranking data ਅਜੇ ਵੀ ਸਿਰਫ਼ ਪਹਿਲੇ hard load ਨੂੰ ਹੀ ਦਰਸਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੱਕ CrUX ਇਸ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਆ ਜਾਂਦਾ, ਟੀਮਾਂ ਨੂੰ ਦੋ ਸਮਾਨਾਂਤਰ (parallel) data sets ਨਾਲ ਨਿਪਟਣਾ ਪਵੇਗਾ: ਇੱਕ ਜੋ ਉਪਭੋਗਤਾ ਦੀ ਅਸਲੀ ਕਹਾਣੀ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਜੋ search rankings ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨਾ—ਅਤੇ ਵਿਆਪਕ browser support ਲਈ ਤਿਆਰ ਰਹਿਣਾ—ਇੱਕ ਮੁਕਾਬਲੇਬਾਜ਼ ਵੈੱਬ ਈਕੋਸਿਸਟਮ ਵਿੱਚ performance-first SPAs ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇਗਾ।