اشکال زدایی عملکرد در این زمینه

بیاموزید که چگونه داده های عملکرد خود را با اطلاعات اشکال زدایی نسبت دهید تا به شما در شناسایی و رفع مشکلات کاربر واقعی با تجزیه و تحلیل کمک کند

فیلیپ والتون

گوگل دو دسته ابزار برای اندازه گیری و اشکال زدایی عملکرد ارائه می دهد:

• ابزارهای آزمایشگاهی: ابزارهایی مانند Lighthouse، جایی که صفحه شما در یک محیط شبیه سازی شده بارگذاری می شود که می تواند شرایط مختلف را تقلید کند (به عنوان مثال، یک شبکه کند و یک دستگاه تلفن همراه پایین رده).
• ابزارهای میدانی: ابزارهایی مانند گزارش تجربه کاربر Chrome (CrUX) که بر اساس داده‌های کاربر واقعی و جمع‌آوری شده از Chrome است. (توجه داشته باشید که داده های میدانی گزارش شده توسط ابزارهایی مانند PageSpeed ​​Insights و Search Console از داده های CrUX تهیه شده است.)

در حالی که ابزارهای میدانی داده های دقیق تری را ارائه می دهند - داده هایی که در واقع نشان دهنده تجربه کاربران واقعی هستند - ابزارهای آزمایشگاهی اغلب در شناسایی و رفع مشکلات به شما کمک می کنند.

داده‌های CrUX بیشتر نشان‌دهنده عملکرد واقعی صفحه شما هستند، اما دانستن امتیازات CrUX شما بعید است که به شما در درک نحوه بهبود عملکردتان کمک کند.

از سوی دیگر، Lighthouse مسائل را شناسایی کرده و پیشنهادات خاصی را برای بهبود آن ارائه خواهد کرد. با این حال، Lighthouse فقط برای مشکلات عملکردی که در زمان بارگذاری صفحه کشف می کند، پیشنهاداتی ارائه می دهد. مشکلاتی را که فقط در نتیجه تعامل کاربر مانند پیمایش یا کلیک کردن روی دکمه‌های صفحه ظاهر می‌شوند، شناسایی نمی‌کند.

این یک سوال مهم را ایجاد می کند: چگونه می توانید اطلاعات اشکال زدایی را برای Core Web Vitals یا سایر معیارهای عملکرد از کاربران واقعی در این زمینه دریافت کنید؟

این پست به تفصیل توضیح می‌دهد که از چه APIهایی می‌توانید برای جمع‌آوری اطلاعات اشکال‌زدایی اضافی برای هر یک از معیارهای Core Web Vitals فعلی استفاده کنید و به شما ایده‌هایی درباره نحوه جمع‌آوری این داده‌ها در ابزار تحلیلی موجود ارائه می‌دهد.

API برای انتساب و اشکال زدایی

CLS

از میان تمام معیارهای Core Web Vitals، CLS شاید یکی از مواردی باشد که جمع آوری اطلاعات اشکال زدایی در این زمینه برای آن مهم ترین است. CLS در کل طول عمر صفحه اندازه‌گیری می‌شود، بنابراین نحوه تعامل کاربر با صفحه - تا چه حد پیمایش می‌کند، روی چه چیزی کلیک می‌کند و غیره - می‌تواند تأثیر قابل‌توجهی بر تغییر طرح‌بندی و تغییر کدام عناصر داشته باشد. .

گزارش زیر از PageSpeed ​​Insights را در نظر بگیرید:

مقدار گزارش شده برای CLS از آزمایشگاه (Lighthouse) در مقایسه با CLS از میدان (داده‌های CrUX) کاملاً متفاوت است، و اگر در نظر داشته باشید که صفحه ممکن است محتوای تعاملی زیادی داشته باشد که در هنگام آزمایش استفاده نمی‌شود، منطقی است. در فانوس دریایی

اما حتی اگر می‌دانید که تعامل کاربر بر داده‌های میدانی تأثیر می‌گذارد، باز هم باید بدانید که چه عناصری در صفحه تغییر می‌کنند تا به امتیاز 0.3 در صدک 75 برسید.

رابط LayoutShiftAttribution این امکان را فراهم می کند.

دریافت انتساب تغییر طرح

رابط LayoutShiftAttribution در هر ورودی layout-shift که Layout Instability API منتشر می کند، نمایش داده می شود.

برای توضیح دقیق هر دوی این رابط‌ها، به Debug layout shifts مراجعه کنید. برای اهداف این پست، اصلی‌ترین چیزی که باید بدانید این است که به عنوان یک توسعه‌دهنده، می‌توانید هر تغییر طرح‌بندی که در صفحه اتفاق می‌افتد و همچنین عناصری که در حال تغییر هستند را مشاهده کنید.

در اینجا چند نمونه کد وجود دارد که هر تغییر طرح و همچنین عناصری که تغییر کرده اند را ثبت می کند:

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 ممکن است از کاربر به کاربر دیگر متفاوت باشد.

این بدان معنی است که شما نمی توانید فرضیاتی در مورد اینکه کدام عنصر یا مجموعه ای از عناصر رایج ترین عنصر کاندید LCP برای یک صفحه خاص خواهد بود، داشته باشید. شما باید آن را بر اساس رفتار کاربر واقعی اندازه گیری کنید.

عنصر کاندید LCP را شناسایی کنید

برای تعیین عنصر کاندید LCP در جاوا اسکریپت می‌توانید از Largest Contentful Paint API استفاده کنید، همان API که برای تعیین مقدار زمان LCP استفاده می‌کنید.

هنگام مشاهده ورودی‌های largest-contentful-paint ، می‌توانید با نگاه کردن به ویژگی element آخرین ورودی، عنصر نامزد LCP فعلی را تعیین کنید:

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 نیز ممکن است مفید باشد، که می‌تواند در تعیین اینکه چه مراحل بهینه‌سازی خاص برای سایت شما مرتبط است مفید باشد.

FID

برای اشکال‌زدایی FID در فیلد، مهم است که به یاد داشته باشید که FID تنها بخش تاخیری از تاخیر کلی اولین رویداد ورودی را اندازه‌گیری می‌کند. این بدان معناست که آنچه کاربر با آن تعامل داشته است، واقعاً به اندازه آنچه که در زمان تعامل در موضوع اصلی اتفاق می‌افتد، مهم نیست.

به عنوان مثال، بسیاری از برنامه‌های جاوا اسکریپت که از رندر سمت سرور (SSR) پشتیبانی می‌کنند، HTML ایستا را ارائه می‌کنند که می‌تواند قبل از تعامل با ورودی کاربر به صفحه نمایش داده شود - یعنی قبل از اینکه جاوا اسکریپت مورد نیاز برای تعاملی کردن محتوا بارگیری شود.

برای این نوع کاربردها، دانستن اینکه آیا اولین ورودی قبل یا بعد از هیدراتاسیون رخ داده است، می تواند بسیار مهم باشد. اگر معلوم شد که بسیاری از افراد سعی می‌کنند قبل از اتمام هیدراتاسیون با صفحه تعامل داشته باشند، به جای اینکه در حالتی تعاملی به نظر می‌رسد، صفحات خود را در حالت غیرفعال یا بارگذاری رندر کنید.

اگر چارچوب برنامه شما مهر زمانی هیدراتاسیون را نشان می دهد، می توانید آن را با مهر زمانی first-input مقایسه کنید تا مشخص کنید که آیا اولین ورودی قبل یا بعد از هیدراتاسیون اتفاق افتاده است. اگر فریمورک شما آن مهر زمانی را نشان نمی‌دهد یا اصلاً از هیدراتاسیون استفاده نمی‌کند، سیگنال مفید دیگری ممکن است این باشد که آیا ورودی قبل یا بعد از اتمام بارگیری جاوا اسکریپت رخ داده است.

رویداد DOMContentLoaded پس از بارگیری و تجزیه کامل HTML صفحه فعال می‌شود، که شامل انتظار برای بارگیری اسکریپت‌های همزمان، معوق یا ماژول (شامل همه ماژول‌های وارد شده به صورت ایستا) است. بنابراین می توانید از زمان بندی آن رویداد استفاده کنید و آن را با زمانی که FID رخ داده است مقایسه کنید.

کد زیر ورودی های first-input را مشاهده می کند و ثبت می کند که آیا اولین ورودی قبل از پایان رویداد DOMContentLoaded رخ داده است یا نه:

new PerformanceObserver((list) => {
  const fidEntry = list.getEntries()[0];
  const navEntry = performance.getEntriesByType('navigation')[0];
  const wasFIDBeforeDCL =
    fidEntry.startTime < navEntry.domContentLoadedEventStart;

  console.log('FID occurred before DOMContentLoaded:', wasFIDBeforeDCL);
}).observe({type: 'first-input', buffered: true});

عنصر هدف FID و نوع رویداد را شناسایی کنید

سیگنال‌های اشکال‌زدایی بالقوه مفید اضافی، عنصری هستند که با آن تعامل داشته و همچنین نوع تعاملی که بوده است (مانند mousedown ، keydown ، pointerdown ). در حالی که تعامل با عنصر به خودی خود به FID کمک نمی کند (به یاد داشته باشید FID فقط بخش تاخیری کل زمان تاخیر رویداد است)، دانستن اینکه کاربران شما با کدام عناصر تعامل دارند ممکن است در تعیین بهترین روش برای بهبود FID مفید باشد.

به عنوان مثال، اگر اکثریت قریب به اتفاق اولین تعاملات کاربر شما با یک عنصر خاص است، کد جاوا اسکریپت مورد نیاز برای آن عنصر را در HTML درج کنید و بقیه را با تنبلی بارگذاری کنید.

برای دریافت نوع تعامل و عنصر مرتبط با اولین رویداد ورودی، می‌توانید به ویژگی‌های target و name first-input مراجعه کنید:

new PerformanceObserver((list) => {
  const fidEntry = list.getEntries()[0];

  console.log('FID target element:', fidEntry.target);
  console.log('FID interaction type:', fidEntry.name);
}).observe({type: 'first-input', buffered: true});

INP

INP بسیار شبیه به FID است زیرا مفیدترین بیت های اطلاعات برای گرفتن در این زمینه عبارتند از:

1. با چه عنصری تعامل داشت
2. چرا نوع تعامل آن بود
3. زمانی که آن تعامل صورت گرفت

مانند FID، یکی از دلایل اصلی تعاملات کند، یک رشته اصلی مسدود شده است که می تواند در هنگام بارگیری جاوا اسکریپت رایج باشد. دانستن اینکه آیا بیشتر کنش‌های کند در حین بارگذاری صفحه رخ می‌دهند یا خیر، برای تعیین اینکه برای رفع مشکل چه کاری باید انجام شود مفید است.

برخلاف FID، متریک INP تأخیر کامل یک تعامل را در نظر می‌گیرد - از جمله زمان لازم برای اجرای هر شنونده رویداد ثبت‌شده و همچنین زمان لازم برای نقاشی فریم بعدی پس از اجرای تمام شنوندگان رویدادها. این بدان معناست که برای INP حتی مفیدتر است که بدانیم کدام عناصر هدف منجر به کنش‌های کند می‌شوند و آن‌ها چه نوع تعاملاتی هستند.

از آنجایی که INP و FID هر دو بر اساس Event Timing API هستند، نحوه تعیین این اطلاعات در جاوا اسکریپت بسیار شبیه به مثال قبلی است. کد زیر عنصر هدف و زمان (نسبت به DOMContentLoaded ) ورودی INP را ثبت می کند.

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

  const navEntry = performance.getEntriesByType('navigation')[0];
  const wasINPBeforeDCL =
    inpEntry.startTime < navEntry.domContentLoadedEventStart;

  console.log('INP occurred before DCL:', wasINPBeforeDCL);
}

توجه داشته باشید که این کد نحوه تعیین ورودی event ورودی INP را نشان نمی دهد، زیرا این منطق بیشتر درگیر است. با این حال، بخش زیر نحوه دریافت این اطلاعات را با استفاده از کتابخانه جاوا اسکریپت web-vitals توضیح می دهد.

استفاده با کتابخانه جاوا اسکریپت web-vitals

بخش‌های بالا چند پیشنهاد کلی و مثال‌های کد را برای جمع‌آوری اطلاعات اشکال‌زدایی ارائه می‌دهند تا در داده‌هایی که به ابزار تجزیه و تحلیل ارسال می‌کنید، گنجانده شوند.

از نسخه 3، کتابخانه جاوا اسکریپت web-vitals شامل یک ساختار اسنادی است که همه این اطلاعات را نشان می دهد و همچنین چند سیگنال اضافی را نیز شامل می شود.

مثال کد زیر نشان می‌دهد که چگونه می‌توانید یک پارامتر رویداد اضافی (یا بعد سفارشی ) حاوی یک رشته اشکال‌زدایی را تنظیم کنید که برای کمک به شناسایی علت اصلی مشکلات عملکرد مفید است.

import {onCLS, onFID, 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 'FID':
    case 'INP':
      eventParams.debug_target = attribution.eventTarget;
      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);

این کد مخصوص گوگل آنالیتیکس است، اما ایده کلی باید به سایر ابزارهای تحلیلی نیز ترجمه شود.

این کد همچنین نحوه گزارش گیری در مورد یک سیگنال اشکال زدایی را نشان می دهد، اما ممکن است مفید باشد که بتوان چندین سیگنال مختلف را در هر متریک جمع آوری و گزارش کرد. به عنوان مثال، برای اشکال زدایی INP ممکن است بخواهید نوع تعامل، زمان و همچنین عنصری که با آن تعامل دارد را جمع آوری کنید. همانطور که در مثال زیر نشان داده شده است، ساخت انتساب web-vitals تمام این اطلاعات را نشان می دهد:

import {onCLS, onFID, 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.eventTarget;
      eventParams.debug_type = attribution.eventType;
      eventParams.debug_time = attribution.eventTime;
      eventParams.debug_load_state = attribution.loadState;
      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);

برای لیست کامل سیگنال های اشکال زدایی که در معرض دید قرار گرفته اند، به اسناد انتساب web-vitals مراجعه کنید.

داده ها را گزارش و تجسم کنید

هنگامی که شروع به جمع آوری اطلاعات اشکال زدایی به همراه مقادیر متریک کردید، گام بعدی این است که داده ها را در بین همه کاربران خود جمع آوری کنید تا شروع به جستجوی الگوها و روندها کنید.

همانطور که در بالا ذکر شد، لزوماً نیازی نیست که به تک تک مشکلاتی که کاربران با آن مواجه می‌شوند بپردازید، می‌خواهید – به خصوص در ابتدا – مسائلی را که بیشترین تعداد کاربران را تحت تأثیر قرار می‌دهند، حل کنید، که باید مشکلاتی نیز باشد که بیشترین تعداد را دارند. تأثیر منفی بر نمرات Core Web Vitals شما.

برای GA4 به مقاله اختصاصی در مورد نحوه پرس و جو و تجسم داده ها با استفاده از BigQuery مراجعه کنید.

خلاصه

امیدواریم این پست به تشریح روش‌های خاصی کمک کرده باشد که می‌توانید از APIهای عملکرد موجود و کتابخانه web-vitals برای دریافت اطلاعات اشکال‌زدایی برای کمک به تشخیص عملکرد بر اساس بازدیدهای کاربران واقعی در این زمینه استفاده کنید. در حالی که این راهنما بر روی Core Web Vitals متمرکز است، این مفاهیم برای اشکال زدایی هر معیار عملکردی که در جاوا اسکریپت قابل اندازه گیری است نیز کاربرد دارد.

اگر به‌تازگی اندازه‌گیری عملکرد را شروع کرده‌اید و در حال حاضر کاربر Google Analytics هستید، ابزار Web Vitals Report ممکن است مکان خوبی برای شروع باشد، زیرا از قبل از گزارش اطلاعات اشکال‌زدایی برای معیارهای Core Web Vitals پشتیبانی می‌کند.

اگر یک فروشنده تجزیه و تحلیل هستید و به دنبال بهبود محصولات خود و ارائه اطلاعات بیشتر برای رفع اشکال به کاربران خود هستید، برخی از تکنیک های شرح داده شده در اینجا را در نظر بگیرید اما خود را فقط به ایده های ارائه شده در اینجا محدود نکنید. این پست در نظر گرفته شده است که به طور کلی برای همه ابزارهای تجزیه و تحلیل قابل استفاده باشد. با این حال، ابزارهای تجزیه و تحلیل فردی به احتمال زیاد می توانند (و باید) اطلاعات اشکال زدایی بیشتری را ضبط و گزارش کنند.

در نهایت، اگر احساس می‌کنید به دلیل از دست دادن ویژگی‌ها یا اطلاعات موجود در خود APIها، در توانایی شما برای اشکال‌زدایی این معیارها شکاف‌هایی وجود دارد، بازخورد خود را به web-vitals-feedback@googlegroups.com ارسال کنید.