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

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

Philip Walton

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

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

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

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

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

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

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

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

بالنسبة إلى الخطوتَين 1 و3، يمكنك الرجوع إلى مستندات أداة الإحصاءات للحصول على تعليمات. بالنسبة إلى الخطوة 2، يمكنك استخدام مكتبة JavaScript الخاصة بميزة web-vitals لحساب قيمة كل مقياس من مقاييس "مؤشرات أداء الويب الأساسية".

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

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 من القائمة الكاملة والمرتّبة لجميع القيم في هذا التقرير هي الشريحة المئوية %75 لهذا المقياس، وسيكون هذا هو الحال بغض النظر عن كيفية تقسيم بياناتك (حسب نوع الجهاز ونوع الاتصال البلد وما إلى ذلك).

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

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

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

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

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

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

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

تتبُّع الأداء بمرور الوقت

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

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

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

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

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

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

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

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

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

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

اتّبِع دائمًا هذه المبادئ عند نشر رمز تحليلات مراقبة المستخدمين في الوقت الفعلي على موقعك الإلكتروني في مرحلة الإنتاج:

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

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

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

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

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

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

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

واجهات برمجة التطبيقات مثل sendBeacon() و requestIdleCallback() مصمّمة خصيصًا لتشغيل المهام غير المُهمّة بطريقة لا تؤدي إلى حظر المهام المُهمّة للمستخدم.

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

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

عدم تتبُّع أكثر من ما تحتاجه

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

على سبيل المثال، تتيح Resource Timing API بيانات توقيت تفصيلية لكل مورد يتم تحميله على صفحتك. ومع ذلك، من غير المحتمل أن تكون كل هذه البيانات مفيدة أو ضرورية في تحسين أداء تحميل الموارد.

باختصار، لا تتتبّع البيانات فقط لأنّها متوفّرة، بل تأكَّد من أنّها ستُستخدَم قبل استخدام الموارد لتتبّعها.