تجربة قياس عمليات التنقّل البسيطة

Barry Pollard

Michal Mocny

تاريخ النشر: 1 شباط (فبراير) 2023، تاريخ آخر تعديل: 30 آذار (مارس) 2026

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

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

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

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

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

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

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

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

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

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

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

يمكنك الاطّلاع على علامات التنقّل السلس وعلامات سرعة عرض أكبر محتوى مرئي (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 كسرعة عرض أول محتوى مرئي (FCP) في تلك الصفحة.
• يُرجى العِلم أنّه سيتم أيضًا إصدار إدخالات 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 من خلال التنقّل السلس. يخطّط العديد من المطوّرين لاختبار هذا المعيار الجديد، وسيأخذون الاعتبارات السابقة في الحسبان. في الوقت الحالي، يسمح بعض مقدّمي الخدمات أيضًا بإجراء قياسات محدودة لمقاييس الأداء استنادًا إلى طرق الاستدلال الخاصة بهم.

لمزيد من المعلومات حول كيفية قياس مقاييس التنقّل السلس، اطّلِع على قسم "قياس مؤشرات 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 لا يجب أخذها في الاعتبار عند قياس مقياس Largest Contentful Paint.

بالإضافة إلى ذلك، ننصحك بمعالجة الإدخال largestInteractionContentfulPaint من الإدخالات 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 على largestInteractionContentfulPaint. يجب ضبط قيمة مقياسَي INP وCLS على 0 كما هو الحال عند تحميل الصفحة.

يمكن بعد ذلك قياس مقاييس LCP وINP وCLS وتتبُّعها كالمعتاد (باستثناء استخدام interaction-contentful-paint لسرعة عرض أكبر محتوى مرئي (LCP) الذي يوفّر تطابقات interactionId). يمكن استخدام 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 لمدة تحميل أول بايت (TTFB) لأي عملية تنقّل سلس، وذلك بطريقة مشابهة لما ننصح به عند استعادة الصفحات من ميزة "التخزين المؤقت للصفحات". هذه هي الطريقة التي تستخدمها مكتبة 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 المقاييس التالية للتنقّلات السلسة:

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

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

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

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

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

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

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

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

الملاحظات

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

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

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

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

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

الخاتمة

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

الإقرارات

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

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