تصحيح أخطاء الأداء في الحقل

تعرَّف على كيفية تحديد مصدر بيانات الأداء باستخدام معلومات تصحيح الأخطاء لمساعدتك في تحديد مشاكل المستخدمين الفعليين وحلّها باستخدام الإحصاءات.

Philip Walton

توفّر Google فئتَين من الأدوات لقياس الأداء وتصحيح الأخطاء فيه:

• أدوات المختبر: أدوات مثل Lighthouse، حيث يتم تحميل صفحتك في بيئة اصطناعية يمكنها محاكاة ظروف مختلفة (مثل شبكة تتحكّم في معدّل نقل البيانات وجهاز جوّال منخفض الأداء).
• أدوات الاستخدام الفعلي: أدوات مثل تقرير تجربة مستخدم Chrome (CrUX)، الذي يستند إلى بيانات مجمّعة من مستخدمي Chrome الفعليين. (يُرجى العلم أنّ البيانات الفعلية التي يتم الإبلاغ عنها من خلال أدوات مثل إحصاءات PageSpeed وSearch Console يتم الحصول عليها من بيانات CrUX).

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

تُمثّل بيانات CrUX الأداء الفعلي لصفحتك بشكل أفضل، ولكن من غير المرجّح أن تساعدك معرفة نتائج CrUX في معرفة كيفية تحسين أدائك.

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

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

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

واجهات برمجة التطبيقات لتحديد المصدر وتصحيح الأخطاء

متغيّرات التصميم التراكمية (CLS)

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

اطّلِع على التقرير التالي من "إحصاءات PageSpeed":

تختلف القيمة المسجّلة لمقياس CLS من المختبر (Lighthouse) مقارنةً بقيمة CLS من الميدان (بيانات CrUX) تمامًا، وهذا منطقي إذا أخذت في الاعتبار أنّ الصفحة قد تحتوي على الكثير من المحتوى التفاعلي الذي لا يتم استخدامه عند اختباره في Lighthouse.

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

الحصول على مصدر متغيّرات التصميم

يتمّ عرض واجهة LayoutShiftAttribution في كلّ إدخال layout-shift يُرسِله Layout Instability API.

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

في ما يلي بعض الأمثلة على الرموز التي تسجِّل كلّ تغيير في التصميم بالإضافة إلى العناصر التي تمّ تغييرها:

new PerformanceObserver((list) => {
  for (const {value, startTime, sources} of list.getEntries()) {
    // Log the shift amount and other entry info.
    console.log('Layout shift:', {value, startTime});
    if (sources) {
      for (const {node, curRect, prevRect} of sources) {
        // Log the elements that shifted.
        console.log('  Shift source:', node, {curRect, prevRect});
      }
    }
  }
}).observe({type: 'layout-shift', buffered: true});

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

لا يتمثل الهدف في تحديد كلّ تغيير في التنسيق يحدث لكلّ مستخدِم وإصلاحه، بل في تحديد التغييرات التي تؤثّر في أكبر عدد من المستخدِمين وبالتالي تساهم بشكلٍ أكبر في مقياس CLS لصفحتك عند نسبة %75.

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

يأخذ الرمز التالي قائمة من إدخالات layout-shift التي ساهمت في متغيّرات التصميم التراكمية (CLS) ويعرض العنصر المصدر الأكبر من التغيير الأكبر:

function getCLSDebugTarget(entries) {
  const largestEntry = entries.reduce((a, b) => {
    return a && a.value > b.value ? a : b;
  });
  if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
    const largestSource = largestEntry.sources.reduce((a, b) => {
      return a.node && a.previousRect.width * a.previousRect.height >
          b.previousRect.width * b.previousRect.height ? a : b;
    });
    if (largestSource) {
      return largestSource.node;
    }
  }
}

بمجرد تحديد العنصر الأكبر الذي يساهم في أكبر تحول، يمكنك إبلاغ أداة التحليلات بذلك.

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

بعد تحديد السبب الأساسي للتحولات في تلك العناصر وإصلاحها، ستبدأ شفرة التحليلات في الإبلاغ عن التحولات الأصغر على أنها "أسوأ" التقلبات التي تمت لصفحاتك. في النهاية، ستكون جميع التغيُّرات التي يتم الإبلاغ عنها صغيرة بدرجة كافية لتكون صفحاتك ضمن الحد "الجيد" الذي يبلغ 0.1.

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

• وقت أكبر وردية
• مسار عنوان URL في وقت التغيير الأكبر (بالنسبة إلى المواقع الإلكترونية التي تُعدِّل عنوان URL ديناميكيًا، مثل تطبيقات الصفحة الواحدة)

سرعة عرض أكبر محتوى مرئي (LCP)

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

يُرجى العِلم أنّه من الممكن تمامًا، بل من الشائع جدًا، أن يختلف العنصر المُحتمَل لقياس LCP من مستخدم إلى آخر، حتى بالنسبة إلى الصفحة نفسها.

ثمة أسباب متعدّدة لحدوث ذلك:

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

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

تحديد العنصر المُحتمَل ليكون LCP

لتحديد عنصر مرشح LCP في JavaScript، يمكنك استخدام أكبر واجهة برمجة تطبيقات لـ Contentful Paint، وهي واجهة برمجة التطبيقات نفسها التي تستخدمها لتحديد قيمة الوقت LCP.

عند ملاحظة إدخالات largest-contentful-paint، يمكنك تحديد العنصر الحالي المرشّح لسرعة عرض أكبر محتوى مرئي (LCP) من خلال الاطّلاع على السمة element للإدخال الأخير:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];

  console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});

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

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

مدى استجابة الصفحة لتفاعلات المستخدم (INP)

في ما يلي أهم المعلومات التي يجب تسجيلها في حقل INP:

1. العنصر الذي تم التفاعل معه
2. سبب نوع التفاعل
3. وقت حدوث هذا التفاعل

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

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

تسجِّل التعليمة البرمجية التالية العنصر المستهدَف ووقت إدخال INP.

function logINPDebugInfo(inpEntry) {
  console.log('INP target element:', inpEntry.target);
  console.log('INP interaction type:', inpEntry.name);
  console.log('INP time:', inpEntry.startTime);
}

يُرجى العِلم أنّ هذا الرمز لا يوضّح كيفية تحديد إدخال event الذي يمثّل إدخال INP ، لأنّ هذا المنطق أكثر تعقيدًا. ومع ذلك، يوضّح القسم التالي كيفية الحصول على هذه المعلومات باستخدام مكتبة JavaScript web-vitals.

الاستخدام مع مكتبة JavaScript لـ web-vitals

تقدم الأقسام السابقة بعض الاقتراحات العامة وأمثلة على التعليمات البرمجية لتسجيل معلومات تصحيح الأخطاء لتضمينها في البيانات التي تُرسِلها إلى أداة التحليل.

منذ الإصدار الثالث، أصبحت مكتبة web-vitals تتضمّن إصدارًا لتحديد المصدر يعرض كل هذه المعلومات، بالإضافة إلى بعض الإشارات الإضافية.

يوضّح مثال الرمز البرمجي التالي كيفية ضبط مَعلمة حدث إضافية (أو سمة مخصّصة) تحتوي على سلسلة debugging مفيدة للمساعدة في تحديد السبب الأساسي لمشاكل الأداء.

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

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'CLS':
      eventParams.debug_target = attribution.largestShiftTarget;
      break;
    case 'LCP':
      eventParams.debug_target = attribution.element;
      break;
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      break;
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

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

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

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

يعرض نموذج تحديد المصدر web-vitals معلومات تحديد مصدر إضافية، كما هو موضّح في المثال التالي لنموذج تحديد المصدر INP:

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

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      eventParams.debug_type = attribution.interactionType;
      eventParams.debug_time = attribution.interactionTime;
      eventParams.debug_load_state = attribution.loadState;
      eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
      eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
      eventParams.debug_presentation_delay =  Math.round(attribution.presentationDelay);
      break;

    // Additional metric logic...
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

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

إعداد تقارير عن البيانات وتصورها

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

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

بالنسبة إلى "إحصاءات Google‏ 4"، يمكنك الاطّلاع على المقالة المخصّصة عن كيفية إجراء طلبات بحث وعرض البيانات باستخدام BigQuery.

ملخّص

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

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

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

أخيرًا، إذا كنت تعتقد أنّ هناك ثغرات في قدرتك على تصحيح أخطاء هذه المقاييس بسبب عدم توفّر ميزات أو معلومات في واجهات برمجة التطبيقات نفسها، يُرجى إرسال ملاحظاتك إلى web-vitals-feedback@googlegroups.com.