این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

به سمت یک معیار پاسخگویی بهتر

درباره افکار ما در مورد سنجش میزان پاسخگویی بیاموزید و به ما بازخورد بدهید.

Annie Sullivan

Hongbo Song

Nicolás Peña Moreno

در تیم Chrome Speed Metrics، ما در حال کار بر روی درک عمیق خود از سرعت واکنش صفحات وب به ورودی کاربر هستیم. مایلیم چند ایده برای بهبود معیارهای پاسخگویی به اشتراک بگذاریم و بازخورد شما را بشنویم.

این پست دو موضوع اصلی را پوشش خواهد داد:

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

تاخیر ورودی اول چیست؟

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

click
keydown
mousedown
pointerdown (فقط اگر با pointerup دنبال شود)

نمودار زیر FID را نشان می دهد:

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

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

چرا FID را انتخاب کردیم؟

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

معیارهای دیگر مانند زمان انسداد کل (TBT) و زمان تعامل (TTI) بر اساس وظایف طولانی هستند و مانند FID، زمان مسدود شدن رشته اصلی را در طول بارگذاری نیز اندازه گیری می کنند. از آنجایی که این معیارها را می توان هم در میدان و هم در آزمایشگاه اندازه گیری کرد، بسیاری از توسعه دهندگان پرسیده اند که چرا یکی از این معیارها را به FID ترجیح نمی دهیم.

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

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

یادداشتی در مورد اندازه گیری TTI در این زمینه

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

چه پیشرفت هایی را در نظر داریم؟

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

ما می خواهیم معیار جدید به این صورت باشد:

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

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

مدت زمان کامل رویداد را ضبط کنید

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

مراحل مختلفی در چرخه حیات یک رویداد وجود دارد که در این نمودار نشان داده شده است:

پنج مرحله در چرخه حیات یک رویداد

مراحل زیر کروم برای پردازش یک ورودی انجام می‌دهد:

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

زمان بین مراحل (1) و (3) بالا تاخیر یک رویداد است که FID اندازه گیری می کند.

زمان بین مراحل (1) و (5) بالا مدت زمان یک رویداد است. این همان چیزی است که معیار جدید ما اندازه گیری می کند.

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

یادداشتی در مورد وظایف ناهمزمان

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

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

رویدادها را در تعاملات گروه بندی کنید

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

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

انواع تعامل

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

رویدادهای DOM برای هر نوع تعامل.
اثر متقابل	شروع / پایان	رویدادهای دسکتاپ	رویدادهای موبایل
صفحه کلید	کلید فشار داده شد	`keydown`	`keydown`
	کلید فشار داده شد	`keypress`	`keypress`
	کلید آزاد شد	`keyup`	`keyup`
ضربه بزنید یا بکشید	روی شروع ضربه بزنید یا شروع را بکشید	`pointerdown`	`pointerdown`
	روی شروع ضربه بزنید یا شروع را بکشید	`mousedown`	`touchstart`
	به بالا ضربه بزنید یا انتهای آن را بکشید	`pointerup`	`pointerup`
		`mouseup`	`touchend`
		`click`	`mousedown`
			`mouseup`
			`click`
طومار	N/A

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

یادداشتی در مورد شروع و پایان

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

صفحه کلید

تعامل صفحه کلید دو بخش دارد: زمانی که کاربر کلید را فشار می دهد و زمانی که آن را رها می کند. سه رویداد مرتبط با این تعامل کاربر وجود دارد: keydown ، keyup ، و keypress . نمودار زیر تأخیرها و مدت زمان keydown و keyup را برای تعامل با صفحه کلید نشان می دهد:

تعامل صفحه کلید با مدت زمان رویدادهای غیرمجاز

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

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

به منظور ثبت کل زمان صرف شده توسط تعامل صفحه کلید، ما می توانیم حداکثر مدت زمان keydown و رویدادهای keyup را محاسبه کنیم.

توجه: رویداد keypress منسوخ شده است، و باید در همان کاری که رویداد keydown اجرا می‌شود، اجرا شود، بنابراین مدت زمان آن همیشه با مدت زمان keydown همپوشانی دارد.

یادداشتی در مورد تکرار فشار دادن کلید

در اینجا یک مورد لبه وجود دارد که قابل ذکر است: ممکن است مواردی وجود داشته باشد که کاربر کلیدی را فشار داده و مدتی طول بکشد تا آن را آزاد کند. در این مورد، توالی رویدادهای ارسال شده می تواند متفاوت باشد . در این موارد، ما در نظر می گیریم که یک تعامل در هر keydown وجود داشته باشد، که ممکن است دارای یک keyup مربوطه باشد یا نداشته باشد.

ضربه زدن

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

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

ما می‌خواهیم مدت‌زمان رویداد را برای همه این رویدادها لحاظ کنیم، اما از آنجایی که بسیاری از آنها کاملاً همپوشانی دارند، باید فقط pointerdown ، pointerup و click تا تعامل کامل را پوشش دهیم.

آیا می‌توانیم فقط به pointerdown و pointerup محدودتر شویم؟

یک فکر اولیه این است که از رویدادهای pointerdown و pointerup استفاده کنیم و فرض کنیم که آنها تمام مدت زمان مورد علاقه ما را پوشش می دهند. متأسفانه، همانطور که این مورد لبه نشان می دهد، اینطور نیست. سعی کنید این سایت را در تلفن همراه یا با شبیه‌سازی موبایل باز کنید و روی جایی که می‌گوید «روی من کلیک کنید» ضربه بزنید. این سایت تاخیر ضربه زدن مرورگر را فعال می کند. مشاهده می شود که pointerdown ، pointerup و touchend به سرعت ارسال می شوند، در حالی که mousedown ، mouseup و click قبل از ارسال منتظر تاخیر باشید. این بدان معناست که اگر ما فقط به pointerdown و pointerup نگاه کنیم، مدت زمان رویدادهای مصنوعی را از دست می‌دهیم، که به دلیل تأخیر ضربه زدن مرورگر زیاد است و باید لحاظ شود. بنابراین ما باید pointerdown ، pointerup را اندازه گیری کنیم و click تا تعامل کامل را پوشش دهیم.

بکشید

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

ما همچنین درگ‌هایی را که از طریق Drag and Drop API پیاده‌سازی می‌شوند در نظر نمی‌گیریم زیرا آنها فقط روی دسکتاپ کار می‌کنند.

پیمایش

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

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

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

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

چگونه تاخیر یک تعامل را تعریف کنیم؟

همانطور که در بالا اشاره کردیم، تعاملاتی که دارای یک جزء "پایین" و "بالا" هستند باید به طور جداگانه در نظر گرفته شوند تا از نسبت دادن زمانی که کاربر صرف نگه داشتن انگشت خود کرده است جلوگیری شود.

برای این نوع تعامل‌ها، ما می‌خواهیم تأخیر شامل مدت زمان همه رویدادهای مرتبط با آنها باشد. از آنجایی که مدت‌زمان رویداد برای هر بخش «پایین» و «بالا» تعامل می‌تواند همپوشانی داشته باشد، ساده‌ترین تعریف تأخیر تعامل که به این امر دست می‌یابد، حداکثر مدت زمان هر رویداد مرتبط با آن است. با مراجعه به نمودار صفحه کلید قبلی، این مدت زمان keydown است، زیرا طولانی تر از keyup است:

تعامل صفحه کلید با حداکثر مدت زمان برجسته شده است

همچنین ممکن است مدت زمان keydown و keyup با هم همپوشانی داشته باشند. این ممکن است برای مثال زمانی اتفاق بیفتد که فریم ارائه شده برای هر دو رویداد یکسان باشد، مانند نمودار زیر:

تعامل صفحه کلید که در آن فشار دادن و رها کردن در یک قاب اتفاق می افتد

این رویکرد استفاده از حداکثر مزایا و معایبی دارد و ما علاقه مند به شنیدن نظرات شما هستیم:

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

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

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

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

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

برای انجام این تجمیع باید دو سوال را حل کنیم:

سعی می کنیم چه اعدادی را جمع کنیم؟
چگونه آن اعداد را جمع کنیم؟

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

یک گزینه این است که بودجه ای برای تأخیر یک تعامل تعریف کنید، که ممکن است به نوع آن (پیمایش، صفحه کلید، ضربه زدن یا کشیدن) بستگی داشته باشد. بنابراین برای مثال اگر بودجه ضربه‌ها 100 میلی‌ثانیه باشد و تأخیر ضربه‌ای 150 میلی‌ثانیه باشد، آن‌گاه مقدار بیش از بودجه برای آن تعامل 50 میلی‌ثانیه خواهد بود. سپس می‌توانیم حداکثر میزان تأخیر را که بیش از بودجه برای هر تعامل کاربر در صفحه است محاسبه کنیم.

گزینه دیگر محاسبه میانگین یا متوسط تأخیر تعاملات در طول عمر صفحه است. بنابراین اگر تاخیرهای 80 ms، 90 ms و 100 ms داشته باشیم، متوسط تاخیر برای صفحه 90 میلی ثانیه خواهد بود. همچنین می‌توانیم میانگین یا میانه «بیش از بودجه» را برای محاسبه انتظارات مختلف بسته به نوع تعامل در نظر بگیریم.

این در APIهای عملکرد وب چگونه به نظر می رسد؟

چه چیزی از زمان بندی رویداد کم است؟

متأسفانه نمی توان همه ایده های ارائه شده در این پست را با استفاده از Event Timing API دریافت کرد. به طور خاص، هیچ راه ساده ای برای دانستن رویدادهای مرتبط با تعامل کاربر معین با API وجود ندارد. برای انجام این کار، اضافه کردن interactionID به API را پیشنهاد کرده‌ایم .

یکی دیگر از کاستی‌های Event Timing API این است که هیچ راهی برای اندازه‌گیری تعامل اسکرول وجود ندارد، بنابراین ما در حال کار بر روی فعال کردن این اندازه‌گیری‌ها (از طریق رویداد زمان‌بندی یا یک API جداگانه) هستیم.

در حال حاضر چه چیزی را می توانید امتحان کنید؟

در حال حاضر، هنوز امکان محاسبه حداکثر تأخیر برای ضربه‌ها/کشیدن و تعاملات صفحه‌کلید وجود دارد. قطعه کد زیر این دو معیار را تولید می کند.

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

بازخورد

نظر خود را در مورد این ایده ها با ارسال ایمیل به ما بگویید: web-vitals-feedback@googlegroups.com!

درباره افکار ما در مورد سنجش میزان پاسخگویی بیاموزید و به ما بازخورد بدهید.

Annie Sullivan

Hongbo Song

Nicolás Peña Moreno

این پست دو موضوع اصلی را پوشش خواهد داد:

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

تاخیر ورودی اول چیست؟

click
keydown
mousedown
pointerdown (فقط اگر با pointerup دنبال شود)

نمودار زیر FID را نشان می دهد:

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

چرا FID را انتخاب کردیم؟

یادداشتی در مورد اندازه گیری TTI در این زمینه

چه پیشرفت هایی را در نظر داریم؟

ما می خواهیم معیار جدید به این صورت باشد:

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

مدت زمان کامل رویداد را ضبط کنید

مراحل مختلفی در چرخه حیات یک رویداد وجود دارد که در این نمودار نشان داده شده است:

پنج مرحله در چرخه حیات یک رویداد

مراحل زیر کروم برای پردازش یک ورودی انجام می‌دهد:

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

زمان بین مراحل (1) و (3) بالا تاخیر یک رویداد است که FID اندازه گیری می کند.

زمان بین مراحل (1) و (5) بالا مدت زمان یک رویداد است. این همان چیزی است که معیار جدید ما اندازه گیری می کند.

یادداشتی در مورد وظایف ناهمزمان

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

رویدادهای گروهی به تعامل

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

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

انواع تعامل

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

رویدادهای DOM برای هر نوع تعامل.
اثر متقابل	شروع / پایان	رویدادهای رومیزی	رویدادهای سیار
صفحه کلید	کلید فشار داده شد	`keydown`	`keydown`
	کلید فشار داده شد	`keypress`	`keypress`
	کلید آزاد شد	`keyup`	`keyup`
ضربه بزنید یا بکشید	روی شروع یا شروع کار ضربه بزنید	`pointerdown`	`pointerdown`
	روی شروع یا شروع کار ضربه بزنید	`mousedown`	`touchstart`
	روی Up یا Drag End ضربه بزنید	`pointerup`	`pointerup`
		`mouseup`	`touchend`
		`click`	`mousedown`
			`mouseup`
			`click`
طومار	N/A

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

یک یادداشت در شروع و پایان

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

صفحه کلید

تعامل صفحه کلید دارای دو بخش است: وقتی کاربر کلید را فشار می دهد و هنگام انتشار آن. سه رویداد مرتبط با این تعامل کاربر وجود دارد: keydown ، keyup و keypress . نمودار زیر تأخیرها و مدت زمان keydown و keyup را برای تعامل صفحه کلید نشان می دهد:

تعامل صفحه کلید با مدت زمان رویداد جداگانه

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

keydown و keypress هنگامی اتفاق می افتد که کاربر کلید را فشار دهد ، در حالی که keyup وقتی کاربر کلید را آزاد می کند اتفاق می افتد. به طور کلی به روزرسانی محتوای اصلی هنگام فشار دادن کلید رخ می دهد: متن روی صفحه نمایش داده می شود ، یا اثر اصلاح کننده اعمال می شود. به گفته این ، ما می خواهیم موارد نادرتر را ضبط کنیم که keyup نیز به روزرسانی های جالب UI را ارائه می دهد ، بنابراین می خواهیم به زمان کلی گرفته شده نگاه کنیم.

به منظور ضبط زمان کلی که توسط تعامل صفحه کلید گرفته شده است ، می توانیم حداکثر مدت زمان keydown و رویدادهای keyup را محاسبه کنیم.

توجه: رویداد keypress مستهلک می شود و باید در همان کار با رویداد keydown اخراج شود ، بنابراین مدت زمان آن همیشه با مدت زمان keydown همپوشانی دارد.

یک یادداشت در مورد تکرار کلید های

در اینجا یک مورد لبه وجود دارد که قابل ذکر است: ممکن است مواردی وجود داشته باشد که کاربر یک کلید را فشار دهد و مدتی طول می کشد تا آن را آزاد کند. در این حالت ، دنباله وقایع اعزام شده می تواند متفاوت باشد . در این موارد ، ما در نظر می گیریم که یک تعامل در هر keydown وجود داشته باشد ، که ممکن است یک keyup مربوطه داشته باشد یا نباشد.

ضربه زدن

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

برای شیر یا کلیک ، نسخه به طور کلی همان چیزی است که باعث ایجاد اکثر واکنش ها می شود ، اما ، مانند تعامل صفحه کلید ، ما می خواهیم تعامل کامل را ضبط کنیم. و در این حالت انجام این کار مهمتر است زیرا داشتن برخی از به روزرسانی های UI در Tap Press در واقع غیر معمول نیست.

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

آیا می توانیم فقط به pointerdown و pointerup محدود شویم؟

یک فکر اولیه استفاده از رویدادهای pointerdown و pointerup است و فرض می کند که آنها تمام مدت زمان مورد علاقه ما را پوشش می دهند. متأسفانه ، همانطور که این مورد نشان می دهد اینگونه نیست. سعی کنید این سایت را در موبایل یا با شبیه سازی موبایل باز کنید و از جایی که می گوید "روی من کلیک کنید" ضربه بزنید. این سایت باعث تأخیر شیر مرورگر می شود. مشاهده می شود که pointerdown ، pointerup و touchend به سرعت ارسال می شود ، در حالی که mousedown ، mouseup و قبل از اعزام ، منتظر تأخیر click . این بدان معناست که اگر فقط به pointerdown و pointerup نگاه کنیم ، می خواهیم مدت زمان وقایع مصنوعی را از دست بدهیم ، که به دلیل تأخیر شیر مرورگر بزرگ است و باید گنجانده شود. بنابراین ما باید pointerdown ، pointerup را اندازه گیری کنیم و برای پوشش کامل تعامل click .

بکشید

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

ما همچنین در نظر نمی گیریم که Drags اجرا شده از طریق Drag و Drop API را اجرا کند زیرا آنها فقط روی دسک تاپ کار می کنند.

پیمایش

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

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

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

چندین رویداد وجود دارد که هنگام پیمایش کاربر مانند touchstart ، touchmove و scroll ارسال می شود. به جز رویداد پیمایش ، این تا حد زیادی به دستگاه مورد استفاده برای پیمایش بستگی دارد: هنگام پیمایش با انگشت روی دستگاه های تلفن همراه ، رویدادهای لمسی ارسال می شوند ، در حالی که هنگام پیمایش با چرخ ماوس ، وقایع چرخ اتفاق می افتد. وقایع پیمایش پس از اتمام پیمایش اولیه شلیک می شود. و به طور کلی ، هیچ رویداد DOM در حال پیمایش نیست ، مگر اینکه وب سایت از شنوندگان رویدادهای غیرقانونی استفاده کند. بنابراین ما فکر می کنیم که به طور کلی از وقایع DOM جدا شده است. آنچه ما می خواهیم اندازه گیری کنیم زمان زمانی است که کاربر به اندازه کافی حرکت می کند تا یک حرکت پیمایش را تولید کند تا اولین قاب که نشان می دهد پیمایش اتفاق افتاده است.

چگونه می توان تأخیر یک تعامل را تعریف کرد؟

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

برای این نوع تعامل ها ، ما می خواهیم تأخیر را شامل مدت زمان وقایع مرتبط با آنها باشد. از آنجا که مدت زمان رویداد برای هر "پایین" و "بالا" از تعامل می تواند با هم همپوشانی داشته باشد ، ساده ترین تعریف از تأخیر تعامل که به این امر دست می یابد ، حداکثر مدت زمان هر رویدادی مرتبط با آن است. با مراجعه به نمودار صفحه کلید از قبل ، این مدت زمان keydown است ، زیرا طولانی تر از keyup است:

تعامل صفحه کلید با حداکثر مدت زمان برجسته

مدت زمان keydown و keyup نیز ممکن است با هم همپوشانی داشته باشد. این ممکن است به عنوان مثال زمانی اتفاق بیفتد که قاب ارائه شده برای هر دو رویداد یکسان باشد ، مانند نمودار زیر:

تعامل صفحه کلید که در آن مطبوعات و انتشار در همان قاب اتفاق می افتد

جوانب مثبت و منفی برای استفاده از حداکثر وجود دارد ، و ما علاقه مند به شنیدن بازخورد شما هستیم:

PRO : این مطابق با نحوه اندازه گیری پیمایش در این است که فقط یک مقدار مدت زمان را اندازه گیری می کند.
PRO : هدف این است که برای مواردی مانند تعامل صفحه کلید ، سر و صدای کاهش یابد ، جایی که keyup معمولاً هیچ کاری انجام نمی دهد و در جایی که کاربر ممکن است مطبوعات کلید را اجرا کند و به سرعت یا آهسته آزاد شود.
CON : زمان انتظار کامل کاربر را ضبط نمی کند. به عنوان مثال ، شروع یا پایان یک کشیدن را ضبط می کند ، اما هر دو نیست.

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

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

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

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

برای انجام این تجمع باید دو سوال را حل کنیم:

چه اعدادی سعی می کنیم جمع شویم؟
چگونه می توانیم آن اعداد را جمع کنیم؟

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

یک گزینه تعریف بودجه برای تأخیر در تعامل است که ممکن است به نوع (پیمایش ، صفحه کلید ، شیر یا کشیدن) بستگی داشته باشد. به عنوان مثال اگر بودجه TAPS 100 میلی ثانیه باشد و تأخیر شیر 150 میلی ثانیه باشد ، مبلغ بیش از بودجه برای آن تعامل 50 میلی ثانیه خواهد بود. سپس می توانیم حداکثر میزان تأخیر را که بیش از بودجه برای هر تعامل کاربر در صفحه است ، محاسبه کنیم.

گزینه دیگر محاسبه تاخیر متوسط یا متوسط تعامل در طول زندگی صفحه است. بنابراین اگر زمان تأخیر 80 میلی ثانیه ، 90 میلی ثانیه و 100 میلی ثانیه داشتیم ، میانگین تأخیر برای این صفحه 90 میلی ثانیه خواهد بود. ما همچنین می توانیم میانگین یا متوسط "بیش از بودجه" را در نظر بگیریم تا بسته به نوع تعامل ، انتظارات مختلف را به خود اختصاص دهد.

این چگونه در API های عملکرد وب به نظر می رسد؟

چه چیزی از زمان رویداد از دست رفته است؟

متأسفانه همه ایده های ارائه شده در این پست با استفاده از API زمان بندی رویداد قابل ضبط نیستند. به طور خاص ، هیچ روش ساده ای برای دانستن وقایع مرتبط با تعامل کاربر خاص با API وجود ندارد. برای انجام این کار ، ما پیشنهاد کرده ایم که یک interactionID به API اضافه کنیم .

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

اکنون چه چیزی می توانید امتحان کنید؟

در حال حاضر ، هنوز هم می توان حداکثر تأخیر را برای شیرها/کشیدن و برای تعامل صفحه کلید محاسبه کرد. قطعه کد زیر این دو معیار را تولید می کند.

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

بازخورد

از طریق ایمیل به ما اطلاع دهید که در مورد این ایده ها چه فکر می کنید: وب-vitals-feedback@googlegroups.com!