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

Barry Pollard

Yoav Weiss

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

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

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

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

ما هو المقصود بميزة "التنقّل السلس"؟

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

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

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

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

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

• سيتمّ بثّ حدث soft-navigation PerformanceTiming بعد رصد كلّ عملية تنقّل سلسة.
• ستوفّر Performance API إمكانية الوصول إلى إدخال توقيت soft-navigation، كما يتم إصداره من خلال الحدث soft-navigation PerformanceTiming.
• ستتم إعادة ضبط مقاييس First Paint (FP) وFirst Contentful Paint (FCP) وLargest Contentful Paint (LCP)، وإعادة إرسالها عند حدوثها في المرات المناسبة التالية. (ملاحظة: لا يتمّ تنفيذ FP وFCP).
• ستتم إضافة سمة navigationId إلى كلّ من أوقات الأداء (first-paint وfirst-contentful-paint وlargest-contentful-paint وfirst-input-delay وevent وlayout-shift) التي تتوافق مع إدخال التنقّل المرتبط بالحدث، ما يسمح بحساب متغيّرات التصميم التراكمية (CLS) والتفاعل إلى اللوحة التالية (INP).

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

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

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

• قد تتم إعادة إصدار أحداث FP وFCP وLCP إضافية للتنقّلات الناعمة. سيتجاهل تقرير تجربة مستخدمي Chrome (CrUX) هذه القيم الإضافية، ولكن قد يؤثر ذلك في أيّ عمليات مراقبة لقياس المستخدِمين الفعليين على موقعك الإلكتروني. تحقّق من مزوّد RUM إذا كانت لديك أي مخاوف بشأن ما إذا كان هذا الإجراء سيؤثّر في هذه القياسات. اطّلِع على القسم الخاص بقياس "مؤشرات أداء الويب الأساسية" لعمليات التنقّل السلسة.
• قد تحتاج إلى مراعاة سمة navigationID الجديدة (والاختيارية) في إدخالات الأداء في رمز تطبيقك الذي يستخدم هذه الإدخالات.
• لن يتوفّر هذا الوضع الجديد إلا في المتصفّحات المستندة إلى Chromium. على الرغم من أنّ العديد من المقاييس الجديدة لا تتوفّر إلا في المتصفّحات المستندة إلى Chromium، يتوفّر بعضها (FCP وLCP) في المتصفّحات الأخرى، وقد لا يكون الجميع قد أجرى ترقية إلى أحدث إصدار من المتصفّحات المستندة إلى Chromium. لذا، يُرجى العِلم أنّ بعض المستخدمين قد لا يُبلغون عن مقاييس التنقّل السلس.
• بما أنّ هذه الميزة جديدة وتجريبية وغير مفعّلة تلقائيًا، على المواقع الإلكترونية اختبارها للتأكّد من عدم حدوث أيّ آثار جانبية أخرى غير مقصودة.

لمزيد من المعلومات عن كيفية قياس مقاييس عمليات التنقّل السلس، اطّلِع على قسم "قياس مؤشرات أداء الويب الأساسية لكل عملية تنقّل سلسة".

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

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

يمكن للمطوّرين تفعيل هذه الميزة من خلال تفعيل علامة ميزات منصة الويب التجريبية في chrome://flags/#enable-experimental-web-platform-features أو باستخدام الوسيطة --enable-experimental-web-platform-features لسطر الأوامر عند تشغيل Chrome.

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

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

الإبلاغ عن عمليات التنقّل البسيطة

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

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

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

الإبلاغ عن المقاييس حسب عنوان URL المناسب

بما أنّه لا يمكن رؤية عمليات التنقّل الناعمة إلا بعد حدوثها، يجب الانتهاء من بعض المقاييس عند حدوث هذا الحدث، ثم إعداد تقارير عن عنوان URL السابق، لأنّ عنوان URL الحالي سيعرض الآن عنوان URL المعدَّل للصفحة الجديدة.

يمكن استخدام سمة navigationId للعنصر PerformanceEntry المناسب لربط الحدث بعنوان URL الصحيح. يمكن البحث عن ذلك باستخدام واجهة برمجة التطبيقات PerformanceEntry API:

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;

يجب استخدام هذا الإجراء pageUrl لإعداد تقارير عن المقاييس استنادًا إلى عنوان URL الصحيح، بدلاً من عنوان URL الحالي الذي ربما استخدموه في السابق.

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

يمكن الحصول على وقت بدء التنقّل بطريقة مشابهة:

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

يشير المقياس startTime إلى وقت التفاعل الأوّلي (مثل النقر على زر) الذي بدأ التنقّل السلس.

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

قياس "مؤشرات أداء الويب الأساسية" لكل عملية تنقّل سلسة

لتضمين إدخالات مقياس التنقّل السلس، عليك تضمين includeSoftNavigationObservations: true في طلب observe من مراقب الأداء.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

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

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

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

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

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

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

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

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

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

كيف يتم قياس وقت استجابة خادم الويب؟

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

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

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

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

كيف يتم قياس كلا الإصدارَين القديم والجديد؟

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

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

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

استخدام مكتبة 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';

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});

تأكَّد من تسجيل المقاييس وفقًا لعنوان URL الصحيح كما هو موضّح سابقًا.

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

هل ستصبح هذه التغييرات جزءًا من قياسات "مؤشرات أداء الويب الأساسية"؟

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

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

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

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

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

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

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

ملاحظات

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

• الإجراءات الإجرائية للتنقلات البسيطة ومعاييرها
• مشاكل تنفيذ Chrome لهذه الأساليب الارشيفية
• ملاحظات عامة حول مقياسات الأداء الرئيسية للويب على العنوان web-vitals-feedback@googlegrouops.com.

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

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

الخاتمة

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

الشكر والتقدير

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