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

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

Philip Walton

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

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

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

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

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

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

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

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

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

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

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

تختلف القيمة التي يتم تسجيلها لمقياس CLS من المختبر (Lighthouse) عن القيمة التي يتم تسجيلها من المجال (بيانات 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 لصفحتك عند النسبة المئوية الخامسة والسبعين.

بالإضافة إلى ذلك، ليس عليك احتساب أكبر عنصر مصدر في كل مرة يحدث فيها تغيير، بل عليك إجراء ذلك فقط عندما تكون مستعدًا لإرسال قيمة 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 المرشّح بشكل كبير من مستخدم إلى آخر.

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

تحديد العنصر المرشّح ليكون أكبر عنصر مرئي

لتحديد العنصر المرشّح ليكون العنصر الأكبر مرئيًا في JavaScript، يمكنك استخدام Largest Contentful Paint API، وهي واجهة برمجة التطبيقات نفسها التي تستخدمها لتحديد قيمة وقت 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.

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

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

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

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

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)، قد تحتاج إلى جمع معلومات عن العنصر الذي يتم التفاعل معه، ونوع التفاعل، والتوقيت، وloadState، ومراحل التفاعل، والمزيد (مثل بيانات صور متحركة يستغرق عرضها وقتًا طويلاً).

تعرض أداة إنشاء بيانات تحديد المصدر 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);

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

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

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

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

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

ملخّص

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

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

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