اندازه گیری تاثیر عملکرد در دنیای واقعی کارکنان خدمات

Philip Walton

یکی از مهمترین مزایای کارکنان خدمات (حداقل از منظر عملکرد) توانایی آنها در کنترل فعالانه ذخیره دارایی ها است. یک برنامه وب که می تواند تمام منابع ضروری خود را در حافظه پنهان نگه دارد، باید برای بازدیدکنندگان بازگشتی سریعتر بارگیری شود. اما این دستاوردها در واقع برای کاربران واقعی چگونه به نظر می رسند؟ و این را چگونه اندازه می گیرید؟

برنامه وب Google I/O (به اختصار IOWA) یک برنامه وب پیشرفته است که از بیشتر قابلیت های جدید ارائه شده توسط کارکنان خدمات برای ارائه تجربه ای غنی و شبیه به برنامه به کاربران خود استفاده می کند. همچنین از Google Analytics برای گرفتن داده‌های کلیدی عملکرد و الگوهای استفاده از مخاطبان بزرگ و متنوع خود استفاده کرد.

این مطالعه موردی به بررسی این موضوع می‌پردازد که چگونه IOWA از Google Analytics برای پاسخ به سؤالات کلیدی عملکرد و گزارش در مورد تأثیر کارکنان خدمات در دنیای واقعی استفاده می‌کند.

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

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

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

1. آیا کش کردن سرویس دهنده عملکرد بیشتری نسبت به مکانیزم های ذخیره سازی HTTP موجود در همه مرورگرها دارد؟

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

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

اما آیا این تلاش بهتر از کاری است که مرورگر در حال حاضر به صورت پیش فرض انجام می دهد؟ و اگر بله، چقدر بهتر است؟ 1

2. کارگر خدمات چگونه بر تجربه بارگذاری سایت تأثیر می گذارد؟

به عبارت دیگر، صرف نظر از زمان بارگذاری واقعی که توسط معیارهای سنتی بارگذاری صفحه اندازه گیری می شود، چقدر سریع احساس می شود که سایت در حال بارگذاری است؟

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

انتخاب متریک مناسب

Google Analytics به‌طور پیش‌فرض، زمان‌های بارگذاری صفحه (از طریق Navigation Timing API ) را برای ۱٪ از بازدیدکنندگان سایت ردیابی می‌کند و این داده‌ها را از طریق معیارهایی مانند میانگین در دسترس قرار می‌دهد. زمان بارگذاری صفحه

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

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

هنگامی که در مورد سوالاتی که می‌خواستیم به آنها پاسخ دهیم تصمیم گرفتیم و معیارهایی را شناسایی کردیم که در پاسخ به آنها مفید هستند، نوبت به پیاده‌سازی Google Analytics و شروع اندازه‌گیری رسید.

پیاده سازی تجزیه و تحلیل

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

<script>
window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<script async src="https://www.google-analytics.com/analytics.js"></script>

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

قسمت میانی شامل این دو خط است:

ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');

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

برای IOWA، ما می‌خواستیم دو چیز دیگر را دنبال کنیم:

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

گرفتن زمان برای اولین رنگ

برخی از مرورگرها زمان دقیقی که اولین پیکسل روی صفحه نمایش داده می شود را ثبت می کنند و آن زمان را در اختیار توسعه دهندگان قرار می دهند. این مقدار، در مقایسه با مقدار navigationStart که از طریق Navigation Timing API نشان داده شده است، حساب بسیار دقیقی از مدت زمانی که کاربر در ابتدا درخواست صفحه را کرده است و زمانی که برای اولین بار چیزی را دیده است، به ما می دهد.

همانطور که قبلاً اشاره کردم، زمان برای اولین بار رنگ کردن یک معیار مهم برای اندازه گیری است زیرا اولین نقطه ای است که کاربر سرعت بارگذاری سایت شما را تجربه می کند. این اولین برداشتی است که کاربران دریافت می‌کنند، و اولین برداشت خوب می‌تواند بر بقیه تجربه کاربر تأثیر مثبت بگذارد. 2

برای دریافت اولین مقدار رنگ در مرورگرهایی که آن را در معرض نمایش قرار می دهند، تابع ابزار getTimeToFirstPaintIfSupported را ایجاد کردیم:

function getTimeToFirstPaintIfSupported() {
  // Ignores browsers that don't support the Performance Timing API.
  if (window.performance && window.performance.timing) {
    var navTiming = window.performance.timing;
    var navStart = navTiming.navigationStart;
    var fpTime;

    // If chrome, get first paint time from `chrome.loadTimes`.
    if (window.chrome && window.chrome.loadTimes) {
      fpTime = window.chrome.loadTimes().firstPaintTime * 1000;
    }
    // If IE/Edge, use the prefixed `msFirstPaint` property.
    // See http://msdn.microsoft.com/ff974719
    else if (navTiming.msFirstPaint) {
      fpTime = navTiming.msFirstPaint;
    }

    if (fpTime && navStart) {
      return fpTime - navStart;
    }
  }
}

احتیاط: مهم: مقادیر firstpaint ارجاع شده در تابع بالا بخشی از APIهای خاص فروشنده هستند. آنها غیر استاندارد هستند و در هر زمان در معرض تغییر (یا حذف) هستند. ما تصمیم گرفتیم آنها را در IOWA پیاده سازی کنیم زیرا می دانستیم که این سایت طول عمر محدودی دارد. برای اکثر سایت‌ها، بهتر است از سایر تکنیک‌های زمان‌بندی کاربر تا زمانی که یک firstpaint (یا یک جایگزین firstpaint ) استاندارد شود، استفاده شود.

با این کار، اکنون می‌توانیم تابع دیگری بنویسیم که یک رویداد غیر تعاملی را با زمان اولین رنگ‌سازی به عنوان مقدار آن ارسال می‌کند : 3

function sendTimeToFirstPaint() {
  var timeToFirstPaint = getTimeToFirstPaintIfSupported();

  if (timeToFirstPaint) {
    ga('send', 'event', {
      eventCategory: 'Performance',
      eventAction: 'firstpaint',
      // Rounds to the nearest millisecond since
      // event values in Google Analytics must be integers.
      eventValue: Math.round(timeToFirstPaint)
      // Sends this as a non-interaction event,
      // so it doesn't affect bounce rate.
      nonInteraction: true
    });
  }
}

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

// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');

// Sends a pageview for the initial pageload.
ga('send', 'pageview');

// Sends an event with the time to first paint data.
sendTimeToFirstPaint();

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

// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');

// Postpones sending any hits until after the page has fully loaded.
// This prevents analytics requests from delaying the loading of the page.
window.addEventListener('load', function() {
  // Sends a pageview for the initial pageload.
  ga('send', 'pageview');

  // Sends an event with the time to first paint data.
  sendTimeToFirstPaint();
});

کد بالا بارهای firstpaint را به Google Analytics گزارش می دهد، اما این تنها نیمی از داستان است. ما هنوز نیاز به پیگیری وضعیت کارگر خدمات داشتیم. در غیر این صورت نمی‌توانیم اولین زمان‌های رنگ‌بندی یک صفحه کنترل‌شده توسط کارگر خدماتی و یک صفحه غیرکنترل‌شده را با هم مقایسه کنیم.

تعیین وضعیت کارگر خدماتی

برای تعیین وضعیت فعلی سرویس‌کار، یک تابع ابزار ایجاد کردیم که یکی از سه مقدار را برمی‌گرداند:

• کنترل شده : یک کارگر خدماتی صفحه را کنترل می کند. در مورد IOWA نیز به این معنی است که تمام دارایی‌ها در حافظه پنهان ذخیره شده‌اند و صفحه به‌صورت آفلاین کار می‌کند.
• پشتیبانی شده : مرورگر از Service Worker پشتیبانی می‌کند، اما سرویس‌گر هنوز صفحه را کنترل نمی‌کند. این وضعیت مورد انتظار برای اولین بازدیدکنندگان است.
• پشتیبانی نشده : مرورگر کاربر از Service Worker پشتیبانی نمی کند.

function getServiceWorkerStatus() {
  if ('serviceWorker' in navigator) {
    return navigator.serviceWorker.controller ? 'controlled' : 'supported';
  } else {
    return 'unsupported';
  }
}

این تابع برای ما وضعیت سرویس دهنده را دریافت کرد. گام بعدی این بود که این وضعیت را با داده هایی که به Google Analytics ارسال می کردیم مرتبط کنیم.

ردیابی داده های سفارشی با ابعاد سفارشی

به طور پیش‌فرض، Google Analytics راه‌های زیادی را در اختیار شما قرار می‌دهد تا کل ترافیک خود را بر اساس ویژگی‌های کاربر، جلسه یا تعامل به گروه‌هایی تقسیم کنید. این ویژگی ها به عنوان ابعاد شناخته می شوند. ابعاد متداول توسعه دهندگان وب مواردی مانند مرورگر ، سیستم عامل یا دسته دستگاه است.

وضعیت کارمند سرویس ابعادی نیست که Google Analytics به طور پیش‌فرض ارائه می‌کند. با این حال، Google Analytics به شما این امکان را می دهد که ابعاد سفارشی خود را ایجاد کنید و آنها را هر طور که می خواهید تعریف کنید.

برای IOWA، یک بعد سفارشی به نام Service Worker Status ایجاد کردیم و دامنه آن را روی ضربه (یعنی در هر تعامل) تنظیم کردیم. 4 به هر بعد سفارشی که در Google Analytics ایجاد می‌کنید، یک شاخص منحصر به فرد در آن ویژگی داده می‌شود، و در کد رهگیری خود می‌توانید آن بعد را با نمایه آن ارجاع دهید. به عنوان مثال، اگر نمایه بعدی که ایجاد کردیم 1 بود، می‌توانیم منطق خود را به صورت زیر به‌روزرسانی کنیم تا رویداد firstpaint را برای شامل وضعیت سرویس‌کار ارسال کنیم:

ga('send', 'event', {
  eventCategory: 'Performance',
  eventAction: 'firstpaint',
  // Rounds to the nearest millisecond since
  // event values in Google Analytics must be integers.
  eventValue: Math.round(timeToFirstPaint)
  // Sends this as a non-interaction event,
  // so it doesn't affect bounce rate.
  nonInteraction: true,

  // Sets the current service worker status as the value of
  // `dimension1` for this event.
  dimension1: getServiceWorkerStatus()
});

این کار می کند، اما فقط وضعیت کارمند خدمات را با این رویداد خاص مرتبط می کند. از آنجایی که وضعیت Service Worker چیزی است که دانستن آن برای هر تعاملی مفید است، بهتر است آن را با تمام داده‌های ارسال شده به Google Analytics اضافه کنید.

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

ga('set', 'dimension1', getServiceWorkerStatus());

پس از تنظیم، این مقدار با تمام بازدیدهای بعدی برای بارگذاری صفحه فعلی ارسال می شود. اگر کاربر بعداً دوباره صفحه را بارگذاری کند، احتمالاً یک مقدار جدید از تابع getServiceWorkerStatus() بازگردانده می شود و آن مقدار روی شی ردیاب تنظیم می شود.

نکته ای سریع در مورد وضوح و خوانایی کد: از آنجایی که سایر افرادی که به این کد نگاه می کنند ممکن است ندانند به چه dimension1 اشاره دارد، همیشه بهتر است متغیری ایجاد کنید که نام ابعاد معنی دار را به مقادیری که analytics.js استفاده می کند نگاشت کند.

// Creates a map between custom dimension names and their index.
// This is particularly useful if you define lots of custom dimensions.
var customDimensions = {
  SERVICE_WORKER_STATUS: 'dimension1'
};

// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');

// Sets the service worker status on the tracker,
// so its value is included in all future hits.
ga('set', customDimensions.SERVICE_WORKER_STATUS, getServiceWorkerStatus());

// Postpones sending any hits until after the page has fully loaded.
// This prevents analytics requests from delaying the loading of the page.
window.addEventListener('load', function() {
  // Sends a pageview for the initial pageload.
  ga('send', 'pageview');

  // Sends an event with the time to first paint data.
  sendTimeToFirstPaint();
});

همانطور که اشاره کردم، ارسال بعد وضعیت Service Worker با هر ضربه به ما این امکان را می دهد که از آن هنگام گزارش در مورد هر معیاری استفاده کنیم.

همانطور که می بینید تقریباً 85٪ از کل بازدیدهای صفحه برای IOWA از مرورگرهایی بود که از service worker پشتیبانی می کردند .

نتایج: پاسخ به سوالات ما

هنگامی که شروع به جمع آوری داده ها برای پاسخ به سؤالات خود کردیم، می توانستیم در مورد آن داده ها گزارش دهیم تا نتایج را ببینیم. (توجه: تمام داده های Google Analytics نشان داده شده در اینجا نشان دهنده ترافیک واقعی وب سایت IOWA از 16 تا 22 مه 2016 است).

اولین سوالی که داشتیم این بود: آیا کش کردن سرویس‌دهنده عملکرد بیشتری نسبت به مکانیسم‌های ذخیره HTTP موجود در همه مرورگرها دارد؟

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

ابعادی که ما انتخاب کردیم:

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

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

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

"...بازدید از برنامه ما زمانی که توسط یک سرویس دهنده کنترل می شود، بسیار سریعتر از بازدیدهای غیر کنترل شده بارگیری می شود..."

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

میانگین زمان بارگذاری صفحه (رومیزی)
وضعیت کارگر خدماتی	نوع کاربر	میانگین زمان بارگذاری صفحه (میلی‌ثانیه)	اندازهی نمونه
کنترل شده است	بازدید کننده بازگشتی	2568	30860
پشتیبانی	بازدید کننده بازگشتی	3612	1289
پشتیبانی	بازدید کننده جدید	4664	21991

میانگین زمان بارگذاری صفحه (موبایل)
وضعیت کارگر خدماتی	نوع کاربر	میانگین زمان بارگذاری صفحه (ms)	اندازهی نمونه
کنترل شده است	بازدید کننده بازگشتی	3760	8162
پشتیبانی	بازدید کننده بازگشتی	4843	676
پشتیبانی	بازدید کننده جدید	6158	5779

ممکن است تعجب کنید که چگونه ممکن است یک بازدیدکننده بازگشتی که مرورگرش از سرویس‌کار پشتیبانی می‌کند، همیشه در یک حالت کنترل نشده باشد. چند توضیح ممکن برای این وجود دارد:

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

هر دوی این موقعیت ها نسبتاً نادر هستند. با مشاهده مقادیر Page Load Sample در ستون چهارم می‌توانیم آن را در داده‌ها ببینیم. توجه داشته باشید که ردیف های میانی نمونه بسیار کوچکتری نسبت به دو ردیف دیگر دارند.

سوال دوم ما این بود: کارگر خدماتی چه تاثیری بر تجربه بارگذاری سایت دارد؟

برای پاسخ به این سوال، یک گزارش سفارشی دیگر برای میانگین متریک ایجاد کردیم. مقدار رویداد و نتایج فیلتر شد تا فقط رویدادهای firstpaint ما را شامل شود. ما از ابعاد Device Category و بعد وضعیت Service Worker Custom خود استفاده کردیم.

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

"...کارمند خدمات تلفن همراه تاثیر بسیار کمتری بر زمان اولین نقاشی نسبت به بارگذاری کلی صفحه داشت."

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

دریافت توزیع یک معیار در Google Analytics

برای بدست آوردن توزیع بارهای firstpaint ، ما نیاز به دسترسی به نتایج فردی برای هر رویداد داریم. متأسفانه Google Analytics این کار را آسان نمی کند.

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

از آنجایی که نتایج گزارش را فقط می‌توان بر اساس ابعاد تقسیم کرد، باید مقدار متریک (در این مورد زمان firstpaint ) را به‌عنوان یک بعد سفارشی روی رویداد تنظیم می‌کردیم. برای انجام این کار، یک بعد سفارشی دیگر به نام Metric Value ایجاد کردیم و منطق ردیابی firstpaint خود را به صورت زیر به روز کردیم:

var customDimensions = {
  SERVICE_WORKER_STATUS: 'dimension1',
  <strong>METRIC_VALUE: 'dimension2'</strong>
};

// ...

function sendTimeToFirstPaint() {
  var timeToFirstPaint = getTimeToFirstPaintIfSupported();

  if (timeToFirstPaint) {
    var fields = {
      eventCategory: 'Performance',
      eventAction: 'firstpaint',
      // Rounds to the nearest millisecond since
      // event values in Google Analytics must be integers.
      eventValue: Math.round(timeToFirstPaint)
      // Sends this as a non-interaction event,
      // so it doesn't affect bounce rate.
      nonInteraction: true
    }

    <strong>// Sets the event value as a dimension to allow for breaking down the
    // results by individual metric values at reporting time.
    fields[customDimensions.METRIC_VALUE] = String(fields.eventValue);</strong>

    ga('send', 'event', fields);
  }
}

رابط وب Google Analytics در حال حاضر راهی برای تجسم توزیع مقادیر دلخواه متریک ارائه نمی دهد، اما با کمک Google Analytics Core Reporting API و کتابخانه Google Charts می توانیم نتایج خام را جستجو کرده و سپس خودمان یک هیستوگرام بسازیم.

به عنوان مثال، پیکربندی درخواست API زیر برای دریافت توزیع مقادیر firstpaint روی دسکتاپ با یک سرویس‌کار غیر کنترل‌شده استفاده شد.

{
  dateRanges: [{startDate: '2016-05-16', endDate: '2016-05-22'}],
  metrics: [{expression: 'ga:totalEvents'}],
  dimensions: [{name: 'ga:dimension2'}],
  dimensionFilterClauses: [
    {
      operator: 'AND',
      filters: [
        {
          dimensionName: 'ga:eventAction',
          operator: 'EXACT',
          expressions: ['firstpaint']
        },
        {
          dimensionName: 'ga:dimension1',
          operator: 'EXACT',
          expressions: ['supported']
        },
        {
          dimensionName: 'ga:deviceCategory',
          operator: 'EXACT',
          expressions: ['desktop']
        }
      ],
    }
  ],
  orderBys: [
    {
      fieldName: 'ga:dimension2',
      orderType: 'DIMENSION_AS_INTEGER'
    }
  ]
}

این درخواست API آرایه ای از مقادیر را برمی گرداند که شبیه این هستند (توجه: اینها فقط پنج نتیجه اول هستند). نتایج از کوچک‌ترین به بزرگ‌ترین مرتب‌سازی می‌شوند، بنابراین این ردیف‌ها سریع‌ترین زمان‌ها را نشان می‌دهند.

نتایج پاسخ API (پنج ردیف اول)
ga:dimension2	ga:totalEvents
4	3
5	2
6	10
7	8
8	10

در اینجا معنی این نتایج به زبان انگلیسی ساده آمده است:

• 3 رویداد وجود داشت که مقدار firstpaint 4 میلی ثانیه بود
• 2 رویداد وجود داشت که مقدار firstpaint 5 میلی ثانیه بود
• 10 رویداد وجود داشت که در آنها مقدار firstpaint 6 میلی ثانیه بود
• 8 رویداد وجود داشت که در آنها مقدار firstpaint 7 ms بود
• 10 رویداد وجود داشت که در آنها value firstpaint 8 ms بود
• و غیره.

از این نتایج می‌توانیم مقدار firstpaint را برای هر رویداد برون‌یابی کنیم و یک هیستوگرام از توزیع ایجاد کنیم. ما این کار را برای هر یک از جستارهایی که اجرا کردیم انجام دادیم.

در اینجا نحوه توزیع روی دسکتاپ با یک سرویس کار غیر کنترل شده (اما پشتیبانی شده) به نظر می رسد:

میانه زمان firstpaint برای توزیع فوق 912 میلی ثانیه است.

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

توجه داشته باشید که وقتی یک کارگر خدماتی صفحه را کنترل می کرد، بسیاری از بازدیدکنندگان اولین رنگ تقریباً فوری را با میانگین 583 میلی ثانیه تجربه کردند.

"...زمانی که یک کارگر خدماتی صفحه را کنترل می کرد، بسیاری از بازدیدکنندگان اولین رنگ تقریباً فوری را تجربه کردند..."

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

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

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

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

در اینجا چیزها در تلفن همراه به نظر می رسند:

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

"...در تلفن همراه، راه‌اندازی یک رشته سرویس بیکار بیشتر از دسکتاپ طول می‌کشد."

در اینجا تفکیک این تغییرات از میانه زمان اولین رنگ آمیزی در تلفن همراه و دسکتاپ است که بر اساس وضعیت سرویس دهنده گروه بندی شده است:

میانه زمان برای اولین نقاشی (ms)
وضعیت کارگر خدماتی	دسکتاپ	سیار
کنترل شده است	583	1634
پشتیبانی شده (کنترل نشده)	912	1933

در حالی که ساخت این تجسم‌های توزیع کمی زمان و تلاش بیشتری نسبت به ایجاد یک گزارش سفارشی در Google Analytics صرف کرده است، اما آنها به ما درک بسیار بهتری از نحوه تأثیر کارکنان خدمات بر عملکرد سایت ما نسبت به میانگین‌ها می‌دهند.

سایر تأثیرات کارگران خدماتی

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

دسترسی آفلاین

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

ارسال داده‌ها به Google Analytics نیاز به اتصال اینترنت دارد، اما نیازی به ارسال داده‌ها در زمان دقیق تعامل ندارد. گوگل آنالیتیکس از ارسال داده‌های تعاملی پس از آن با تعیین زمان افست (از طریق پارامتر qt ) پشتیبانی می‌کند.

در دو سال گذشته، IOWA از یک اسکریپت Service Worker استفاده کرده است که بازدیدهای ناموفق به Google Analytics را زمانی که کاربر آفلاین است شناسایی کرده و بعداً با پارامتر qt آنها را دوباره پخش می کند.

برای ردیابی آنلاین یا آفلاین بودن کاربر، یک بعد سفارشی به نام Online ایجاد کردیم و آن را روی مقدار navigator.onLine قرار دادیم، سپس به رویدادهای online و offline گوش دادیم و بعد را متناسب با آن به‌روزرسانی کردیم.

و برای اینکه بفهمیم آفلاین بودن یک کاربر در حین استفاده از IOWA چقدر رایج است، بخشی ایجاد کردیم که کاربران را با حداقل یک تعامل آفلاین هدف قرار می‌داد. به نظر می رسد، این تقریبا 5٪ از کاربران بود.

اعلان های فشاری

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

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

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

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

بسیار خوب است که می بینیم بیش از نیمی از کاربرانی که وارد سیستم شده اند دریافت اعلان های فشاری را انتخاب کرده اند.

بنرهای نصب اپلیکیشن

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

در IOWA، تعداد دفعات نمایش این دستورات به کاربر (و پذیرفته شدن آنها) را با کد زیر پیگیری کردیم:

window.addEventListener('beforeinstallprompt', function(event) {
  // Tracks that the user saw a prompt.
  ga('send', 'event', {
    eventCategory: 'installprompt',
    eventAction: 'fired'
  });

  event.userChoice.then(function(choiceResult) {
    // Tracks the users choice.
    ga('send', 'event', {
      eventCategory: 'installprompt',
      // `choiceResult.outcome` will be 'accepted' or 'dismissed'.
      eventAction: choiceResult.outcome,
      // `choiceResult.platform` will be 'web' or 'android' if the prompt was
      // accepted, or '' if the prompt was dismissed.
      eventLabel: choiceResult.platform
    });
  });
});

از بین کاربرانی که بنر نصب اپلیکیشن را دیدند، حدود 10 درصد آن را به صفحه اصلی خود اضافه کردند.

بهبودهای احتمالی ردیابی (برای دفعه بعد)

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

1. رویدادهای بیشتر مربوط به تجربه بار را ردیابی کنید

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

رویداد اولیه مرتبط با بارگذاری که ما ردیابی نکردیم (اما آرزو داشتیم داشته باشیم) نقطه ای است که در آن صفحه نمایش ناپدید می شود و کاربر می تواند محتوای صفحه را ببیند.

2. شناسه سرویس گیرنده تجزیه و تحلیل را در IndexedDB ذخیره کنید

به طور پیش فرض، analytics.js فیلد شناسه مشتری را در کوکی های مرورگر ذخیره می کند. متأسفانه اسکریپت‌های Service Worker نمی‌توانند به کوکی‌ها دسترسی داشته باشند.

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

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

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

3. به کارمند خدمات اجازه دهید وضعیت آنلاین/آفلاین را گزارش کند

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

در آینده باید هم وضعیت navigator.onLine و هم اینکه آیا ضربه توسط سرویس‌کار به دلیل خرابی اولیه شبکه پخش شده است را ردیابی کنیم. این به ما تصویر دقیق تری از استفاده واقعی آفلاین می دهد.

بسته شدن

این مطالعه موردی نشان داده است که استفاده از سرویس‌کار در واقع عملکرد بارگذاری برنامه وب Google I/O را در طیف وسیعی از مرورگرها، شبکه‌ها و دستگاه‌ها بهبود بخشیده است. همچنین نشان داده است که وقتی به توزیع داده‌های بار در طیف گسترده‌ای از مرورگرها، شبکه‌ها و دستگاه‌ها نگاه می‌کنید، بینش بسیار بیشتری در مورد نحوه مدیریت این فناوری سناریوهای دنیای واقعی دریافت می‌کنید و ویژگی‌های عملکردی را کشف می‌کنید انتظار نداشتند

در اینجا برخی از نکات کلیدی از مطالعه IOWA آورده شده است:

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

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

اگر سرویس کارگر را در برنامه خود پیاده سازی می کنید، مهم است که استراتژی اندازه گیری خود را پیاده سازی کنید تا بتوانید عملکرد خود را ارزیابی کرده و از رگرسیون آینده جلوگیری کنید. اگر این کار را می کنید، لطفاً نتایج خود را به اشتراک بگذارید تا همه بتوانند از آن بهره ببرند!

پانویسها و منابع

1. این کاملاً منصفانه نیست که عملکرد اجرای کش سرویس کارگر ما را با عملکرد سایت خود تنها با کش HTTP مقایسه کنیم. از آنجایی که ما در حال بهینه سازی IOWA برای سرویس دهنده بودیم، زمان زیادی را برای بهینه سازی حافظه پنهان HTTP صرف نکردیم. اگر داشتیم، احتمالاً نتایج متفاوت بود. برای کسب اطلاعات بیشتر در مورد بهینه سازی سایت خود برای حافظه پنهان HTTP، بهینه سازی محتوا را به طور موثر بخوانید.
2. بسته به نحوه بارگیری سبک ها و محتوای سایت شما، ممکن است مرورگر بتواند قبل از در دسترس بودن محتوا یا سبک ها، نقاشی کند. در چنین مواردی، firstpaint ممکن است با یک صفحه سفید خالی مطابقت داشته باشد. اگر از firstpaint استفاده می کنید، مهم است که اطمینان حاصل کنید که با یک نقطه معنی دار در بارگذاری منابع سایت شما مطابقت دارد.
3. از نظر فنی، می‌توانیم یک ضربه زمان‌بندی (که به‌طور پیش‌فرض بدون تعامل هستند) برای ثبت این اطلاعات به جای یک رویداد ارسال کنیم. در واقع، بازدیدهای زمان‌بندی به طور خاص به Google Analytics اضافه شدند تا معیارهای بارگذاری مانند این را ردیابی کنند. با این حال، بازدیدهای زمان‌بندی به‌شدت در زمان پردازش نمونه‌برداری می‌شوند و مقادیر آن‌ها را نمی‌توان در بخش‌ها استفاده کرد. با توجه به این محدودیت‌های فعلی، رویدادهای غیرتعاملی مناسب‌تر هستند.
4. برای درک بهتر اینکه چه محدوده ای برای دادن یک بعد سفارشی در Google Analytics باید به بخش Custom Dimension مرکز راهنمای Analytics مراجعه کنید. همچنین درک مدل داده Google Analytics که از کاربران، جلسات و تعاملات (بازدیدها) تشکیل شده است، مهم است. برای کسب اطلاعات بیشتر، درس آکادمی Analytics را در مورد مدل داده Google Analytics تماشا کنید.
5. این برای منابعی که پس از رویداد بارگذاری به صورت تنبل بارگذاری شده اند، حساب نمی شود.