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

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

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

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

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

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

ما المقصود بالتنقّل الجزئي؟

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

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

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

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

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

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

ما هي تداعيات تفعيل عمليات الانتقال الجزئي في Chrome؟

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

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

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

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

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

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

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

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

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

بعد تفعيل تجربة التنقّل المبسط، سيتم إعداد تقارير عن المقاييس باستخدام واجهة برمجة التطبيقات 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 وقت التفاعل الأولي (على سبيل المثال، نقرة على زرّ) الذي بدأ عملية التنقّل الأوّلية.

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

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

لتضمين إدخالات مقياس التنقل البسيط، عليك تضمين 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:

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 الجديد. في المقابل، إذا تم تحميل صفحة جديدة من خلال رابط لصفحة معيّنة في عنوان URL للتنقّل البسيط، ستظهر صورة البانر بألوان جديدة، وبالتالي ستكون مؤهَّلة ليتم اعتبارها عنصر سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP).

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

كيف يمكن قياس TTFB؟

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

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

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

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

كيف يمكن قياس أداء الاشتراكات القديمة والجديدة؟

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

يجب قياس عمليات التنقّل اللينة بالإضافة إلى هذه الميزات للسماح لك بمعرفة كيفية قياسها في المستقبل، ومنحك الفرصة لتقديم ملاحظات إلى فريق 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 المقاييس التالية لعمليات التنقّل البسيطة:

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

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

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

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

كيف سيتم الإبلاغ عن عمليات التنقّل اللينة في تقرير تجربة المستخدم على Chrome؟

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

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

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

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

إضافة ملاحظات

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

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

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

الخلاصة

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

شكر وتقدير

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