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

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

Philip Walton

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

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

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

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

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

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

عادةً ما يكون قياس المقاييس أو الأحداث المخصّصة في أي أداة تحليلات عملية مكونة من ثلاث خطوات وهي:

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

بالنسبة إلى الخطوتين 1 و3، يمكنك الرجوع إلى وثائق أداة التحليلات على التعليمات بالنسبة للخطوة 2، يمكنك استخدام مكتبة 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);

تجنب المتوسطات

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

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

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

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

يمكنك التأكّد من إمكانية الإبلاغ عن التوزيع.

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

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

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

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

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

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

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

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

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

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

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

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

نسخة التغييرات التي أجريتها

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

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

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

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

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

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

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

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

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

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

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

تم تصميم جميع واجهات برمجة التطبيقات المستخدَمة لقياس مقاييس Core Web Vitals صُممت لدعم تحميل النص البرمجي غير المتزامن والمؤجل (عبر buffered)، لذا لا داعي للعجلة لتحميل النصوص البرمجية مبكرًا.

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

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

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

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

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

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

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

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

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

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

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