تجربة 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 قياس بعض جوانب Core Web Vitals. على وجه الخصوص، يستند مقياسا مدى استجابة الصفحة لتفاعلات المستخدم (INP) ومتغيّرات التصميم التراكمية (CLS) إلى عناصر أساسية (واجهة برمجة التطبيقات Event Timing API وواجهة برمجة التطبيقات Layout Instability API على التوالي) يمكن قياسها على أي فترة زمنية لاحتساب مقياسَي INP وCLS. ومع ذلك، بما أنّ المتصفّح يعرض سرعة عرض أكبر محتوى مرئي (LCP) ويضع اللمسات الأخيرة عليها استنادًا إلى عمليات التنقّل والتفاعلات على الصفحة، لا يمكن لأُطر عمل JavaScript الاطّلاع على أي شيء آخر غير أداء التحميل الأولي لتطبيقات الصفحة الواحدة.

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

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

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

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

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

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

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

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

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

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

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

أحتاج إلى مساعدة لاختبار Soft Navigation API

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

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

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

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

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

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

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

الملاحظات

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

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