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

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

Philip Walton

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

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

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

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

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

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

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

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

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

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

اطّلِع على التقرير التالي من "إحصاءات 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) لصفحتك عند الشريحة المئوية الخامسة والسبعين.

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

يأخذ الرمز التالي قائمة من 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، يمكنك استخدام الخيار أكبر Contentful Paint API، واجهة برمجة التطبيقات نفسها التي تستخدمها لتحديد القيمة الزمنية لسرعة عرض أكبر محتوى مرئي.

عند مراقبة إدخالات 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 لمؤشرات أداء الويب

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

بدءًا من الإصدار 3، شملت web-vitals تتضمن مكتبة 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"، ولكن يجب ترجمة الفكرة العامة إلى أدوات تحليلية أخرى أيضًا

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

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

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

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

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

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

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

ملخّص

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

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

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

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