تاخیر در پاسخ به اولین تعامل FID

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

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

مقدمه

تأخیر ورودی اول (FID) یک معیار مهم core web vitals و کاربر محور برای اندازه گیری میزان واکنش پذیری صفحه است، زیرا تجربه ای را که کاربران هنگام تلاش برای تعامل با صفحات فاقد تعامل احساس می‌کنند بهبود می‌بخشد- هر اندازه که زمان تاخیر اولین تعامل کاربر پایین تر باشد، کاربر حس بهتری نسبت به محتوای شما پیدا می‌کند.

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

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

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

معیارFirst Input Delay (FID) کمک می‌کند تا بتوانید اولین برداشت کاربر از تعامل و پاسخگویی سایت شما را اندازه گیری کنید.

FID چیست ؟

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

معیار تأخیر ورودی اول (FID) کمک می کند تا اولین برداشت کاربر از تعامل و پاسخگویی سایت شما را اندازه گیری کنید.
First Input Delay (FID)

بهترین امتیاز در FID چقدر است ؟

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

جزییات بیشتر در مورد FID

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

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

FID فقط “تاخیر” را در پردازش رویداد اندازه گیری می‌کند نه زمان پردازش خود رویداد و زمانی که مرورگر برای به روز رسانی UI پس از اجرای کنترل کننده های رویداد نیاز دارد. در حالی که این زمان ها نیز بر تجربه کاربر تأثیر می‌گذارند.

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

برخورد مرورگر با درخواست های شبکه برای منابع در مقابل پردازش اصلی خود مرورگر
برخورد مرورگر با درخواست های شبکه برای منابع در مقابل پردازش اصلی خود مرورگر

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

اولین تأخیرهای طولانی در ورودی معمولاً بین First Contentful Paint (FCP) و Time to Interactive (TTI) رخ می‌دهد، زیرا در این فاصله صفحه برخی از محتویات خود را باگذاری کرده اما هنوز به طور قابل اعتماد تعاملی نیستند. برای نشان دادن چگونگی این اتفاق در نمودار زیر ، FCP و TTI به فرایند پردازش صفحه وب اضافه شده اند

برخورد مرورگر با درخواست های شبکه برای منابع در مقابل پردازش اصلی خود مرورگر
برخورد مرورگر با درخواست های شبکه برای منابع در مقابل پردازش اصلی خود مرورگر

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

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

برخورد مرورگر با درخواست های شبکه برای منابع در مقابل پردازش اصلی خود مرورگر
برخورد مرورگر با درخواست های شبکه برای منابع در مقابل پردازش اصلی خود مرورگر

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

اگر یک تعامل، شنونده رویداد (event listener) نداشته باشد چه اتفاقی می‌افتد؟

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

به عنوان مثال ، همه عناصر HTML زیر باید منتظرتکمیل فرایند در حال ئردازش فعلی برای انجام تعاملات خود دارند

  • فیلدهای نوشتاری ، کادرهای تأیید و دکمه های رادیویی (<input>, <textarea>)
  • منوی کشویی (<select>)
  • لینک ها (<a>)

چرا فقط ورودی اول در نظر گرفته می‌شود؟

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

  • First Input Delay اولین برداشت کاربر از پاسخگویی سایت شما خواهد بود و اولین برداشت ها در شکل گیری تصور کلی ما از کیفیت و قابلیت اطمینان بودن سایت بسیار مهم است.
  • بزرگترین مسائل تعاملی که امروزه در وب مشاهده می‌کنیم در هنگام بارگیری صفحه رخ می‌دهد. بنابراین ، گوگل معتقد است که در ابتدا تمرکز بر بهبود اولین تعامل کاربر، بیشترین تأثیر را در بهبود تعامل کلی وب خواهد داشت.
  • راه حل های توصیه شده برای نحوه رفع تاخیرهای اولیه در ورودی ها (تقسیم کد ، بارگذاری کمتر جاوا اسکریپت و غیره) لزوماً راه حل های یکسانی برای کاهش FID نیستند.

چه چیزی به عنوان اولین ورودی محاسبه می‌شود؟

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

به بیان دیگر ، FID بر روی R (واکنش پذیری) در مدل عملکرد RAIL تمرکز می‌کند ، در حالی که پیمایش و بزرگنمایی بیشتر به A (انیمیشن) مربوط می‌شود و ویژگی های عملکرد آنها باید به طور جداگانه ارزیابی شود.

اگر کاربری با سایت شما تعامل برقرار نکند چه می‌شود؟

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

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

چرا باید تاخیر ورودی را در نظر بگیریم؟

همانطور که در بالا ذکر شد، FID فقط “تاخیر” را در پردازش رویداد اندازه گیری می‌کند. این خود زمان پردازش رویداد را اندازه گیری نمی‌کند و نه زمانی که مرورگر برای به روز رسانی UI پس از اجرای کنترل کننده های رویداد نیاز دارد. اگرچه این زمان ها برای کاربر مهم است و بر تجربه او تأثیر می‌گذارد ، در این معیار گنجانده نشده است.

با این حال ، در حالی که FID تنها بخش “تاخیر” رویداد را اندازه گیری می‌کند ، توسعه دهندگانی که می‌خواهند چرخه عمر رویداد را بیشتر دنبال کنند می‌توانند با استفاده از API زمان بندی رویداد این کار را انجام دهند.

نحوه اندازه گیری FID

FID به یک کاربر واقعی برای اندازه‌گیری نیاز دارد و بنابراین در آزمایشگاه قابل اندازه گیری نیست. با این حال معیار کل زمان مسدودسازی (TBT) قابل اندازه گیری آزمایشگاهی است ، به خوبی با FID در این زمینه ارتباط دارد و همچنین مواردی را که بر تعامل تأثیر می‌گذارد ، ضبط می‌کند. بهینه سازی هایی که TBT را در آزمایشگاه بهبود می‌بخشند ، باید FID را برای کاربران شما نیز بهبود بخشند.جهت کسب اطلاعات بیشتر در مورد اندازه گیری می توانید به مقاله شروع کار با اندازه گیری web vitals را نیز مطالعه بفرمایید.

ابزارهای میدانی

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

برای اندازه گیری FID در جاوا اسکریپت ، می‌توانید از API زمان بندی رویداد استفاده کنید. مثال زیر نحوه ایجاد a PerformanceObserver را نشان می‌دهد که به ورودی رویدادها گوش می‌دهد و آنها را به کنسول وارد می‌کند.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

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

تفاوت بین محاسبه با API و روش متریک

  • first-input برای تب های پس زمینه در API محاسبه می‌شود در حالی که در FID نباید این ورودی ها را لحاض کرد
  • اگر صفحه قبل از وقوع first-input دارای پس زمینه بوده است در api محاسبه می‌شود اما هنگام محاسبه FID این صفحات نیز باید نادیده گرفته شوند (ورودی ها فقط در صورتی در نظر گرفته می شوند که صفحه در تمام مدت به عنوان صفحه فعال بوده باشد).
  • اگر fi صفحات به وسیله دکمه های back/forward دسترسی پیدا کنیم API این صفحات را نادیده می‌گیره در حالی که باید FID برای آنها نیز محاسبه شود.
  • API ورودی هایی را که در iframes رخ می دهد گزارش نمی کند ، اما برای اندازه گیری صحیح ترFID باید آنها را در نظر بگیرید.

به جای سروکله زدن با همه این تفاوت های ظریف ، توسعه دهندگان می توانند از کتابخانه جاوا اسکریپت web-vitals برای اندازه گیری FID استفاده کنند .

import {getFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
getFID(console.log);

چگونه FID را بهبود ببخشیم؟

برای یادگیری نحوه بهبود FID برای یک سایت خاص ، میتوانید پیشنهاد های Lighthouse بر روی سایت خود را اجرا کرده و خروجی را مشاهده کنید.البته که FID یک معیار میدانی است (و Lighthouse یک ابزار اندازه گیری آزمایشگاهی است) ، راهنمایی که برای بهبود FID ارائه می‌شود همان است که برای بهبود متریک آزمایشگاهی زمان کل مسدودسازی (TBT) ارائه می شود.

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

  • کاهش تأثیر کدها third-party (شخص ثالث).
  • کاهش زمان اجرای جاوا اسکریپت.
  • حجم کار نخ اصلی را به حداقل برسانید.
  • تعداد درخواست ها را کم نگه دارید و اندازه های انتقالی را کوچک کنید.

این مقاله تشریح تقریبا کاملی بر First Input Delay (تاخیر اولین ورودی) است، امیدواریم بتوانیم این مقاله را به روز نگه داریم و اطلاعات بیشتری به آن بیفزایم منتظر نظرات و پیشنهادات شما هستیم.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *