أفضل الممارسات لقياس "مؤشرات أداء الويب" في هذا الحقل

كيفية قياس "مؤشرات أداء الويب" باستخدام أداة الإحصاءات الحالية

Philip Walton

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

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

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

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

استخدام مقاييس أو أحداث مخصّصة

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

يتكوّن قياس الأحداث أو المقاييس المخصّصة في أداة الإحصاءات بشكل عام من ثلاث خطوات:

1. حدِّد أو سجِّل المقياس المخصّص في مشرف الأداة (إذا لزم الأمر). (ملاحظة: لا يشترط جميع مقدّمي خدمات التحليلات تحديد مقاييس مخصّصة مسبقًا).
2. احسب قيمة المقياس في رمز JavaScript للواجهة الأمامية.
3. أرسِل قيمة المقياس إلى خلفية "إحصاءات Google"، مع التأكّد من تطابق الاسم أو رقم التعريف مع ما تم تحديده في الخطوة 1 (مرة أخرى، إذا لزم الأمر).

بالنسبة إلى الخطوتين 1 و3، يمكنك الرجوع إلى مستندات أداة الإحصاءات للحصول على التعليمات. لتنفيذ الخطوة الثانية، يمكنك استخدام مكتبة JavaScript لمؤشرات الويب لحساب قيمة كل مقياس من مقاييس "مؤشرات أداء الويب الأساسية".

يوضح نموذج الرمز البرمجي التالي مدى سهولة تتبع هذه المقاييس في الترميز وإرسالها إلى خدمة إحصاءات.

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

تجنُّب المعدلات

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

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

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

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

يُرجى التأكُّد من أنّه يمكنك الإبلاغ عن عملية توزيع.

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

لضمان استيفاء الحدود الدنيا المقترَحة لمؤشرات أداء الويب الأساسية، يجب أن يعرض تقريرك قيمة كل مقياس عند الشريحة المئوية الخامسة والسبعين.

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

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

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

إرسال بياناتك في الوقت المناسب

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

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

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

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

مراقبة الأداء بمرور الوقت

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

إصدار التغييرات

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

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

أجرِ اختبارات

يمكنك إجراء خطوة أخرى لتحديد النُسخ من خلال تتبُّع عدة نُسخ (أو تجارب) في الوقت نفسه.

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

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

التأكّد من أنّ القياس لا يؤثّر في الأداء

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

اتبع دائمًا المبادئ التالية عند نشر الرمز البرمجي لتحليلات RUM على موقع الإنتاج لديك:

تأجيل إحصاءاتك

ويجب دائمًا تحميل رمز "إحصاءات Google" البرمجي بطريقة غير متزامنة لا تمنع الحظر، وبوجه عام يجب تحميلها في النهاية. إذا تم تحميل رمز التحليلات بطريقة حظر، قد يؤثر ذلك سلبًا في سرعة LCP

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

في حال قياس مقياس يتعذّر حسابه لاحقًا في المخطط الزمني لتحميل الصفحة، عليك تضمين الرمز البرمجي المطلوب تشغيله مبكرًا في <head> من المستند (حتى لا يكون طلبًا لحظر العرض) وتأجيل الباقي. يجب عدم تحميل جميع التحليلات في وقت مبكر لمجرد أن هناك مقياس واحد يتطلب ذلك.

عدم إنشاء مهام طويلة

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

استخدام واجهات برمجة تطبيقات لا تحظر المحتوى

تم تصميم واجهات برمجة التطبيقات مثل sendBeacon() و requestIdleCallback() خصيصًا لتشغيل المهام غير الأساسية بطريقة لا تمنع المهام الأساسية للمستخدمين.

تعتبر واجهات برمجة التطبيقات هذه أدوات رائعة للاستخدام في مكتبة تحليلات RUM.

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

لا تتبّع أكثر مما تحتاج إليه.

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

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

باختصار، لا تتبع البيانات لأنها موجودة هناك، وتأكد من استخدام البيانات قبل أن تستهلك الموارد التي تتبعها.