تجربة Soft Navigations الجديدة

Barry Pollard
Michal Mocny

تاريخ النشر: 31 يوليو 2025

سيطلق Chrome مرحلة تجربة وتقييم جديدة من الإصدار 139 من Chrome لواجهة Soft Navigations API التي سبق أن أجرينا تجارب عليها. تتيح هذه التجربة الأصلية للمواقع الإلكترونية تجربة واجهة برمجة التطبيقات على مواقعها الإلكترونية مع مستخدمين حقيقيين لاختبارها ميدانيًا وتقديم ملاحظات إلى فريق Chrome.

ما هي عمليات التنقّل السلس؟

يحدث التنقّل السلس عندما يعترض JavaScript عملية تنقّل (مثل النقر على رابط) ويعدّل المحتوى على الصفحة الحالية، بدلاً من تحميل صفحة جديدة ثم تعديل عنوان URL في شريط العناوين (مع حالة سجلّ تتيح التنقّل السلس ذهابًا وإيابًا). بالنسبة إلى المستخدم، تبدو هذه التنقلات مماثلة للتنقلات التقليدية، ولكن بالنسبة إلى المتصفّح، تظل الصفحة هي الصفحة الأصلية.

سبب الحاجة إلى Soft Navigation API

Soft Navigations API هي واجهة برمجة تطبيقات مقترَحة تتيح رصد ما يُعرف باسم "عمليات التنقّل السلس" المستخدَمة في المواقع الإلكترونية التي تستخدم تطبيقات الصفحة الواحدة (SPA) استنادًا إلى البحث الاستدلالي. بما أنّه لا يتم التنقّل الفعلي بين الصفحات عند التنقّل السلس، يعني ذلك أنّه يجب إدارة بعض الإجراءات التي تحدث عادةً عند التنقّل يدويًا باستخدام JavaScript. تتوفّر بعض الإجراءات، مثل إدارة سجلّ التنقّل، من خلال واجهات برمجة التطبيقات الحالية. ومع ذلك، لا يمكن تنفيذ إجراءات أخرى، مثل قياس مؤشرات Core Web Vitals، في عمليات التنقّل هذه.

تتيح واجهة برمجة التطبيقات Soft Navigation API مراقبة عمليات التنقّل السلس. في حين أنّ JavaScript الذي يبدأ عملية التنقّل السلس (عادةً ما يكون إطار عمل JavaScript) يكون على دراية بوقت حدوث عملية التنقّل، لن يكون JavaScript الآخر والمتصفّح نفسه على دراية بذلك.

مؤشرات Core Web Vitals وتطبيقات الصفحة الواحدة

أحد الأسباب الرئيسية لتوفير Soft Navigation API هو السماح بقياس مؤشرات Core Web Vitals لتطبيقات الصفحة الواحدة. يتم قياس مؤشرات Core Web Vitals من خلال المتصفّح (لعرضها في الأدوات، مثل تقرير تجربة المستخدم في Chrome)، ومن خلال مكتبات JavaScript الخاصة بميزة "مراقبة المستخدمين الفعليين" (RUM).

يمكن لأُطر عمل JavaScript قياس بعض جوانب "مؤشرات أداء الويب الأساسية". على وجه الخصوص، يستند مقياسا مدى استجابة الصفحة لتفاعلات المستخدم (INP) وإجمالي تغيير تنسيق الصفحة (CLS) إلى عناصر أساسية (واجهة برمجة التطبيقات Event Timing API وواجهة برمجة التطبيقات Layout Instability API على التوالي) يمكن قياسها على مدار أي فترة زمنية لاحتساب مقياسَي INP وCLS. ومع ذلك، لا يتم إرسال مقاييس أخرى، مثل سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)، إلا من خلال المتصفّح استنادًا إلى عمليات التنقّل بين الصفحات، ويتم تحديد قيمتها النهائية عند التفاعل.

كيف تتيح Soft Navigation API قياس "مؤشرات أداء الويب الأساسية" لتطبيقات الصفحة الواحدة

في الإصدار الأول من Soft Navigation API، تم ربط الإرشادات التجريبية للتنقّل السلس بإعادة ضبط مقياس Largest Contentful Paint. بعد إعادة ضبطها، يمكن إعادة إرسال مقياس LCP لعمليات التنقّل السلس من أجل عرض جديد للمحتوى، ما يتيح قياس هذا المقياس لعمليات التنقّل السلس.

يتّخذ هذا الإصدار الأخير نهجًا مختلفًا ويفصل بين هذه المفاهيم في Soft Navigation API وإدخال جديد للأداء في مقياس "سرعة عرض أوّل محتوى مفيد". يقيس إدخال interaction-contentful-paint "الرسم المفيد" بعد التفاعلات. في الوقت الحالي، يتم إصدار هذا الحدث فقط للتنقّلات السلسة، ولكن يتيح ذلك حالات استخدام محتملة أخرى تتجاوز LCP إذا تم تفعيله لجميع التفاعلات.

وسّعت واجهة برمجة التطبيقات أيضًا كل إدخالات الأداء largest-contentful-paint وinteraction-contentful-paint وevent-timing وlayout-shift لتشمل معرّفًا يخصّ التنقّل الذي يمثّله الإدخال. يتم إصدار إدخالات الأداء بعد الحدث الذي تقيسه، وعادةً ما يكون ذلك خلال وقت الخمول. وهذا يعني أنّه غالبًا ما يكون عنوان URL قد تغيّر بحلول وقت إصدار إدخال الأداء. ويؤدي تضمين عملية التنقّل مع الإدخال إلى تسهيل قياس "مؤشرات أداء الويب الأساسية" لعنوان URL المحدّد بدون الحاجة إلى مطابقة أوقات إدخال الأداء مع أوقات إدخال التنقّل السلس.

لماذا نستخدم طريقة إرشادية؟

تعتبر Soft Navigation API عملية تنقّل سلسة عند حدوث ما يلي:

  • حدوث تفاعل يستند إلى المستخدم (لا يتم احتساب عمليات تعديل عناوين URL بدون تفاعل المستخدم)
  • … ما يؤدي إلى تعديل DOM وعملية رسم
  • … ويتم تعديل عنوان URL
  • تعديل عنوان URL، بما في ذلك تغيير في السجلّ

تتّبع واجهة برمجة التطبيقات هذه نهجًا مستندًا إلى الاستدلال بدلاً من السماح لإطار عمل JavaScript بـ "إصدار" تنقّل سلس، أو أن يتم إنشاؤها استنادًا إلى Navigation API، لأنّ ذلك يتيح فهمًا متسقًا لما يشكّل تنقّلاً سلسًا بغض النظر عن إطار العمل أو طريقة استخدام المطوّر له.

قد تعدّل الأُطر أو المطوّرون عنوان URL الخاص بالتنقّل السلس حتى بدون تفاعل المستخدم أو تعديل نموذج المستند (DOM) الذي نعتبره ما سيراه المستخدم كتنقّل. وقد يعدّلون أيضًا عنوان URL في أوقات مختلفة، مثل بداية التفاعل أو نهايته فقط عند اكتماله، أو في أي مرحلة بينهما.

بدلاً من الاعتماد على خيارات الأُطر، يتيح إنشاء ميزة رصد التنقّل السلس في المتصفّح وضع "إرشادات" أساسية (مع ملاحظاتك من هذه التجربة الأصلية)، ما سيسمح لنا بقياس "مؤشرات أداء الويب الأساسية" لعمليات التنقّل السلس على نطاق واسع وجعل هذه القياسات قابلة للمقارنة على نطاق واسع.

يمكن أيضًا للأُطر والمطوّرين تجاهل إحصاءات Soft Navigations API واستخدام واجهات برمجة التطبيقات الأساسية Event Timing وLayout Instability وInteraction to Contentful Paint لقياس مقاييس أداء إضافية حسب ما يريدون، ولكنّنا ننصح باستخدام "مؤشرات أداء الويب الأساسية" مع الإحصاءات للسماح بالقياس على مستوى المواقع الإلكترونية.

مساعدة مطلوبة لاختبار Soft Navigation API

نحتاج إلى المساعدة في اختبار واجهة برمجة التطبيقات Soft Navigations API للتأكّد مما إذا كانت طريقة البحث الاستدلالي تتطابق بشكل صحيح مع توقعاتك بشأن وقت حدوث التنقّل السلس. هل هناك حالات لا تعرض فيها واجهة برمجة التطبيقات عمليات التنقّل السلس عندما تعتبر أنّها حدثت؟ على العكس من ذلك، هل تتجاهل واجهة برمجة التطبيقات عمليات التنقّل المتكرّرة التي لا تعتبرها عمليات تنقّل سلسة؟

من الأمثلة التي لاحظنا أنّها تتسبّب في حدوث مشاكل، عندما يتم تعديل عنوان URL باستخدام replaceState بدلاً من إضافة سجلّ، أو عندما يحدث تنقّل لم يبدأه المستخدم (مثل تسجيل الخروج عند انتهاء المهلة). يمكن تفسير كلتا الحالتين بعدم تطابق الإرشادات التجريبية، ويوافق فريق Chrome على عدم تضمينها، ولكنّنا نريد أن نسمع آراء مطوّري الويب بشأن هذا الموضوع. ونريد بشكل خاص معرفة الحالات التي يبدو فيها أنّه تم استيفاء الإرشادات التجريبية ولكنّ واجهة برمجة التطبيقات لا تزال لا تتعرّف على التنقّل السلس.

بالإضافة إلى ذلك، نريد أن نعرف ما إذا كانت واجهة برمجة التطبيقات هذه، وعنصر Interaction to Contentful Paint الأساسي الجديد، يلبّيان حالة الاستخدام الأساسية المتمثّلة في السماح بقياس "مؤشرات أداء الويب الأساسية" لتطبيقات الصفحة الواحدة.

نريد أن تكون واجهة برمجة التطبيقات مفيدة قدر الإمكان، ويسهل تحقيق ذلك قبل إطلاقها وبدء المواقع الإلكترونية في الاعتماد على عملية التنفيذ. لذلك، نطلب من مطوّري تطبيقات الصفحة الواحدة ومن المهتمين بقياس أداء الويب لهذه المواقع الإلكترونية تجربة واجهة برمجة التطبيقات هذه وإخبارنا بمدى فعاليتها.

كيفية إجراء الاختبار

يمكن اختبار واجهة برمجة التطبيقات محليًا باستخدام علامات Chrome أو خيارات سطر الأوامر. بالإضافة إلى ذلك، يمكن اختبارها ميدانيًا من خلال مرحلة التجربة والتقييم.

يمكنك الرجوع إلى مستنداتنا أو مستودع GitHub للاطّلاع على المزيد من التفاصيل الفنية حول واجهة برمجة التطبيقات، وخاصةً كيفية قياس مؤشرات Core Web Vitals. بالإضافة إلى ذلك، يتوفّر إصدار تجريبي من مكتبة web-vitals يتيح التنقّل السلس.

الملاحظات

نحن نسعى جاهدين للحصول على ملاحظات حول هذه التجربة في الأماكن التالية:

إذا كنت غير متأكد، لا تقلق كثيرًا، فنحن نفضل تلقّي الملاحظات في أيّ من المكانين وسنصنّف المشاكل بكل سرور في كلا المكانين ونعيد توجيهها إلى المكان الصحيح.