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

Barry Pollard

Michal Mocny

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

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

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

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

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

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

ما المقصود بالتنقّل السلس؟

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

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

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

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

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

• سيتم إرسال حدث soft-navigation PerformanceTiming بعد رصد كل عملية تنقّل سلس.
• سيتم إصدار interaction-contentful-paint جديد بعد التفاعلات التي تؤدي إلى عرض محتوى مفيد. يمكن استخدام هذا المقياس لقياس سرعة عرض أكبر محتوى مرئي (LCP) لعمليات التنقّل السلس عندما يمتدّ عرض المحتوى على عملية تنقّل سلس. يُرجى العِلم أنّ التنفيذ الأصلي لعملية إعادة الضبط هذه كان يعيد ضبط المقياس largest-contentful-paint، ما يسمح بإعادة إصداره، ولكنّنا استقررنا على هذا النهج البديل لتبسيطه وتوسيع نطاقه في المستقبل.
• ستتم إضافة السمة navigationId إلى كل توقيت من توقيتات الأداء (first-paint وfirst-contentful-paint وlargest-contentful-paint وinteraction-contentful-paint وfirst-input-delay وevent وlayout-shift) بما يتوافق مع إدخال التنقّل الذي يرتبط به الحدث، ما يتيح احتساب Largest Contentful Paint (LCP) وCumulative Layout Shift (CLS) وInteraction to Next Paint (INP) وإسنادها إلى عنوان URL الصحيح.

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

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

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

• يمكن تقسيم مقياسَي CLS وINP حسب عنوان URL للتنقّل السلس، بدلاً من قياسهما على مدار مدة دورة حياة الصفحة بأكملها.
• تمّت تسوية الإدخال largest-contentul-paint من قبل في تفاعل، لذا يتمّ استخدامه فقط لقياس أول عملية تنقّل "صعبة" في LCP، وبالتالي لا حاجة إلى منطق إضافي لتغيير طريقة قياس ذلك.
• سيتم إرسال مقياس interaction-contentful-paint الجديد من التفاعلات، ويمكن استخدامه لقياس مقياس Largest Contentful Paint (LCP) لعمليات التنقّل السلس.
• لتحديد مصدر التنقّلات السلسة على أنّها عنوان URL الصحيح، قد تحتاج إلى أخذ السمة الجديدة navigationID في عناصر الأداء في الاعتبار في رمز تطبيقك باستخدام هذه العناصر.
• لن تتوافق هذه الواجهة مع جميع المستخدمين، خاصةً في إصدارات Chrome القديمة ومع المستخدمين الذين يستعملون متصفّحات أخرى. يُرجى العِلم أنّ بعض المستخدمين قد لا يبلغون عن مقاييس التنقّل السلس، حتى إذا أبلغوا عن مقاييس "مؤشرات أداء الويب الأساسية".
• بما أنّها ميزة تجريبية جديدة غير مفعّلة تلقائيًا، على المواقع الإلكترونية اختبارها للتأكّد من عدم حدوث آثار جانبية غير مقصودة.

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

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

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

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

بالنسبة إلى المطوّرين، يمكن تفعيل هذه الميزة من خلال تفعيل العلامة ميزات تجريبية لمنصة الويب على chrome://flags/#soft-navigation-heuristics أو باستخدام وسيطات سطر الأوامر --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution عند تشغيل Chrome.

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

يمكن لمالكي المواقع الإلكترونية اختيار تضمين التجربة الأصلية في صفحاتهم للجميع أو لمجموعة فرعية فقط من المستخدمين. يُرجى الانتباه إلى قسم الآثار المترتبة السابق لمعرفة كيفية تأثير ذلك في طريقة عرض مقاييسك، خاصةً إذا فعّلت هذه التجربة الأصلية لنسبة كبيرة من المستخدمين. يُرجى العِلم أنّ CrUX سيواصل تسجيل المقاييس بالطريقة الحالية بغض النظر عن إعداد التنقّل السلس، وبالتالي لن يتأثّر بهذه الآثار. يجب أيضًا ملاحظة أنّ التجارب الأصلية تقتصر أيضًا على تفعيل الميزات التجريبية على% 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:

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

سيستمر عرض التوقيتات بالنسبة إلى وقت بدء التنقّل "الثابت" الأصلي. لذلك، لاحتساب مقياس LCP للتنقّل السلس مثلاً، عليك أخذ توقيت interaction-contentful-paint وطرح وقت بدء التنقّل السلس المناسب كما هو موضّح بالتفصيل سابقًا للحصول على توقيت مرتبط بالتنقّل السلس. على سبيل المثال، بالنسبة إلى مقياس 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: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

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

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

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

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

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

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

كيفية قياس وقت استجابة أول بايت؟

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

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

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

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

كيفية قياس الأداء القديم والجديد

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

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

بالنسبة إلى مقياس LCP، يعني ذلك أخذ إدخالات largest-contentful-paint فقط في الاعتبار للطريقة القديمة، وإدخالات largest-contentful-paint وinteraction-contentful-paint للطريقة الجديدة.

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

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

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

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

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

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

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

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

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

الملاحظات

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

• معايير التقييم والتسوية الخاصة بعمليات التنقّل السلس:
• المشاكل المتعلّقة بتنفيذ Chrome لهذه الإرشادات
• يمكنك إرسال ملاحظات عامة حول مقاييس Web Vitals إلى web-vitals-feedback@googlegroups.com.

سجلّ التغيير

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

الخاتمة

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

الإقرارات

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

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