كيفية قياس "مؤشرات أداء الويب" باستخدام أداة الإحصاءات الحالية
إنّ امتلاك القدرة على قياس أداء صفحاتك في الواقع وإعداد تقارير عنه أمر مهم لتشخيص الأداء وتحسينه بمرور الوقت. بدون بيانات الحقول، من المستحيل معرفة ما إذا كانت التغييرات التي تجريها على موقعك الإلكتروني تحقّق النتائج المطلوبة فعلاً.
يتيح العديد من مقدّمي إحصاءات مراقبة المستخدِمين الفعليين (RUM) الرائجين استخدام مقاييس مؤشرات أداء الويب الأساسية في أداتهم (بالإضافة إلى العديد من مؤشرات أداء الويب الأخرى). إذا كنت تستخدم حاليًا إحدى أدوات تحليل RUM هذه، ستكون في وضع جيد لتقييم مدى استيفاء الصفحات على موقعك الإلكتروني للحدود القصوى المُقترَحة لمؤشرات Core Web Vitals ومنع حدوث تراجعات في الأداء في المستقبل.
على الرغم من أنّنا ننصحك باستخدام أداة إحصاءات متوافقة مع مقاييس Core Web Vitals، إذا كانت أداة الإحصاءات التي تستخدمها حاليًا لا تتوافق معها، ليس عليك بالضرورة التبديل. توفّر جميع أدوات الإحصاءات تقريبًا طريقة لتحديد وقياس مقاييس أو أحداث مخصّصة، ما يعني أنّه يمكن أن تستخدِم على الأرجح مقدّم خدمة الإحصاءات الحالي لقياس مقاييس "مؤشرات أداء الويب الأساسية" وإضافتها إلى تقارير الإحصاءات ولوحات البيانات الحالية.
يتناول هذا الدليل أفضل الممارسات لقياس مقاييس "مؤشرات أداء الويب الأساسية" (أو أي مقاييس مخصّصة) باستخدام أداة إحصاءات تابعة لجهة خارجية أو أداة إحصاءات داخلية. ويمكن أن يُستخدم أيضًا كدليل لمورّدي الإحصاءات الذين يريدون إضافة دعم "مؤشرات أداء الويب الأساسية" إلى خدمتهم.
استخدام المقاييس أو الأحداث المخصّصة
كما ذكرنا أعلاه، تتيح لك معظم أدوات الإحصاءات قياس البيانات المخصّصة. إذا كانت أداة التحليلات تتيح ذلك، من المفترض أن تتمكّن من قياس كلّ من مقاييس "مؤشرات أداء الويب الأساسية" باستخدام هذه الآلية.
إنّ قياس المقاييس أو الأحداث المخصّصة في أداة تحليلات يمثّل بشكل عام عملية تتم على ثلاثة مراحل:
- حدِّد المقياس المخصّص أو سجِّله في صفحة المشرف في أداتك (إذا لزم الأمر). (ملاحظة: لا يتطلّب بعض مقدمي تحليلات الويب تحديد المقاييس المخصّصة مسبقًا.)
- احتسِب قيمة المقياس في رمز JavaScript للواجهة الأمامية.
- أرسِل قيمة المقياس إلى الخلفية في خدمة الإحصاءات، مع التأكّد من أنّ الاسم أو رقم التعريف يتطابقان مع ما تم تحديده في الخطوة 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" استجابةً لإدخال المستخدِم، ولكن إذا كان رمز "إحصاءات Google" يُجري الكثير من قياسات DOM أو يستخدم واجهات برمجة تطبيقات أخرى تتطلّب معالجة مكثّفة، يمكن أن يتسبّب رمز "إحصاءات Google" نفسه في ضعف استجابة الإدخال. بالإضافة إلى ذلك، إذا كان ملف JavaScript الذي يحتوي على رمز الإحصاءات كبيرًا، يمكن أن يؤدي تنفيذ هذا الملف إلى حظر سلسلة المهام الرئيسية والتأثير سلبًا في التفاعل إلى اللوحة التالية (INP) للصفحة.
استخدام واجهات برمجة التطبيقات غير المحظورة
واجهات برمجة التطبيقات مثل
sendBeacon()
و
requestIdleCallback()
مصمّمة خصيصًا لتشغيل المهام غير المُهمّة بطريقة لا تؤدي إلى
حظر المهام المُهمّة للمستخدم.
وتعدّ واجهات برمجة التطبيقات هذه أدوات رائعة لاستخدامها في مكتبة إحصاءات مراقبة المستخدمين في الوقت الفعلي.
بشكل عام، يجب إرسال جميع إشارات الإحصاءات باستخدام واجهة برمجة التطبيقات sendBeacon()
(إذا كانت متاحة)، ويجب تشغيل جميع رموز قياس الإحصاءات التلقائية أثناء
فترات السكون.
عدم تتبُّع أكثر من ما تحتاجه
يعرض المتصفّح الكثير من بيانات الأداء، ولكن لا يعني توفّر البيانات ضرورة تسجيلها وإرسالها إلى خوادم الإحصاءات.
على سبيل المثال، تقدّم Resource Timing API بيانات توقيت تفصيلية لكلّ مورد يتم تحميله على صفحتك. ومع ذلك، من غير المحتمل أن تكون كل هذه البيانات مفيدة أو ضرورية في تحسين أداء تحميل الموارد.
باختصار، لا تتتبّع البيانات فقط لأنّها متوفّرة، بل تأكَّد من أنّها ستُستخدَم قبل استخدام الموارد لتتبّعها.