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

Barry Pollard

Michal Mocny

تاريخ النشر: 1 فبراير 2023، تاريخ آخر تعديل: 20 سبتمبر 2026

منذ إطلاق مبادرة Core Web Vitals، سعت إلى قياس تجربة المستخدم الفعلية لموقع إلكتروني، بدلاً من التفاصيل الفنية وراء كيفية إنشاء موقع إلكتروني أو تحميله. تم إنشاء مقاييس Core Web Vitals الثلاثة لتكون مقاييس تتمحور حول المستخدم، وهي تمثّل تطورًا مقارنةً بالمقاييس الفنية الحالية، مثل DOMContentLoaded أو load التي تقيس أوقاتًا غالبًا ما تكون غير مرتبطة بكيفية إدراك المستخدمين لأداء الصفحة. لهذا السبب، من المفترض ألا تؤثر التكنولوجيا المستخدَمة لإنشاء الموقع الإلكتروني في النتيجة، شرط أن يكون أداء الموقع جيدًا.

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

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

يدرس فريق Chrome هذا التحدي منذ فترة، ويتطلّع إلى توحيد تعريف "التنقّل السلس" وكيفية قياس مؤشرات Core Web Vitals لهذا النوع من التنقّل، بطريقة مشابهة لطريقة قياس المواقع الإلكترونية التي تم تنفيذها في بنية الصفحات المتعددة (MPA) التقليدية.

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

ما هو التنقّل السلس؟

لقد توصّلنا إلى التعريف التالي للتنقّل المرن:

• يبدأ التنقّل من خلال إجراء من المستخدم.
• يؤدي الانتقال إلى تغيير عنوان URL الذي يظهر للمستخدم.
• يؤدي التفاعل إلى عرض مرئي.

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

دعم DevTools لعمليات التنقّل المرن

أضفنا إمكانية تتبُّع عمليات التنقّل السلسة إلى لوحة "الأداء" في "أدوات مطوري البرامج في Chrome" ضمن عرض المقاييس المباشرة، وفي عرض التتبُّع مع إتاحة الإحصاءات والعلامات:

كيف يطبّق Chrome عمليات التنقّل السلس لمطوّري تطبيقات الويب؟

بعد تفعيل ميزة التنقّل السلس (مزيد من المعلومات في القسم التالي)، سيغيّر Chrome طريقة تسجيل بعض مقاييس الأداء:

• سيتم إرسال حدث soft-navigation PerformanceTiming بعد رصد كل عملية تنقّل سلسة.
• سيتضمّن إدخال soft-navigation هذا navigationId، وهو عنوان URL الجديد في السمة name، بالإضافة إلى interactionId للتفاعل الأولي.
• سيتم إصدار إدخال واحد أو أكثر من إدخالات interaction-contentful-paint بعد التفاعلات التي تؤدي إلى عرض محتوى. سيحتوي هذا على إدخال largestContentfulPaint يمكن استخدامه لقياس سرعة عرض أكبر محتوى مرئي (LCP) لعمليات التنقّل السلسة.
• تتم إضافة السمة navigationId إلى كلّ من توقيتات الأداء (first-paint وfirst-contentful-paint وlargest-contentful-paint وinteraction-contentful-paint وfirst-input-delay وevent وlayout-shift)، ويتوافق ذلك مع إدخال التنقّل الذي تم إصدار الحدث ضمنه. يُرجى العِلم أنّه عندما تمتد هذه الإدخالات إلى عمليات التنقّل السلس، قد تحتوي على navigationId السابق أو التالي استنادًا إلى وقت إصدار الإدخال. يمكنك الاطّلاع على مزيد من المعلومات حول هذا الموضوع في قسم تسجيل المقاييس وفقًا لعنوان URL المناسب.
• ستتضمّن السمة soft-navigation دالة getLargestInteractionContentfulPaint() لاسترداد أكبر إدخال interaction-contentful-paint لعملية التنقّل هذه. ويمكن بعد ذلك استخدام هذه القيمة كقيمة أولية لمقياس LCP لعملية التنقّل هذه، ويمكن بعد ذلك تعديل قيمة LCP مع رصد المزيد من إدخالات interaction-contentful-paint لهذا التفاعل. يُرجى العِلم أنّ هذه السمة تحلّ محلّ سمة largestInteractionContentfulPaint التي كانت متاحة في مراحل التجربة والتقييم السابقة.
• من المحتمل أن تكون بعض إدخالات interaction-contentful-paint قد حدثت قبل التنقّل السلس (إذا لم يحدث تعديل عنوان URL إلا بعد عمليات العرض هذه). في هذه الحالات، تتجنّب دالة getLargestInteractionContentfulPaint() الحاجة إلى تخزين الإدخالات القديمة مؤقتًا والرجوع إليها بعد الانتهاء من عملية التنقّل السلس. يُرجى العِلم أنّ الإدخال الذي يعرضه getLargestInteractionContentfulPaint() هو نسخة طبق الأصل من أكبر إدخال interaction-contentful-paint في وقت إصداره، لذا قد يكون هذا الإدخال قد استخدم navigationId السابق لأنّ ذلك هو وقت حدوث العرض، ولكن يجب قياس عمليات العرض هذه مقارنةً بـ navigationId الجديد.
• سيتضمّن إدخال soft-navigation أيضًا paintTime وpresentationTime كسرعة عرض أول محتوى مرئي (FCP) لعملية التنقّل هذه.
• يُرجى العِلم أنّه سيتم أيضًا إصدار إدخالات interaction-contentful-paint بعد إجراء المزيد من التفاعلات، ولكن يجب أن يقتصر مقياس LCP لعنوان URL على إدخالات interaction-contentful-paint التي تتطابق مع عمليات التنقّل السلسة interactionId لاستبعادها، وكذلك على سمات largestContentfulPaint فقط ضمن ذلك.

ستسمح هذه التغييرات بقياس مؤشرات Core Web Vitals وبعض مقاييس بيانات التشخيص المرتبطة بها لكل عملية تنقّل في الصفحة، مع أنّ هناك بعض الفروق الدقيقة التي يجب أخذها في الاعتبار.

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

في ما يلي بعض التغييرات التي يجب أن يأخذها مالكو المواقع الإلكترونية في الاعتبار بعد تفعيل هذه الميزة:

• تتيح مراقبة إدخالات soft-navigation "تقسيم" إدخالات الأداء إلى كل "تنقّل".
• يمكن تقسيم مقياسَي CLS وINP وفقًا لتقديرك، بدلاً من قياسهما على مدار مراحل نشاط الصفحة بالكامل، ولكن ميزة "التنقّل السلس" توفّر مقياسًا موحّدًا لوقت حدوث ذلك، بغض النظر عن التكنولوجيا الأساسية المستخدَمة.
• يتم إنهاء إدخال largest-contentful-paint عند حدوث تفاعل (وهو أمر ضروري لبدء التنقّل المرن)، لذا لا يمكن استخدامه إلا لقياس سرعة عرض أكبر محتوى مرئي (LCP) في التنقّل الأولي "الصلب". وهذا يعني أنّ هذا المقياس لن يتغيّر عند قياس عمليات التنقّل السلسة، وبالتالي يمكن قياس LCP لعملية تحميل الصفحة الأولية، أي التنقّل الثابت، كما كان الحال دائمًا.
• يمكن استخدام إدخال interaction-contentful-paint الجديد الذي سيتم إصداره من التفاعلات لقياس LCP لعمليات التنقّل السلس من خلال الاطّلاع على السمة largestContentfulPaint ضمنه، ولكن هناك بعض الاعتبارات حول كيفية استخدام هذا الإدخال التي سنناقشها في هذه المقالة.
• يُرجى العِلم أنّ ميزة التنقّل السلس هذه لن تكون متاحة لبعض المستخدمين، لا سيما الذين يستخدمون متصفّحات أخرى أو إصدارات من Chrome قبل الإصدار 151. يُرجى العِلم أنّ بعض المستخدمين قد لا يبلّغون عن المقاييس المستندة إلى التنقّل السلس، حتى لو أبلغوا عن مقاييس Core Web Vitals.

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

لمزيد من المعلومات حول كيفية قياس مقاييس عمليات التنقّل السلسة، يُرجى الاطّلاع على قسم قياس Core Web Vitals لكل عملية تنقّل سلسة.

كيف يمكنني تفعيل عمليات التنقّل السلس في Chrome؟

يتم تفعيل ميزة "عمليات التنقّل السلسة" تلقائيًا بدءًا من الإصدار 151 من Chrome.

رصد ميزة توفّر واجهة Soft Navigations API

يمكنك استخدام الرمز التالي لاختبار ما إذا كانت واجهة برمجة التطبيقات متوافقة:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

أو بدلاً من ذلك:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

كيف يمكنني قياس عمليات التنقّل السلس؟

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

الإبلاغ عن عمليات التنقّل المرن

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

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

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

إعداد تقارير عن المقاييس وفقًا لعنوان URL المناسب

عند رصد عملية تنقّل سلسة، يجب إنهاء مؤشرات Core Web Vitals للصفحة السابقة، ثم الإبلاغ عنها لعنوان URL السابق، وبدء تتبُّع جديد لعنوان URL الجديد.

ستحتوي السمة name لإدخال soft-navigation المناسب على عنوان URL الجديد الذي سيتم تسجيل مقاييس التتبُّع له، وستكون السمة navigationId هي المرجع الفريد لعملية التنقّل هذه (لأنّه قد تتم زيارة عنوان URL نفسه عدة مرات على مدار عمر تطبيق من صفحة واحدة).

يجب ضبط هذا الإعداد لكل إدخال soft-navigation واستخدامه لتسجيل المقاييس إلى أن يتم تلقّي إدخال soft-navigation التالي.

الإبلاغ عن عنوان URL الصحيح لـ "interaction-contentful-paint"

يجب مراعاة بعض الاعتبارات الإضافية عند احتساب مقياس LCP من إدخالات interaction-contentful-paint، لأنّه لا يجب ربط جميع إدخالات interaction-contentful-paint باستخدام navigationId والإبلاغ عنها كمقياس LCP لعنوان URL هذا:

• المشكلة الأولى هي أنّه قد يتم إصدار إدخالات interaction-contentful-paint قبل حدوث التنقّل السلس في حال حدوث عرض قبل تعديل عنوان URL. في هذه الحالات، سيكون navigationId لعنوان URL القديم. إذا تم تعديل عنوان URL أولاً، ستُكمل عملية العرض التنقّل السلس، وفي هذه الحالة سيتم إرسال إدخال soft-navigation أولاً، وسيتضمّن interaction-contentful-paint عنوان URL الجديد.
• المشكلة الثانية هي أنّه في interaction-contentful-paint، سيستمر إصدار الإدخالات للتفاعلات الأحدث، لأنّ نطاق مقياس الأداء هذا يمتد إلى ما هو أبعد من "سرعة عرض أكبر محتوى مرئي" (LCP) لعمليات التنقّل السلسة. نريد فقط مراعاة عمليات العرض لتحميل التنقّل السلس لمقياس LCP وليس للتفاعلات اللاحقة.

لذلك، يجب استخدام interactionId بدلاً من navigationId لربط إدخالات interaction-contentful-paint بـ soft-navigation-entries للحصول على عنوان URL الصحيح. سيعالج هذا الإجراء أي إدخالات تتضمّن navigationId قديمة، كما سيستبعد أي إدخالات interaction-contentful-paint لا يجب أخذها في الاعتبار لمقياس LCP.

بالإضافة إلى ذلك، عليك معالجة دالة getLargestInteractionContentfulPaint() لإدخالات soft-navigation أولاً، للتعامل مع إدخالات interaction-contentful-paint التي حدثت قبل إرسال soft-navigation entries.

الحصول على startTime من عمليات التنقّل السلس

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

يمكن الحصول على وقت بدء التنقّل بطريقة مماثلة من خلال الربط بإدخال soft-navigation المناسب واستخدام startTime الخاص به.

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

قياس مؤشرات Core Web Vitals لكل عملية تنقّل سلسة

لقياس Core Web Vitals، استمِع إلى إدخالات soft-navigation، وأعِد ضبط المقاييس عند تلقّيها. يمكن إصدار سرعة عرض أول محتوى مرئي (FCP) استنادًا إلى presentationTime ويمكن بدء سرعة عرض أكبر محتوى مرئي (LCP) إلى الإدخال getLargestInteractionContentfulPaint(). يجب ضبط مقياسَي INP وCLS على 0 كما هو الحال عند تحميل الصفحة.

بعد ذلك، يمكن قياس ومراقبة مقاييس LCP وINP وCLS كالمعتاد (باستثناء استخدام interaction-contentful-paint لمقياس LCP في حال تطابق interactionId). يمكن استخدام interactionId لتسمية الإدخالات في عنوان URL كما تمت مناقشته سابقًا.

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

يتم قياس بعض المقاييس عادةً طوال عمر الصفحة: على سبيل المثال، يمكن أن يتغيّر مقياس LCP إلى أن يحدث تفاعل. يمكن تعديل مقياسَي CLS وINP إلى أن يتم الانتقال من الصفحة، بغض النظر عن أي تفاعلات. لذلك، يجب إنهاء مقاييس التنقّل السابقة عند حدوث كل عملية تنقّل سلسة جديدة. هذا يعني أنّ مقاييس التنقّل "الكامل" الأولية قد يتم الانتهاء منها في وقت أبكر من المعتاد عند قياس Core Web Vitals باستخدام عمليات التنقّل السلسة.

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

كيف يجب التعامل مع المحتوى الذي يظل كما هو بين عمليات التنقّل؟

سيقيس مقياس LCP لعمليات التنقّل السلسة (المحسوب من interaction-contentful-paint) عمليات العرض الجديدة فقط، وعمليات العرض المرتبطة بالتفاعل الذي تسبّب في التنقّل فقط. وقد يؤدي ذلك إلى اختلاف في مقياس LCP بين التشغيل على البارد لعملية التنقّل السلس والتشغيل السلس.

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

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

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

كيفية قياس مدة تحميل أول بايت (TTFB)

مدة تحميل أول بايت (TTFB) لعملية تحميل صفحة تقليدية تمثّل الوقت الذي يتم فيه عرض وحدات البايت الأولى من الطلب الأصلي.

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

هناك طريقة أبسط، وهي الإبلاغ عن مدة تحميل أول بايت (TTFB) بقيمة 0 لعمليات التنقّل السلس، على غرار ما ننصح به لعمليات الاستعادة من ميزة "التخزين المؤقت للصفحات". هذه هي الطريقة التي تستخدمها مكتبة web-vitals لعمليات التنقّل السلسة، وهي الطريقة التي ننصح بها لهذا المقياس في الوقت الحالي.

هل يجب قياس "مؤشرات أداء الويب الأساسية" باستخدام كلتا المنهجيتَين؟

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

بالنسبة إلى مقياس LCP، يعني ذلك مراعاة إدخالات largest-contentful-paint فقط للطريقة الحالية، وإدخالات largest-contentful-paint وinteraction-contentful-paint للطريقة الجديدة.

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

بعد ذلك، يجب إرسال المقاييس وتخزينها مرّتين لتحليلها.

استخدام مكتبة web-vitals لقياس مؤشرات Core Web Vitals لعمليات التنقّل السلس

وأسهل طريقة لمراعاة جميع الفروق الدقيقة هي استخدام مكتبة JavaScript‏ web-vitals التي تتيح عمليات التنقّل السلسة اعتبارًا من الإصدار 6.0.0. ويمكن قياس ذلك بالطريقة التالية (مع استبدال doTraditionalProcessing وdoSoftNavProcessing حسب الاقتضاء):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

تضمن مكتبة web-vitals أيضًا إعداد تقارير عن المقاييس وفقًا لعنوان URL الصحيح كما هو موضّح سابقًا، لأنّها تتضمّن كلاً من navigationId وnavigationURL في الإدخالات المقدَّمة إلى دالة الاستدعاء.

تسجّل مكتبة web-vitals المقاييس التالية لعمليات التنقّل السلس:

هل ستصبح هذه التغييرات جزءًا من قياسات Core Web Vitals؟

والهدف النهائي هو توفير وسيلة لقياس الأداء بشكل أفضل من خلال تجارب المستخدمين الفعليين. لذا، نعم، الهدف هو تضمين هذه العناصر في قياسات Core Web Vitals كما تعرضها جميع الأدوات بعد إطلاق واجهة برمجة التطبيقات.

كيف سيتم تسجيل عمليات التنقّل السلس في CrUX؟

لقد أطلقنا إصدارات تجريبية من مقاييس Core Web Vitals في CrUX. تنهي هذه المقاييس CLS وINP لـ "التنقّل الثابت" بعد أول تنقّل سلس، وتتضمّن أيضًا مقاييس LCP وCLS وINP إضافية لكل تنقّل سلس. ونخطّط لترقية هذه المقاييس التجريبية إلى مقاييس ثابتة في مايو 2027. لمزيد من المعلومات، يمكنك الاطّلاع على منشور المدوّنة مقاييس التنقّل السلس التجريبية متاحة الآن في CrUX.

كيفية التعامل مع عمليات التنقّل السلس في المتصفّحات الأخرى

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

يمكن استخدام Navigation API لمراقبة التغييرات في عناوين URL، ما قد يسمح بتقسيم مقياس INP حسب عنوان URL (وبالمثل مقياس CLS، مع أنّه متاح فقط في Chromium في الوقت الحالي، لذا لن يتم قياسه بغض النظر عن ذلك). ومع ذلك، لا يعالج هذا مقاييس العرض (FCP وLCP) التي يمكن تقريبها فقط.

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

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

الملاحظات

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

• يجب إرسال الملاحظات حول واجهة برمجة التطبيقات على شكل مشاكل على GitHub.
• يجب الإبلاغ عن الأخطاء في تنفيذ Chromium على أداة تتبُّع المشاكل في Chrome، إذا لم تكن هذه إحدى المشاكل المعروفة بعد.
• يمكن مشاركة الملاحظات العامة حول مؤشرات أداء الويب على web-vitals-feedback@googlegroups.com.

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

سجلّ التغييرات

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

الخاتمة

تُعدّ ميزة "عمليات التنقّل البسيطة" نهجًا رائعًا لكيفية تطوّر مبادرة Core Web Vitals لقياس نمط شائع على الويب الحديث غير متوفّر في مقاييسنا. لقد جمعنا ملاحظات كثيرة من منتدى الويب الأوسع نطاقًا، ونحن متحمّسون لإمكانات واجهة برمجة التطبيقات هذه.

الإقرارات

الصورة المصغّرة من تصميم جوردان مدريد على Unsplash

هذا العمل هو استمرار للعمل الذي بدأه يواف فايس عندما كان في Google. نشكر "يواف" على جهوده في واجهة برمجة التطبيقات هذه.