بازخورد مورد نیاز: یک معیار سنجش پاسخگویی آزمایشی

به روز رسانی در مورد برنامه های ما برای اندازه گیری پاسخگویی در وب.

Hongbo Song

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

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

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

تأخیر تعامل را اندازه گیری کنید

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

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

ما همچنین قصد داریم به جای رویدادهای فردی ، تعاملات را اندازه گیری کنیم. فعل و انفعالات گروهی از رویدادها هستند که به عنوان بخشی از یک اشاره منطقی کاربر ارسال می شوند (به عنوان مثال: pointerdown ، click ، pointerup ).

برای اندازه گیری تأخیر کل تعامل از یک گروه از مدت زمان رویداد فردی، ما دو رویکرد بالقوه را در نظر می گیریم:

• حداکثر مدت زمان رویداد: تأخیر تعامل برابر با بزرگترین مدت زمان رویداد از هر رویداد در گروه تعامل است.
• مدت زمان کل رویداد: تأخیر تعامل مجموع تمام مدت زمان رویداد است، بدون توجه به همپوشانی.

به عنوان مثال، نمودار زیر یک تعامل با فشار کلید را نشان می دهد که از یک keydown و یک رویداد keyup تشکیل شده است. در این مثال یک همپوشانی مدت زمان بین این دو رویداد وجود دارد. برای اندازه‌گیری تأخیر تعامل فشار کلید، می‌توانیم از max(keydown duration, keyup duration) یا sum(keydown duration, keyup duration) - duration overlap استفاده کنیم:

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

همه تعاملات را در هر صفحه جمع کنید

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

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

گزینه های استراتژی های تجمیع

برای کمک به توضیح هر یک از استراتژی های زیر، یک نمونه بازدید از صفحه را در نظر بگیرید که شامل چهار تعامل است:

بدترین تأخیر تعامل

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

استراتژی های بودجه

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

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

بدترین تأخیر تعامل بیش از بودجه

بزرگترین تأخیر یک تعامل بیش از بودجه. با استفاده از مثال بالا، امتیاز max(20, 0, 10, 30) = 30 ms خواهد بود.

کل تأخیر تعامل بیش از بودجه

مجموع تمام تأخیرهای تعامل بیش از بودجه. با استفاده از مثال بالا، امتیاز (20 + 0 + 10 + 30) = 60 ms خواهد بود.

متوسط ​​تأخیر تعامل بیش از بودجه

کل تأخیر تعامل بیش از حد بودجه تقسیم بر تعداد کل تعاملات. با استفاده از مثال بالا، امتیاز (20 + 0 + 10 + 30) / 4 = 15 ms خواهد بود.

تقریب کمیت بالا

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

• گزینه 1: بزرگترین و دومین تعاملات بزرگ را از نظر بودجه پیگیری کنید. بعد از هر 50 تعامل جدید، بزرگترین تعامل را از مجموعه 50 قبلی حذف کنید و بزرگترین تعامل را از مجموعه 50 فعلی اضافه کنید. مقدار نهایی، بزرگترین تعامل باقی مانده بیش از بودجه خواهد بود.
• گزینه 2: بزرگترین 10 تعامل را با بودجه محاسبه کنید و بسته به تعداد کل تعاملات، مقداری را از آن لیست انتخاب کنید. با توجه به N کل تعامل، (N / 50 + 1) بزرگترین مقدار یا دهمین مقدار را برای صفحات با بیش از 500 تعامل انتخاب کنید.

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

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

const interactionMap = new Map();

let worstLatency = 0;
let worstLatencyOverBudget = 0;
let totalLatencyOverBudget = 0;

new PerformanceObserver((entries) => {
  for (const entry of entries.getEntries()) {
    // Ignore entries without an interaction ID.
    if (entry.interactionId > 0) {
      // Get the interaction for this entry, or create one if it doesn't exist.
      let interaction = interactionMap.get(entry.interactionId);
      if (!interaction) {
        interaction = {latency: 0, entries: []};
        interactionMap.set(entry.interactionId, interaction);
      }
      interaction.entries.push(entry);

      const latency = Math.max(entry.duration, interaction.latency);
      worstLatency = Math.max(worstLatency, latency);

      const budget = entry.name.includes('key') ? 50 : 100;
      const latencyOverBudget = Math.max(latency - budget, 0);
      worstLatencyOverBudget = Math.max(
        latencyOverBudget,
        worstLatencyOverBudget,
      );

      if (latencyOverBudget) {
        const oldLatencyOverBudget = Math.max(interaction.latency - budget, 0);
        totalLatencyOverBudget += latencyOverBudget - oldLatencyOverBudget;
      }

      // Set the latency on the interaction so future events can reference.
      interaction.latency = latency;

      // Log the updated metric values.
      console.log({
        worstLatency,
        worstLatencyOverBudget,
        totalLatencyOverBudget,
      });
    }
  }
  // Set the `durationThreshold` to 50 to capture keyboard interactions
  // that are over-budget (the default `durationThreshold` is 100).
}).observe({type: 'event', buffered: true, durationThreshold: 50});

بازخورد

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

هر گونه بازخورد کلی در مورد رویکردهای ذکر شده در اینجا را به گروه Google web-vitals-feedback با "[Responsiveness Metrics]" در خط موضوع ایمیل کنید. ما واقعا مشتاقانه منتظر شنیدن نظر شما هستیم!

به روز رسانی در مورد برنامه های ما برای اندازه گیری پاسخگویی در وب.

Hongbo Song

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

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

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

تأخیر تعامل را اندازه گیری کنید

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

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

ما همچنین قصد داریم به جای رویدادهای فردی ، تعاملات را اندازه گیری کنیم. فعل و انفعالات گروهی از رویدادها هستند که به عنوان بخشی از یک اشاره منطقی کاربر ارسال می شوند (به عنوان مثال: pointerdown ، click ، pointerup ).

برای اندازه گیری تأخیر کل تعامل از یک گروه از مدت زمان رویداد فردی، ما دو رویکرد بالقوه را در نظر می گیریم:

• حداکثر مدت زمان رویداد: تأخیر تعامل برابر با بزرگترین مدت زمان رویداد از هر رویداد در گروه تعامل است.
• مدت زمان کل رویداد: تأخیر تعامل مجموع تمام مدت زمان رویداد است، بدون توجه به همپوشانی.

به عنوان مثال، نمودار زیر یک تعامل با فشار کلید را نشان می دهد که از یک keydown و یک رویداد keyup تشکیل شده است. در این مثال یک همپوشانی مدت زمان بین این دو رویداد وجود دارد. برای اندازه‌گیری تأخیر تعامل فشار کلید، می‌توانیم از max(keydown duration, keyup duration) یا sum(keydown duration, keyup duration) - duration overlap استفاده کنیم:

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

همه تعاملات را در هر صفحه جمع کنید

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

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

گزینه های استراتژی های تجمیع

برای کمک به توضیح هر یک از استراتژی های زیر، یک نمونه بازدید از صفحه را در نظر بگیرید که شامل چهار تعامل است:

بدترین تأخیر تعامل

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

استراتژی های بودجه

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

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

بدترین تأخیر تعامل بیش از بودجه

بزرگترین تأخیر یک تعامل بیش از بودجه. با استفاده از مثال بالا، امتیاز max(20, 0, 10, 30) = 30 ms خواهد بود.

کل تأخیر تعامل بیش از بودجه

مجموع تمام تأخیرهای تعامل بیش از بودجه. با استفاده از مثال بالا، امتیاز (20 + 0 + 10 + 30) = 60 ms خواهد بود.

متوسط ​​تأخیر تعامل بیش از بودجه

کل تأخیر تعامل بیش از حد بودجه تقسیم بر تعداد کل تعاملات. با استفاده از مثال بالا، امتیاز (20 + 0 + 10 + 30) / 4 = 15 ms خواهد بود.

تقریب کمیت بالا

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

• گزینه 1: بزرگترین و دومین تعاملات بزرگ را از نظر بودجه پیگیری کنید. بعد از هر 50 تعامل جدید، بزرگترین تعامل را از مجموعه 50 قبلی حذف کنید و بزرگترین تعامل را از مجموعه 50 فعلی اضافه کنید. مقدار نهایی، بزرگترین تعامل باقی مانده بیش از بودجه خواهد بود.
• گزینه 2: بزرگترین 10 تعامل را با بودجه محاسبه کنید و بسته به تعداد کل تعاملات، مقداری را از آن لیست انتخاب کنید. با توجه به N کل تعامل، (N / 50 + 1) بزرگترین مقدار یا دهمین مقدار را برای صفحات با بیش از 500 تعامل انتخاب کنید.

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

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

const interactionMap = new Map();

let worstLatency = 0;
let worstLatencyOverBudget = 0;
let totalLatencyOverBudget = 0;

new PerformanceObserver((entries) => {
  for (const entry of entries.getEntries()) {
    // Ignore entries without an interaction ID.
    if (entry.interactionId > 0) {
      // Get the interaction for this entry, or create one if it doesn't exist.
      let interaction = interactionMap.get(entry.interactionId);
      if (!interaction) {
        interaction = {latency: 0, entries: []};
        interactionMap.set(entry.interactionId, interaction);
      }
      interaction.entries.push(entry);

      const latency = Math.max(entry.duration, interaction.latency);
      worstLatency = Math.max(worstLatency, latency);

      const budget = entry.name.includes('key') ? 50 : 100;
      const latencyOverBudget = Math.max(latency - budget, 0);
      worstLatencyOverBudget = Math.max(
        latencyOverBudget,
        worstLatencyOverBudget,
      );

      if (latencyOverBudget) {
        const oldLatencyOverBudget = Math.max(interaction.latency - budget, 0);
        totalLatencyOverBudget += latencyOverBudget - oldLatencyOverBudget;
      }

      // Set the latency on the interaction so future events can reference.
      interaction.latency = latency;

      // Log the updated metric values.
      console.log({
        worstLatency,
        worstLatencyOverBudget,
        totalLatencyOverBudget,
      });
    }
  }
  // Set the `durationThreshold` to 50 to capture keyboard interactions
  // that are over-budget (the default `durationThreshold` is 100).
}).observe({type: 'event', buffered: true, durationThreshold: 50});

بازخورد

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

هر گونه بازخورد کلی در مورد رویکردهای ذکر شده در اینجا را به گروه Google web-vitals-feedback با "[Responsiveness Metrics]" در خط موضوع ایمیل کنید. ما واقعا مشتاقانه منتظر شنیدن نظر شما هستیم!