بهترین روش ها برای اندازه گیری Web Vitals در این زمینه

چگونه با ابزار تجزیه و تحلیل فعلی خود، Web Vitals را اندازه گیری کنید.

فیلیپ والتون

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

بسیاری از ارائه دهندگان محبوب تجزیه و تحلیل مانیتورینگ کاربر واقعی (RUM) در حال حاضر از معیارهای Core Web Vitals در ابزارهای خود (و همچنین بسیاری دیگر از Web Vitals ) پشتیبانی می کنند. اگر در حال حاضر از یکی از این ابزارهای تجزیه و تحلیل RUM استفاده می کنید، برای ارزیابی اینکه صفحات سایت شما تا چه حد آستانه های توصیه شده Core Web Vitals را برآورده می کنند و از رگرسیون در آینده جلوگیری می کنند، در وضعیت خوبی هستید.

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

این راهنما بهترین روش‌ها را برای اندازه‌گیری معیارهای Core Web Vitals (یا هر معیار سفارشی) با ابزار تجزیه و تحلیل شخص ثالث یا داخلی مورد بحث قرار می‌دهد. همچنین می تواند به عنوان راهنمای فروشندگان تجزیه و تحلیلی که مایلند پشتیبانی Core Web Vitals را به سرویس خود اضافه کنند، باشد.

از معیارها یا رویدادهای سفارشی استفاده کنید

همانطور که در بالا ذکر شد، اکثر ابزارهای تجزیه و تحلیل به شما امکان می دهند داده های سفارشی را اندازه گیری کنید. اگر ابزار تجزیه و تحلیل شما از این امر پشتیبانی می کند، باید بتوانید هر یک از معیارهای Core Web Vitals را با استفاده از این مکانیسم اندازه گیری کنید.

اندازه‌گیری معیارها یا رویدادهای سفارشی در یک ابزار تحلیلی به طور کلی یک فرآیند سه مرحله‌ای است:

1. معیار سفارشی را در ادمین ابزار خود تعریف یا ثبت کنید (در صورت نیاز). (توجه: همه ارائه دهندگان تجزیه و تحلیل نیازی به تعریف معیارهای سفارشی ندارند.)
2. مقدار معیار را در کد جاوا اسکریپت ظاهری خود محاسبه کنید.
3. با اطمینان از مطابقت نام یا شناسه با آنچه در مرحله 1 تعریف شده است، مقدار متریک را به بخش تحلیلی خود ارسال کنید (دوباره، در صورت لزوم) .

برای مراحل 1 و 3، می توانید برای دستورالعمل ها به مستندات ابزار تجزیه و تحلیل خود مراجعه کنید. برای مرحله 2 می توانید از کتابخانه جاوا اسکریپت web-vitals برای محاسبه مقدار هر یک از معیارهای Core Web Vitals استفاده کنید.

نمونه کد زیر نشان می دهد که ردیابی این معیارها در کد و ارسال آنها به یک سرویس تجزیه و تحلیل چقدر آسان است.

import {onCLS, onFID, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);

از میانگین ها دوری کنید

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

میانگین ها مشکل ساز هستند زیرا نشان دهنده جلسه هیچ کاربر واحدی نیستند. نقاط پرت در هر یک از محدوده‌های توزیع ممکن است میانگین را به روش‌هایی گمراه‌کننده تغییر دهند.

به عنوان مثال، گروه کوچکی از کاربران ممکن است در شبکه‌ها یا دستگاه‌هایی بسیار کند باشند که در محدوده حداکثری مقادیر قرار دارند، اما جلسات کاربر کافی برای تأثیرگذاری بر میانگین به‌گونه‌ای که نشان از وجود مشکل دارد، در نظر نگرفته باشند.

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

اطمینان حاصل کنید که می توانید یک توزیع را گزارش دهید

هنگامی که مقادیر هر یک از معیارهای Core Web Vitals را محاسبه کردید و آنها را با استفاده از یک معیار یا رویداد سفارشی به سرویس تجزیه و تحلیل خود ارسال کردید، گام بعدی این است که یک گزارش یا داشبورد ایجاد کنید که مقادیر جمع‌آوری شده را نمایش دهد.

برای اطمینان از رعایت آستانه های پیشنهادی Core Web Vitals ، باید گزارش خود را برای نمایش مقدار هر متریک در صدک 75 نشان دهید.

اگر ابزار تجزیه و تحلیل شما گزارش چندگانه را به عنوان یک ویژگی داخلی ارائه نمی دهد، احتمالاً همچنان می توانید این داده ها را به صورت دستی با ایجاد گزارشی که هر مقدار متریک را به ترتیب صعودی مرتب می کند، دریافت کنید. هنگامی که این گزارش ایجاد شد، نتیجه ای که در 75٪ از فهرست کامل و مرتب شده از همه مقادیر در آن گزارش است، صدک 75 برای آن متریک خواهد بود - و صرف نظر از اینکه داده های خود را چگونه تقسیم بندی کنید، این مورد خواهد بود ( بر اساس نوع دستگاه، نوع اتصال، کشور و غیره).

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

گزارش Web Vitals نمونه ای از این تکنیک است که از Google Analytics استفاده می کند. کد گزارش منبع باز است، بنابراین توسعه دهندگان می توانند آن را به عنوان نمونه ای از تکنیک های ذکر شده در این بخش ارجاع دهند.

داده های خود را در زمان مناسب ارسال کنید

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

با این حال، این می تواند مشکل ساز باشد، زیرا هر دو رویداد beforeunload و unload قابل اعتماد نیستند (مخصوصاً در تلفن همراه) و استفاده از آنها توصیه نمی شود (زیرا می توانند از واجد شرایط بودن یک صفحه برای Cache Back-Forward جلوگیری کنند).

برای معیارهایی که کل طول عمر یک صفحه را ردیابی می‌کنند، بهتر است هر مقدار فعلی اندازه‌گیری را در طول رویداد visibilitychange ارسال کنید، هر زمان که وضعیت نمایان بودن صفحه به hidden تغییر کرد. این به این دلیل است که - پس از تغییر وضعیت دید صفحه به hidden - هیچ تضمینی وجود ندارد که هر اسکریپت در آن صفحه بتواند دوباره اجرا شود. این امر به ویژه در سیستم عامل های تلفن همراه که در آن برنامه مرورگر خود را می توان بدون بازخوانی هیچ صفحه ای بسته کرد، صادق است.

توجه داشته باشید که سیستم‌عامل‌های تلفن همراه معمولاً هنگام تعویض برگه‌ها، تعویض برنامه‌ها یا بستن خود برنامه مرورگر، رویداد visibilitychange را فعال می‌کنند. آنها همچنین هنگام بستن یک برگه یا پیمایش به صفحه جدید، رویداد visibilitychange را فعال می کنند. این باعث می شود که رویداد visibilitychange بسیار قابل اعتمادتر از رویدادهای unload یا beforeunload باشد.

نظارت بر عملکرد در طول زمان

هنگامی که پیاده سازی تجزیه و تحلیل خود را برای ردیابی و گزارش معیارهای Core Web Vitals به روز کردید، گام بعدی این است که بررسی کنید که چگونه تغییرات سایت شما بر عملکرد در طول زمان تأثیر می گذارد.

تغییرات خود را نسخه کنید

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

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

آزمایش ها را اجرا کنید

می‌توانید با ردیابی چندین نسخه (یا آزمایش) همزمان، نسخه‌سازی را یک قدم جلوتر ببرید.

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

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

اطمینان حاصل کنید که اندازه گیری بر عملکرد تأثیر نمی گذارد

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

همیشه هنگام استقرار کدهای تجزیه و تحلیل RUM در سایت تولید خود از این اصول پیروی کنید:

تجزیه و تحلیل خود را به تعویق بیندازید

کد تجزیه و تحلیل همیشه باید به صورت ناهمزمان و غیر مسدود بارگذاری شود و به طور کلی باید آخرین بارگذاری شود. اگر کد تجزیه و تحلیل خود را به روشی مسدود کننده بارگیری کنید، می تواند بر LCP تأثیر منفی بگذارد.

همه API های مورد استفاده برای اندازه گیری معیارهای Core Web Vitals به طور خاص برای پشتیبانی از بارگیری ناهمزمان و معوق اسکریپت (از طریق پرچم buffered ) طراحی شده اند، بنابراین نیازی به عجله برای بارگذاری زودهنگام اسکریپت های خود نیست.

در صورتی که متریکی را اندازه‌گیری می‌کنید که نمی‌توان آن را بعداً در جدول زمانی بارگذاری صفحه محاسبه کرد، باید فقط کدی را که باید زودتر اجرا شود در <head> سند خود درج کنید (بنابراین این یک درخواست مسدود کردن رندر نیست) و بقیه را به تعویق بیندازید. همه تجزیه و تحلیل های خود را زود بار نکنید فقط به این دلیل که یک معیار واحد به آن نیاز دارد.

کارهای طولانی ایجاد نکنید

کد تجزیه و تحلیل اغلب در پاسخ به ورودی کاربر اجرا می‌شود، اما اگر کد تحلیلی شما اندازه‌گیری‌های DOM زیادی را انجام می‌دهد یا از دیگر API‌های فشرده پردازشگر استفاده می‌کند، خود کد تحلیلی می‌تواند باعث پاسخگویی ورودی ضعیف شود. علاوه بر این، اگر فایل جاوا اسکریپت حاوی کد تجزیه و تحلیل شما بزرگ باشد، اجرای آن فایل می تواند رشته اصلی را مسدود کند و تأثیر منفی بر تاخیر ورودی اول (FID) یا تعامل با رنگ بعدی (INP) بگذارد .

از API های غیر مسدود کننده استفاده کنید

APIهایی مانند sendBeacon() و requestIdleCallback() به طور خاص برای اجرای وظایف غیر حیاتی به گونه ای طراحی شده اند که وظایف حیاتی کاربر را مسدود نکنند.

این APIها ابزارهای عالی برای استفاده در کتابخانه تجزیه و تحلیل RUM هستند.

به طور کلی، تمام چراغ های تجزیه و تحلیل باید با استفاده از sendBeacon() API (در صورت وجود) ارسال شوند، و تمام کدهای اندازه گیری تجزیه و تحلیل غیرفعال باید در دوره های بیکار اجرا شوند.

بیش از آنچه نیاز دارید ردیابی نکنید

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

به عنوان مثال، Resource Timing API داده های زمان بندی دقیقی را برای هر منبعی که در صفحه شما بارگذاری می شود ارائه می دهد. با این حال، بعید است که همه این داده ها لزوما یا در بهبود عملکرد بار منبع مفید باشند.

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