تتيح واجهة برمجة تطبيقات Soft Navigations API في متصفح Chrome 151 أخيرًا لتطبيقات الصفحة الواحدة (SPAs) الإبلاغ عن مقاييس Core Web Vitals لكل عملية تنقل داخل التطبيق، ولكن لا تزال مجموعة بيانات CrUX من Google تسجل فقط التحميل الصلب (hard load) الأول، مما يترك المطورين أمام صورتين متباينتين للأداء.

لماذا تأخرت مقاييس تطبيقات الصفحة الواحدة (SPA)

تَمَّ تحديد مقاييس Core Web Vitals — وهي Largest Contentful Paint (LCP) وInteraction-to-Next-Paint (INP) وCumulative Layout Shift (CLS) — بناءً على عمليات التنقل الصلبة (hard navigations). تقوم عملية التنقل الصلب بجلب مستند جديد تمامًا والتخلص من حالة الصفحة السابقة.

نادراً ما تطلق تطبيقات SPA المبنية باستخدام React أو Vue أو Next.js أو أطر عمل مماثلة عمليات تنقل صلبة. فبالنقر على رابط، يتم تحديث عنوان URL عبر History API، وجلب البيانات في الخلفية، وتبديل المحتوى دون إعادة تحميل كاملة للصفحة. تقتصر واجهة Performance API الحالية على التقاط تحميل الصفحة الأولي فقط، لذا لا تظهر مقاييس LCP وINP التأخير الذي يشعر به المستخدمون عند الانتقال من مسار إلى آخر.

تؤدي هذه الفجوة إلى تشويه لوحات البيانات التي تسحب البيانات من Performance Timeline أو تقرير Chrome User Experience Report (CrUX) من Google. فغالباً ما تظهر هذه اللوحات قيمة LCP ممتازة لـ "صفحة الهيكل" (shell page) بينما تتجاهل عمليات التحميل الأبطأ في أعماق التطبيق، مما يعطي شعوراً زائفاً بصحة الأداء.

واجهة برمجة تطبيقات Chrome Soft Navigations API

قدم Chrome 151 واجهة Soft Navigations API، وهي مجموعة من القواعد الاستدلالية (heuristics) التي تعامل بعض تفاعلات تطبيقات SPA كعمليات تنقل حقيقية. تراقب هذه الواجهة ثلاث إشارات:

  • تفاعل بدأه المستخدم (نقرة، لمسة، أو حدث لوحة مفاتيح)
  • تغيير في عنوان URL عبر History API
  • أحداث الرسم (paint events) اللاحقة التي تعرض محتوى جديداً

عندما تتماشى هذه الإشارات الثلاث، يقوم Chrome بتسجيل تنقل ناعم (soft navigation) في Performance Timeline، ويتم حساب مقاييس Core Web Vitals لهذا الانتقال تماماً كما هو الحال في التنقل الصلب. وقد أضافت مكتبة web-vitals مفتوحة المصدر الدعم في 21 يوليو، مما يتيح للمطورين البدء في استخراج هذه الأرقام باستخدام نفس واجهة برمجة التطبيقات التي يستخدمونها بالفعل.

من الناحية العملية، ستتمكن الآن من رؤية قيمة LCP لكل تغيير في المسار، وقيمة INP تعكس التأخير الحقيقي لآخر إدخال من المستخدم، وقيمة CLS التي ترصد إزاحات التخطيط بعد التنقل الناعم.

انقسام البيانات: Chrome مقابل CrUX

تعتمد أدوات مثل PageSpeed Insights وSearch Console، وبشكل غير مباشر، على إشارات التصنيف، على تقرير CrUX (Chrome User Experience Report) من Google. ومع ذلك، لا تزال CrUX تجمع فقط بيانات التنقل الصلب (hard-navigation).

ونتيجة لذلك، ستجد نفسك أمام تدفقين متسقين ولكن مختلفين من البيانات:

  • الأدوات الداخلية التي تقرأ Performance Timeline تظهر الآن مقاييس LCP وINP وCLS على مستوى المسار، مما يعطي رؤية واقعية لما يختبره المستخدمون في تطبيق SPA.
  • مجموعات البيانات العامة من Google تستمر في إظهار المقاييس لتحميل الصفحة الأول فقط، وهو ما تظهره تقارير Search Console وما تعتمد عليه خوارزميات التصنيف من Google.

كلاهما صحيح؛ فهما يقيسان لحظات مختلفة فقط. الاعتماد فقط على Search Console قد يخفي تراجعات الأداء التي تحدث بعد التحميل الأولي، بينما لن تعكس لوحات البيانات الداخلية وحدها الخط المرجعي (baseline) الذي تستخدمه Google لتحسين محركات البحث (SEO).

ما يجب على المطورين مراقبته

  • دعم المتصفحات – تتوفر Soft Navigations API حالياً فقط في المتصفحات القائمة على Chromium. تفتقر Safari وFirefox إلى بديل مماثل، لذا يجب عليك الاحتفاظ بمنطق بديل (fallback logic) لجزء من جمهورك.
  • القيود الاستدلالية – تقرر الواجهة ما إذا كان التنقل "ناعماً" بناءً على مجموعة من الإشارات. إذا كان تطبيقك يقوم بتحديث المحتوى دون تغيير عنوان URL (مثل النوافذ المنبثقة "modal overlays" أو التمرير اللانهائي)، فقد تغفل الواجهة عن تلك الانتقالات، مما يترك فجوات في البيانات.
  • الاختبار قبل الثقة – نظرًا لأن الكشف يعتمد على قواعد استدلالية، قم بتشغيل مجموعة من التفاعلات الواقعية على تطبيقك وقارن المقاييس المسجلة بالتوقيت اليدوي (على سبيل المثال، باستخدام performance.mark). لا يجب عليك بناء قرارات التحسين على الأرقام الجديدة إلا بعد التأكد من دقتها.

الخلاصة

يمنح Chrome 151 مطوري تطبيقات SPA القدرة المنتظرة منذ فترة طويلة لقياس LCP وINP وCLS لكل تغيير في مسار التطبيق، ولكن بيانات التصنيف من Google لا تزال تعكس فقط التحميل الصلب الأول. وإلى أن تلحق CrUX بالركب، يجب على الفرق التعامل مع مجموعتين متوازيتين من البيانات: إحداهما تروي القصة الحقيقية للمستخدم، والأخرى هي التي تحرك تصنيفات البحث. سيكون التوازن بينهما — والاستعداد لدعم أوسع من المتصفحات — هو المفتاح للحفاظ على تطبيقات SPA التي تضع الأداء في المقام الأول في بيئة ويب تنافسية.