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

Barry Pollard
Michal Mocny

تاريخ النشر: 1 شباط (فبراير) 2023، تاريخ آخر تعديل: 14 أيار (مايو) 2026

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

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

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

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

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

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

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

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

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

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

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

علامة تنقّل غير مكتملة في "لوحة الأداء" مع تتبُّع من youtube.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يمكن لمالكي المواقع الإلكترونية اختيار تضمين مرحلة التجربة والتقييم في صفحاتهم للجميع أو لمجموعة فرعية فقط من المستخدمين. يُرجى الانتباه إلى قسم الآثار المترتبة السابق لمعرفة كيفية تأثير ذلك في طريقة عرض مقاييسك، خاصةً إذا فعّلت مرحلة التجربة والتقييم هذه لنسبة كبيرة من المستخدمين. يُرجى العِلم أنّ CrUX سيواصل تسجيل المقاييس بالطريقة الحالية بغض النظر عن إعداد التنقّل السلس، وبالتالي لن يتأثر بهذه الآثار. يجب أيضًا ملاحظة أنّ التجارب الأصلية تقتصر أيضًا على تفعيل الميزات التجريبية على% 0.5 كحد أقصى من جميع عمليات تحميل صفحات Chrome كمتوسط على مدار 14 يومًا، ولكن من المفترض ألا يشكّل ذلك مشكلة إلا للمواقع الإلكترونية الكبيرة جدًا.

التحقّق من توفّر 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 نفسه عدة مرات خلال فترة استخدام تطبيق من صفحة واحدة). يمكن البحث عن ذلك باستخدام واجهة برمجة التطبيقات PerformanceEntry:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

الإبلاغ عن عنوان 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.

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

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

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

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

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

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

لقياس "مؤشرات أداء الويب الأساسية"، استمع إلى إدخالات soft-navigation وأعِد ضبط المقاييس عند تلقّيها. يمكن إصدار FCP استنادًا إلى presentationTime ويمكن إعداد LCP على largestInteractionContentfulPaint. يجب ضبط قيمة مقياسَي INP وCLS على 0 كما هو الحال عند تحميل الصفحة.

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

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

لقد تم قياس بعض المقاييس تقليديًا طوال مدة بقاء الصفحة: على سبيل المثال، يمكن أن يتغيّر مقياس LCP إلى أن يحدث تفاعل. يمكن تعديل مقياسَي 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 باستخدام المنهجيتَين؟

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

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

بالنسبة إلى مقياس 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 المقاييس التالية للتنقّلات السلسة:

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

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

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

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

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

لم يتم بعد تحديد الطريقة التي سيتم بها تسجيل عمليات التنقّل السلس في CrUX بعد إطلاق الميزة. ليس من الضروري أن يتم التعامل معها بالطريقة نفسها التي يتم بها التعامل مع عمليات التنقّل "الصعبة" الحالية.

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

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

الملاحظات

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

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

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

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

الخاتمة

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

الإقرارات

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

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