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

Barry Pollard

Michal Mocny

تاريخ النشر: 1 فبراير 2023، تاريخ آخر تعديل: 24 يونيو 2026

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

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

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

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

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

ما هي ميزة "التنقّل السلس"؟

لقد وضعنا التعريف التالي للتنقّل السلس:

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

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

توافق DevTools مع عمليات التنقّل السلس

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

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

في الوقت الحالي، لا يعرض ذلك سوى الطوابع الزمنية للتنقّل السلس وأكبر محتوى مرئي في عرض التتبُّع. ستتم إضافة مقاييس أخرى (مثل LCP) وإتاحة عرضها في المقاييس المباشرة لاحقًا.

كيف ينفّذ 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 فقط ضمن ذلك.

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

ما هي الآثار المترتبة على تفعيل التنقّل السلس في Chrome؟

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

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

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

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

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

من المفترض أن يتم تفعيل ميزة التنقّل السلس تلقائيًا في الإصدار 151 من Chrome، ولكن يمكن اختبارها قبل ذلك من خلال تفعيلها بشكل صريح.

ويمكن للمطوّرين تفعيل هذا الخيار من خلال تفعيل العلامة في chrome://flags/#soft-navigation-heuristics. يمكنك بدلاً من ذلك تفعيلها باستخدام وسيطات سطر الأوامر --enable-features=SoftNavigationHeuristics عند تشغيل Chrome. يؤدي تفعيل العلامة chrome://flags/#enable-experimental-web-platform-features إلى تفعيل عمليات التنقّل السلس أيضًا.

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

إتاحة واجهة برمجة التطبيقات Soft Navigations API لرصد الميزات

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

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

يُرجى العِلم أنّه يتم تجميد قيمة supportedEntryTypes عند الاستخدام الأول، لذا إذا تمت إضافة ميزة التنقّل السلس ديناميكيًا من خلال رمز تجريبي لمرحلة التجربة والتقييم تم إدراجه في الصفحة، قد يؤدي ذلك إلى عرض القيمة الأصلية قبل تفعيل هذه الميزة.

يمكن استخدام البديل التالي في هذه الحالة إلى أن يصبح التنقّل السلس متاحًا تلقائيًا ويكون في حالة الانتقال هذه:

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 وطرح وقت بدء التنقّل السلس المناسب كما تم توضيحه سابقًا للحصول على توقيت مرتبط بالتنقّل السلس.

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

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

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

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

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

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

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

كيفية قياس TTFB؟

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

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

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

هل يجب قياس مؤشرات Core 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 التي تتضمّن دعمًا تجريبيًا للتنقّلات السلسة في حزمة منفصلة soft-navs branch (تتوفّر أيضًا على npm وunpkg). يمكن قياس ذلك بالطريقة التالية (مع استبدال 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 التي تعرضها جميع الأدوات بعد إطلاق واجهة برمجة التطبيقات.

نحن نقدّر ملاحظات مطوّري الويب حول واجهة برمجة التطبيقات وما إذا كانت تعكس التجربة بدقة أكبر. مستودع GitHub الخاص بالتنقّل السلس هو أفضل مكان لتقديم هذه الملاحظات، ولكن يجب الإبلاغ عن الأخطاء الفردية في تنفيذ Chrome لهذه الميزة في أداة تتبُّع المشاكل في Chrome.

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

لم يتم بعد تحديد الطريقة التي سيتم بها تسجيل عمليات التنقّل السلس في CrUX بعد إطلاق الميزة. سنعلن عن التغييرات التي ستطرأ على CrUX عندما تتوفّر لدينا معلومات أكثر لمشاركتها هنا.

الملاحظات

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

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

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

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

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

الخاتمة

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

الإقرارات

صورة مصغّرة من Jordan Madrid على Unsplash

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