با اطلاعات اشکال‌زدایی یاد بگیرید چگونه داده‌های عملکردتان را نسبت دهید تا با تجزیه‌وتحلیل بتوانید مشکلات کاربران واقعی را شناسایی و برطرف کنید
Google دو دسته ابزار برای اندازه‌گیری و اشکال‌زدایی عملکرد ارائه می‌دهد:
- ابزارهای آزمایشگاه: ابزارهایی مثل Lighthouse که در آن صفحه شما در یک محیط شبیه‌سازی‌شده بار می‌شود که می‌تواند شرایط مختلف را تقلید کند (برای مثال، شبکه کند و دستگاه همراه پایین‌رده).
- ابزارهای میدانی: ابزارهایی مثل گزارش تجربه کاربری Chrome (CrUX) که براساس داده‌های انبوهشی کاربر واقعی از Chrome است. (توجه داشته باشید که داده‌های فیلد گزارش‌شده توسط ابزارهایی مانند PageSpeed Insights و Search Console از داده‌های CrUX گرفته شده است.)
درحالی‌که ابزارهای میدانی داده‌های دقیق‌تری ارائه می‌دهند—داده‌هایی که درواقع نشان‌دهنده تجربه کاربران واقعی است—ابزارهای آزمایشگاهی اغلب در کمک به شناسایی و رفع مشکلات بهتر هستند.
داده‌های CrUX نمایانگر عملکرد واقعی صفحه شما است، اما دانستن امتیازهای CrUX به شما کمک نمی‌کند چگونه عملکردتان را بهبود دهید.
از سوی دیگر، Lighthouse مشکلات را شناسایی می‌کند و پیشنهادهای مشخصی برای نحوه بهبود ارائه می‌دهد. بااین‌حال، Lighthouse فقط برای مشکلات عملکردی که در زمان بار کردن صفحه پیدا می‌کند پیشنهاد می‌دهد. این ابزار مشکلاتی را که فقط درنتیجه تعامل کاربر مثل پیمایش یا کلیک کردن روی دکمه‌های صفحه آشکار می‌شوند شناسایی نمی‌کند.
این موضوع سؤال مهمی را مطرح می‌کند: چگونه می‌توانید اطلاعات اشکال‌زدایی را برای «معیارهای کلیدی وب» یا دیگر سنجه‌های عملکرد از کاربران واقعی در این زمینه ضبط کنید؟
این پست به‌طور مفصل توضیح می‌دهد که از کدام «میاناهای برنامه‌سازی کاربردی» می‌توانید برای جمع‌آوری اطلاعات اشکال‌زدایی اضافی برای هریک از شاخص‌های «حیاتی وب اصلی» فعلی استفاده کنید و ایده‌هایی درباره نحوه ضبط این داده‌ها در ابزار تجزیه‌وتحلیل موجودتان ارائه می‌دهد.
میاناهای برنامه‌سازی کاربردی برای ارجاع و اشکال‌زدایی
تغییر چیدمان تجمعی (CLS)
از بین همه سنجه‌های «معیارهای کلیدی اصلی وب»، CLS شاید سنجه‌ای باشد که جمع‌آوری اطلاعات اشکال‌زدایی در فیلد برای آن از همه مهم‌تر است. «تغییر چیدمان تجمعی» در کل طول عمر صفحه اندازه‌گیری می‌شود، بنابراین نحوه تعامل کاربر با صفحه—تا چه میزان پیمایش می‌کند، روی چه چیزی کلیک می‌کند، و غیره—می‌تواند تأثیر قابل‌توجهی بر وجود تغییرات چیدمان و اینکه کدام عناصر تغییر می‌کنند داشته باشد.
گزارش زیر را از «اطلاعات آماری PageSpeed» درنظر بگیرید:
مقدار گزارش‌شده برای CLS از آزمایشگاه (Lighthouse) در مقایسه با CLS از فیلد (داده‌های CrUX) بسیار متفاوت است، و این منطقی است اگر درنظر بگیرید که صفحه ممکن است محتوای تعاملی زیادی داشته باشد که هنگام آزمایش در Lighthouse استفاده نمی‌شود.
اما حتی اگر بدانید که تعامل کاربر بر داده‌های فیلد تأثیر می‌گذارد، همچنان باید بدانید که کدام عناصر در صفحه تغییر می‌کنند تا به نمره ۰٫۲۸ در صدک ۷۵ برسند. میانای 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 به ابزار تجزیه‌وتحلیل خود هستید.
کد زیر فهرستی از layout-shift ورودی را که در
«تغییر چیدمان تجمعی» نقش داشته‌اند می‌گیرد و بزرگ‌ترین عنصر منبع را از بزرگ‌ترین تغییر برمی‌گرداند:
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;
}
}
}
پس‌از شناسایی بزرگ‌ترین عنصر مؤثر در بزرگ‌ترین تغییر، می‌توانید آن را به ابزار تجزیه‌وتحلیل خود گزارش دهید.
عنصری که بیشترین سهم را در «تغییر چیدمان تجمعی» برای یک صفحه معین دارد احتمالاً از کاربری به کاربر دیگر متفاوت است، اما اگر این عناصر را در بین همه کاربران تجمیع کنید، می‌توانید فهرستی از عناصر جابه‌جا شونده‌ای که بیشترین تعداد کاربران را تحت‌تأثیر قرار می‌دهد تولید کنید.
پس‌از اینکه علت اصلی جابه‌جایی‌های آن عناصر را شناسایی و برطرف کردید، کد Analytics شما شروع به گزارش جابه‌جایی‌های کوچک‌تر به‌عنوان «بدترین» جابه‌جایی‌های صفحه‌هایتان می‌کند. درنهایت، همه تغییرات گزارش‌شده به‌اندازه‌ای کوچک خواهند بود که صفحه‌هایتان کاملاً در آستانه «خوب» ۰٫۱ قرار بگیرند!
برخی‌از فراداده‌های دیگری که ممکن است برای ضبط همراه با عنصر منبع بزرگ‌ترین تغییر مفید باشند عبارت‌اند از:
- زمان بزرگ‌ترین تغییر
- مسیر نشانی وب در زمان بزرگ‌ترین تغییر (برای سایت‌هایی که نشانی وب را به‌طور پویا به‌روز می‌کنند، مثل «برنامه‌های تک‌صفحه‌ای»).
بزرگ‌ترین نقاشی دارای محتوا (LCP)
برای اشکال‌زدایی LCP در فیلد، اطلاعات اصلی موردنیاز شما این است که کدام عنصر خاص بزرگ‌ترین عنصر (عنصر نامزد LCP) برای آن بار صفحه خاص بوده است.
توجه داشته باشید که کاملاً ممکن است—درواقع، بسیار رایج است—که عنصر نامزد LCP برای کاربران مختلف متفاوت باشد، حتی برای دقیقاً همان صفحه.
این اتفاق می‌تواند به چند دلیل رخ دهد:
- دستگاه‌های کاربران وضوح صفحه‌نمایش متفاوتی دارند که منجر به چیدمان‌های صفحه متفاوت و درنتیجه عناصر مختلفی می‌شود که در ناحیه نمایش قابل‌مشاهده هستند.
- کاربران همیشه صفحه‌های پیمایش‌شده تا بالا را بار نمی‌کنند. اغلب پیوندها حاوی شناسه‌های تکه‌تکه یا حتی تکه‌های نوشتاری هستند، که به این معنی است که ممکن است صفحات شما در هر موقعیت پیمایشی در صفحه بارگیری و نمایش داده شوند.
- محتوا ممکن است برای کاربر فعلی شخصی‌سازی شود، بنابراین عنصر نامزد LCP می‌تواند از کاربری به کاربر دیگر بسیار متفاوت باشد.
این یعنی نمی‌توانید درباره اینکه کدام عنصر یا مجموعه عناصر رایج‌ترین عنصر نامزد LCP برای صفحه‌ای خاص خواهد بود فرضیه بسازید. باید آن را براساس رفتار کاربر واقعی اندازه‌گیری کنید.
عنصر نامزد LCP را شناسایی کنید
برای تعیین عنصر نامزد LCP در جاوا اسکریپت می‌توانید از 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 ضبط شود عبارت‌اند از:
- با کدام عنصر تعامل شده است
- نوع تعامل
- زمان وقوع آن تعامل
یکی از دلایل اصلی تعامل‌های کند، مسدود شدن رشته اصلی است که می‌تواند در زمان بار شدن جاوا اسکریپت رایج باشد. دانستن اینکه آیا بیشتر تعاملات کند درطول بار کردن صفحه رخ می‌دهد یا نه، در تعیین اینکه برای رفع مشکل چه کاری باید انجام شود مفید است.
سنجه 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 است را نشان نمی‌دهد، زیرا این منطق پیچیده‌تر است. بااین‌حال، بخش زیر توضیح می‌دهد
چگونه بااستفاده از کتابخانه
جاوا اسکریپت web-vitals این اطلاعات را دریافت کنید.
استفاده با کتابخانه جاوا اسکریپت web-vitals
بخش‌های قبلی چند پیشنهاد کلی و نمونه کد برای گرفتن اطلاعات اشکال‌زدایی ارائه می‌دهد تا در داده‌هایی که به ابزار تجزیه‌وتحلیل خود ارسال می‌کنید بگنجانید.
از نسخه ۳، کتابخانه جاوا اسکریپت 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 Analytics است، اما ایده کلی باید به ابزارهای تحلیلی دیگر نیز ترجمه شود.
این کد همچنین فقط نحوه گزارش‌دهی درباره یک سیگنال اشکال‌زدایی را نشان می‌دهد، اما جمع‌آوری و گزارش‌دهی درباره چندین سیگنال مختلف در هر سنجه مفید است.
برای مثال، برای اشکال‌زدایی 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);
برای فهرست کامل نشان‌های اشکال‌زدایی نمایان‌شده، به اسناد اسنادی وب‌سایت‌های حیاتی مراجعه کنید.
گزارش و دیداری‌سازی داده‌ها
وقتی جمع‌آوری اطلاعات اشکال‌زدایی را همراه با مقادیر سنجه شروع کردید، گام بعدی تجمیع داده‌ها در همه کاربران برای شروع جستجوی الگوها و گرایش‌ها است.
همان‌طور که قبلاً ذکر شد، لازم نیست حتماً به تک‌تک مشکلاتی که کاربران شما با آن مواجه هستند رسیدگی کنید، بلکه باید—به‌ویژه در ابتدا—به مشکلاتی رسیدگی کنید که بیشترین تعداد کاربران را تحت‌تأثیر قرار می‌دهند، که این مشکلات باید همان مشکلاتی باشند که بیشترین تأثیر منفی را بر نمره‌های «شاخص‌های اصلی وب» شما دارند.
برای GA4، مقاله اختصاصی نحوه پُرسمان و دیداری‌سازی داده‌ها بااستفاده از BigQuery را ببینید.
خلاصه
امیدواریم این پست به شما کمک کرده باشد تا روش‌های خاصی را که می‌توانید از
میاناهای برنامه‌سازی کاربردی عملکرد موجود و کتابخانه web-vitals برای دریافت اطلاعات اشکال‌زدایی
استفاده کنید تا به تشخیص عملکرد براساس بازدیدهای کاربران واقعی در این زمینه کمک کنید، مشخص کند. اگرچه این راهنما بر «معیارهای کلیدی اصلی وب» تمرکز دارد، این مفاهیم برای اشکال‌زدایی هر سنجه عملکردی که در جاوا اسکریپت قابل اندازه‌گیری است نیز کاربرد دارد.
اگر فروشنده تجزیه‌وتحلیل هستید و به‌دنبال بهبود محصولات خود و ارائه اطلاعات اشکال‌زدایی بیشتر به کاربران خود هستید، برخی‌از تکنیک‌های شرح‌داده‌شده در اینجا را درنظر بگیرید، اما خودتان را به فقط ایده‌های ارائه‌شده در اینجا محدود نکنید. این پست به‌طور کلی برای همه ابزارهای تجزیه‌وتحلیل کاربرد دارد؛ بااین‌حال، ابزارهای تجزیه‌وتحلیل فردی احتمالاً می‌توانند (و باید) اطلاعات اشکال‌زدایی بیشتری را ضبط و گزارش کنند.
در آخر، اگر احساس می‌کنید به‌دلیل نبود ویژگی‌ها یا اطلاعات در خود «میاناهای برنامه‌سازی کاربردی» نمی‌توانید این معیارها را اشکال‌زدایی کنید، بازخوردتان را به web-vitals-feedback@googlegroups.com ارسال کنید.