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 ಹೊಸ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಹಿಂದಿನ ಪುಟದ ಸ್ಥಿತಿಯನ್ನು (state) ಕೈಬಿಡುತ್ತದೆ.

React, Vue, Next.js ಅಥವಾ ಇಂತಹ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳೊಂದಿಗೆ ನಿರ್ಮಿಸಲಾದ SPAs ಬಹಳ ಅಪರೂಪವಾಗಿ hard navigations ಅನ್ನು ಪ್ರಚೋದಿಸುತ್ತವೆ. ಲಿಂಕ್ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡುವುದು History API ಮೂಲಕ URL ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುತ್ತದೆ, ಹಿನ್ನೆಲೆಯಲ್ಲಿ (background) ಡೇಟಾವನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಪೂರ್ಣ ರೀಲೋಡ್ ಇಲ್ಲದೆ ಕಂಟೆಂಟ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ 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 ಸಂವಹನಗಳನ್ನು (interactions) ನೈಜ ಸಂಚಲನಗಳಾಗಿ (navigations) ಪರಿಗಣಿಸುವ 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 ಆ ಪರಿವರ್ತನೆಗಳನ್ನು ತಪ್ಪಿಸಬಹುದು, ಇದರಿಂದ ಡೇಟಾದಲ್ಲಿ ಅಂತರಗಳು (gaps) ಉಂಟಾಗಬಹುದು.
  • Testing before trusting – ಪತ್ತೆಹಚ್ಚುವಿಕೆಯು heuristic ಆಗಿರುವುದರಿಂದ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ನೈಜ-ಪ್ರಪಂಚದ ಸಂವಹನಗಳ ಸರಣಿಯನ್ನು ಚಲಾಯಿಸಿ ಮತ್ತು ವರದಿಯಾದ ಮೆಟ್ರಿಕ್ಸ್‌ಗಳನ್ನು ಮ್ಯಾನುಯಲ್ ಟೈಮಿಂಗ್ (ಉದಾಹರಣೆಗೆ, performance.mark ಬಳಸಿ) ಜೊತೆಗೆ ಹೋಲಿಸಿ ನೋಡಿ. ನಿಖರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಂಡ ನಂತರವಷ್ಟೇ ನೀವು ಹೊಸ ಅಂಕಿಅಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಆಪ್ಟಿಮೈಸೇಶನ್ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು.

ಸಾರಾಂಶ

Chrome 151 ಪ್ರತಿ in-app route ಬದಲಾವಣೆಗಾಗಿ LCP, INP ಮತ್ತು CLS ಅನ್ನು ಅಳೆಯುವ ಬಹುಕಾಲದ ನಿರೀಕ್ಷಿತ ಸಾಮರ್ಥ್ಯವನ್ನು SPA ಡೆವಲಪರ್‌ಗಳಿಗೆ ನೀಡುತ್ತದೆ, ಆದರೆ Google ನ র‍್ಯಾಂಕಿಂಗ್ ಡೇಟಾ ಇನ್ನೂ ಮೊದಲ hard load ಅನ್ನು ಮಾತ್ರ ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. CrUX ಈ ಮಟ್ಟಕ್ಕೆ ಬರುವವರೆಗೆ, ತಂಡಗಳು ಎರಡು ಸಮಾಂತರ ಡೇಟಾ ಸೆಟ್‌ಗಳನ್ನು ನಿಭಾಯಿಸಬೇಕಾಗುತ್ತದೆ: ಒಂದು ನಿಜವಾದ ಬಳಕೆದಾರರ ಕಥೆಯನ್ನು ಹೇಳುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ಸರ್ಚ್ ರಾಂಕಿಂಗ್‌ಗಳನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಎರಡನ್ನೂ ಸಮತೋಲನಗೊಳಿಸುವುದು—ಮತ್ತು ವ್ಯಾಪಕವಾದ ಬ್ರೌಸರ್ ಬೆಂಬಲಕ್ಕಾಗಿ ಸಿದ್ಧರಾಗಿರುವುದು—ಸ್ಪರ್ಧಾತ್ಮಕ ವೆಬ್ ಪರಿಸರದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಆದ್ಯತೆ ನೀಡುವ (performance-first) SPAs ಅನ್ನು ಕಾಯ್ದುಕೊಳ್ಳಲು ಪ್ರಮುಖವಾಗಿರುತ್ತದೆ.