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

Barry Pollard

Michal Mocny

تاريخ النشر: 1 فبراير 2023، تاريخ آخر تعديل: 2 سبتمبر 2026

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

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

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

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

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

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

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

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

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

أدوات مطوّري البرامج التي تتوافق مع التنقّل السلس

أضفنا إمكانية استخدام التنقّلات السلسة إلى لوحة "الأداء" في DevTools ضمن عرض المقاييس المباشرة، وفي عرض التتبُّع مع الإحصاءات وإمكانية استخدام العلامات:

كيف يتيح Chrome عمليات التنقّل السلس للمطوّرين؟

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

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

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

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

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

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

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

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

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

يتم تفعيل ميزة "عمليات التنقّل السلس" تلقائيًا بدءًا من الإصدار 151 من Chrome.

إتاحة واجهة برمجة التطبيقات Soft Navigations API لرصد الميزات

يمكنك استخدام الرمز التالي لاختبار ما إذا كانت واجهة برمجة التطبيقات متوافقة:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

أو بدلاً من ذلك:

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

يجب ضبط هذا الحقل على أنّه كل إدخال soft-navigation، ويجب استخدامه لتسجيل المقاييس إلى أن يتم تلقّي إدخال soft-navigation التالي.

الإبلاغ عن عنوان 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 لا يجب أخذها في الاعتبار عند قياس مقياس "أكبر محتوى مرئي".

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

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

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

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

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

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

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

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

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

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

كيفية قياس TTFB؟

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

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

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

هل يجب قياس Core Web Vitals باستخدام المنهجيتَين؟

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

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

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

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

استخدام مكتبة web-vitals لقياس مؤشرات Core Web Vitals لعمليات التنقّل السلس

أسهل طريقة لمراعاة كل الفروق الدقيقة هي استخدام مكتبة JavaScript web-vitals التي تتيح التنقّل السلس اعتبارًا من الإصدار 6.0.0. يمكن قياس ذلك بالطريقة التالية (مع استبدال 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 التي تعرضها جميع الأدوات بعد إطلاق واجهة برمجة التطبيقات.

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

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

كيفية التعامل مع عمليات التنقّل السلس في المتصفّحات الأخرى

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

يمكن استخدام Navigation API لتتبُّع التغييرات في عناوين URL، ما قد يتيح تقسيم مقياس INP حسب عنوان URL (وكذلك مقياس CLS، على الرغم من أنّه متاح فقط في Chromium في الوقت الحالي، لذا لن يتم قياسه على أي حال). ومع ذلك، لا يعالج ذلك مقاييس العرض (FCP وLCP) التي لا يمكن إلا تقريبها.

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

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

الملاحظات

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

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

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

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

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

الخاتمة

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

الإقرارات

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

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