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

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

Philip Walton

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

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

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

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

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

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

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

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

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

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

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

تعرض "إحصاءات PageSpeed" بيانات كلٍّ من الحقول والميزة الاختبارية في حال توفّرها، وقد تختلف هذه البيانات

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

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

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

تظهر واجهة LayoutShiftAttribution في كل إدخال layout-shift التي تنبعثها واجهة برمجة التطبيقات عدم استقرار التنسيق.

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

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

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

لتحديد عنصر مرشح 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، يمكن أن يتغيّر عنصر ترشيح LCP من خلال تحميل الصفحة، لذا يجب بذل المزيد من العمل لتحديد العنصر "النهائي" الخاص بمقياس LCP. أسهل طريقة لتحديد وقياس العنصر المرشح "النهائي" لسرعة عرض أكبر محتوى مرئي (LCP) هي استخدام مكتبة JavaScript لمؤشرات أداء الويب، كما هو موضّح في المثال.

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

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

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

ملاحظة: راجِع المقالة المخصّصة حول العثور على التفاعلات البطيئة في الحقل للحصول على مزيد من المعلومات عن تصحيح أخطاء 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 لمؤشرات أداء الويب.

الاستخدام مع مكتبة JavaScript لمؤشرات أداء الويب

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

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

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

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);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

هذه التعليمة البرمجية خاصة بخدمة Google Analytics، ولكن الفكرة العامة يجب أن تُترجم إلى أدوات تحليلية أخرى كذلك.

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

على سبيل المثال، لتصحيح أخطاء 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);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

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

إعداد تقرير عن البيانات وتمثيلها بيانيًا

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

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

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

ملخّص

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

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

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

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