Chrome 151 کا Soft Navigations API آخر کار single-page apps (SPAs) کو ہر in-app navigation کے لیے Core Web Vitals رپورٹ کرنے کی اجازت دیتا ہے، لیکن Google کا CrUX dataset اب بھی صرف پہلی 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 اپ ڈیٹ ہو جاتا ہے، بیک گراؤنڈ میں ڈیٹا فیچ کیا جاتا ہے، اور مکمل ری لوڈ کے بغیر مواد (content) تبدیل ہو جاتا ہے۔ موجودہ Performance API صرف ابتدائی پیج لوڈ کو ہی کیپچر کرتا ہے، اس لیے LCP اور INP اس تاخیر (latency) کو کبھی نہیں دیکھ پاتے جو صارفین کو ایک روٹ سے دوسرے روٹ پر منتقل ہوتے وقت محسوس ہوتی ہے۔
یہ اندھی جگہ (blind spot) ان ڈیش بورڈز کو غلط رخ دیتی ہے جو Performance Timeline یا Google کے Chrome User Experience Report (CrUX) سے ڈیٹا حاصل کرتے ہیں۔ وہ اکثر "shell" پیج کے لیے بہترین LCP دکھاتے ہیں جبکہ ایپ کے اندرونی حصوں میں ہونے والے سست لوڈز کو نظر انداز کر دیتے ہیں، جس سے کارکردگی کی صحت کا ایک غلط احساس پیدا ہوتا ہے۔
Chrome کا Soft Navigations API
Chrome 151 نے Soft Navigations API متعارف کرایا ہے، جو کہ ہیورسٹکس (heuristics) کا ایک مجموعہ ہے جو مخصوص SPA انٹرایکشنز کو حقیقی نیویگیشن کے طور پر لیتا ہے۔ یہ API تین سگنلز پر نظر رکھتا ہے:
- صارف کی طرف سے شروع کی گئی انٹرایکشن (کلک، ٹیپ، کی بورڈ ایونٹ)
- History API کے ذریعے URL میں تبدیلی
- بعد کے پینٹ ایونٹس (paint events) جو نیا مواد دکھاتے ہیں
جب یہ تینوں چیزیں ایک ساتھ ملتی ہیں، تو Chrome Performance Timeline میں ایک soft navigation لاگ کرتا ہے، اور Core Web Vitals کا حساب بالکل اسی طرح لگایا جاتا ہے جیسے hard navigation کے لیے لگایا جاتا ہے۔ اوپن سورس web-vitals لائبریری نے 21 جولائی کو اس کی سپورٹ شامل کر دی ہے، تاکہ ڈویلپرز اسی API کے ذریعے یہ نمبر حاصل کرنا شروع کر سکیں۔
عملی طور پر، اب آپ ہر روٹ چینج کے لیے LCP ویلیو، ایک ایسا INP جو آخری صارف ان پٹ کی حقیقی تاخیر (latency) کو ظاہر کرتا ہے، اور ایک ایسا CLS دیکھ سکتے ہیں جو soft navigation کے بعد لے آؤٹ شفٹس (layout shifts) کو کیپچر کرتا ہے۔
ڈیٹا کا فرق: Chrome بمقابلہ CrUX
Google کا CrUX (Chrome User Experience Report) PageSpeed Insights، Search Console اور بالواسطہ طور پر رینکنگ سگنلز کو طاقت فراہم کرتا ہے۔ CrUX اب بھی صرف hard-navigation ڈیٹا کو ہی جمع کرتا ہے۔
نتیجے کے طور پر، آپ کے پاس دو مستقل لیکن مختلف ڈیٹا اسٹریمز ہو جاتے ہیں:
- انٹرنل ٹولز جو Performance Timeline کو پڑھتے ہیں، اب روٹ لیول پر LCP، INP اور CLS دکھاتے ہیں، جو کہ ایک SPA میں صارفین کے تجربے کا حقیقت پسندانہ منظر پیش کرتے ہیں۔
- Google کے عوامی ڈیٹا سیٹس صرف پہلے پیج لوڈ کے میٹرکس دکھانا جاری رکھتے ہیں، جو کہ Search Console رپورٹ کرتا ہے اور جس کا حوالہ Google کے رینکنگ الگورتھم دیتے ہیں۔
دونوں درست ہیں؛ وہ بس مختلف لمحات کی پیمائش کرتے ہیں۔ صرف Search Console پر بھروسہ کرنے سے کارکردگی میں ایسی کمی (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 روٹ چینج کے لیے LCP، INP اور CLS کو ناپنے کی طویل عرصے سے مطلوبہ صلاحیت دیتا ہے، لیکن Google کا رینکنگ ڈیٹا اب بھی صرف پہلی hard load کو ہی ظاہر کرتا ہے۔ جب تک CrUX اس کے برابر نہیں آ جاتا، ٹیموں کو دو متوازی ڈیٹا سیٹس کے ساتھ کام کرنا ہوگا: ایک جو صارف کی حقیقی کہانی بتاتا ہے، اور دوسرا جو سرچ رینکنگ کو چلاتا ہے۔ دونوں کے درمیان توازن برقرار رکھنا—اور وسیع تر براؤزر سپورٹ کے لیے تیار رہنا—ایک مسابقتی ویب ایکو سسٹم میں کارکردگی کو اولیت دینے والی SPAs کو برقرار رکھنے کے لیے کلیدی حیثیت رکھتا ہے۔