معیار تأخیر ورودی اول (FID) چیست؟
همه ما می‌دانیم که ایجاد یک احساس خوب در برخورد اول چقدر مهم است. همانطور که این مساله هنگام ملاقات با افراد جدید بسیار مهم است، در مورد تجربیات در وب نیز اهمیت بالایی دارد. معیار تأخیر ورودی اول (FID) نشان‌دهنده همین تجربه در وب است.
در وب، اولین برداشت خوب می‌تواند تفاوتی را بین تبدیل شدن شخصی به کاربر وفادار یا خروج و عدم بازگشت ایجاد کند. سوال این است که چه چیزی باعث ایجاد تأثیر خوب می‌شود و چگونه می توان نوع برداشتی کاربران را اندازه گیری کرد؟
در وب، اولین برداشت‌ها می‌توانند اشکال مختلف داشته باشند – مانند اولین برداشت از طراحی سایت و جذابیت بصری و همچنین اولین برداشت از سرعت و پاسخگویی.
در حالی که اندازه گیری اینکه کاربران چقدر طراحی سایت را دوست دارند سخت است، اما اندازه‌گیری سرعت و پاسخگویی آن چنین نیست!
اولین برداشت کاربران از اینکه سرعت بارگذاری سایت شما با First Contentful Paint (FCP) چقدر سریع است قابل اندازه‌گیری است. اما اینکه سایت شما با چه سرعتی می‌تواند پیکسل‌های صفحه را پر کند، تنها بخشی از داستان است. به همان اندازه میزان توانایی تعامل و پاسخگویی سایت شما با کاربرانی که سعی در استفاده از عناصر صفحه را دارند هم مهم است.
معیار تأخیر ورودی اول (FID) به اندازه‌گیری اولین برداشت کاربر از تعامل و پاسخگویی سایت شما کمک می‌کند.
معیار تأخیر ورودی اول (FID) چیست؟
FID از زمانی که کاربر برای اولین بار با یک صفحه ارتباط برقرار می‌کند (به عنوان مثال هنگامی که روی لینک کلیک می‌کند، روی دکمه‌ای ضربه می‌زند یا از کنترل سفارشی با استفاده از JavaScript استفاده می‌کند) تا زمانی که مرورگر در واقع در پاسخ به آن تعامل قادر به پردازش کنترل کننده‌های رویداد است، اندازه گیری می‌کند.
چه امتیازی برای معیار تأخیر ورودی اول (FID) خوب محسوب می‌شود؟
برای ایجاد یک تجربه کاربری خوب، سایت‌ها باید تلاش کنند تا تأخیر ورودی اول 100 میلی‌ثانیه یا کمتر داشته باشند. برای اطمینان از رسیدن به این هدف برای بیشتر کاربران، یک آستانه خوب برای اندازه‌گیری، رسیدن به این آستانه در ۷۵ درصد بار بارگیری صفحه است که در دستگاه‌های تلفن همراه و دسکتاپ اتفاق می‌افتد.
جزییات معیار تأخیر ورودی اول (FID)
توسعه‌دهندگانی که کدی را می‌نویسند که به رویدادها پاسخ می‌دهد، اغلب تصور می‌کنند که کد به محض وقوع رویداد بلافاصله اجرا می‌شود. اما به عنوان کاربران، همه ما به طور مکرر برعکس این مسئله را تجربه کرده‌ایم – یک صفحه وب را در تلفن خود بارگیری کرده‌ایم، سعی کرده‌ایم با آن تعامل داشته باشیم و بعد از اینکه اتفاقی نیفتاده ناامید شده‌ایم.
به طور کلی، تأخیر ورودی به این دلیل اتفاق می‌افتد که ترد (thread) اصلی مرورگر مشغول انجام کار دیگری است، بنابراین (در آن لحظه) نمی‌تواند به کاربر پاسخ دهد. یک دلیل رایج ممکن است این اتفاق باشد، مرورگر مشغول تجزیه و اجرای یک فایل جاوا اسکریپت بزرگ است که توسط برنامه شما بارگذاری شده است. در حالی که این کار را انجام می‌دهد، نمی‌تواند شنوندگان(listeners) رویداد را اجرا کند زیرا JavaScript که بارگیری می‌کند ممکن است به او بگوید کار دیگری انجام دهد.
جدول زمانی زیر را برای بارگذاری معمول صفحه وب در نظر بگیرید:
تصویر فوق صفحه‌ای را نشان می‌دهد که چندین درخواست شبکه برای منابع (به احتمال زیاد فایل‌های CSS و JS) ایجاد می‌کند و – پس از اتمام بارگیری این منابع – در ترد اصلی پردازش می‌شوند.
این نتیجه در دوره‌هایی است که ترد اصلی لحظه‌ای مشغول است، که توسط بلوک‌های کار بژ رنگ نشان داده می‌شوند.
تأخیرهای ورودی اول طولانی معمولاً بین First Contentful Paint (FCP) و Time to Interactive (TTI) رخ می‌دهد زیرا این صفحه برخی از محتوای خود را ارائه داده است اما هنوز به طور کامل تعاملی نیست. برای نشان دادن چگونگی این اتفاق ، FCP و TTI به جدول زمانی اضافه شده‌اند:
ممکن است متوجه شده باشید که بین FCP و TTI زمان نسبتاً کمی (از جمله سه تسک طولانی) وجود دارد، اگر کاربر در آن مدت سعی کند با صفحه ارتباط برقرار کند (به عنوان مثال روی لینک کلیک کند)، بین زمانی کلیک و هنگامی که ترد اصلی قادر به پاسخگویی است، تاخیری به وجود خواهد آمد.
در نظر بگیرید که اگر یک کاربر سعی کند با صفحه، نزدیک به ابتدای طولانی ترین کار تعامل کند چه اتفاقی می‌افتد:
از آنجا که ورودی در حالی وارد شده است که مرورگر در وسط اجرای یک کار است، باید صبر کند تا کار به پایان برسد تا مرورگر بتواند به ورودی پاسخ دهد. زمان انتظار، همان مقدار FID برای این کاربر در این صفحه می‌باشد.
اگر یک تعامل شنونده رویداد (event listener) نداشته باشد، چه اتفاقی می‌افتد؟
FID، تفاوت زمانی که یک رویداد ورودی دریافت می‌کند و زمانی که ترد اصلی بیکار است را اندازه می‌گیرد. این بدان معناست که FID حتی در مواردی که شنونده رویداد ثبت نشده است، اندازه‌گیری می‌شود. دلیل این امر این است که بسیاری از تعاملات کاربر به یک شنونده رویداد احتیاج ندارند اما برای اجرای آن نیاز به بیکار شدن ترد اصلی است.
به عنوان مثال، همه عناصر HTML زیر قبل از پاسخ به تعاملات کاربر باید منتظر بمانند تا کارهای در حال انجام روی ترد اصلی تکمیل شود:
-
زمینه‌های نوشتاری، چک‌باکس‌ها و دکمه‌های رادیویی (<input> ، <textarea>).
-
گزینه‌های کشویی انتخاب (<select>).
-
لینک‌ها (<a>).
چرا فقط ورودی اول را در نظر می‌گیریم؟
در حالی که تأخیر از هر ورودی می‌تواند منجر به تجربه کاربری بدی شود، به چند دلیل توصیه می‌کنیم اولین تاخیر ورودی را اندازه‌گیری کنید:
-
اولین تأخیر ورودی اولین برداشت کاربر از پاسخگویی سایت شما خواهد بود و اولین برداشت‌ها در شکل‌گیری تأثیر کلی ما درباره کیفیت و قابلیت اطمینان سایت بسیار مهم است.
-
بیشترین مشکلات تعاملی که امروزه در وب مشاهده می‌کنیم در هنگام بارگذاری صفحه رخ می‌دهد. بنابراین، ما اعتقاد داریم که در ابتدا تمرکز بر بهبود اولین تعامل کاربر سایت بیشترین تأثیر را در بهبود تعامل کل وب خواهد داشت.
-
راه‌حل‌های پیشنهادی برای اینکه چگونه سایت‌ها تأخیرهای ورودی اول بالا را برطرف کنند (تقسیم کد، بارگیری کمتر جاوا اسکریپت از قبل و غیره) لزوماً راه‌حل‌های یکسانی برای رفع تأخیر ورودی آهسته پس از بارگذاری صفحه نیستند. با تفکیک این معیارها، می‌توانیم دستورالعمل‌های عملکرد ویژه‌تری را به توسعه‌دهندگان وب ارائه دهیم.
چه‌چیزی به عنوان ورودی اول در نظر گرفته می‌شود؟
FID معیاری است که میزان پاسخگویی صفحه را هنگام بارگیری اندازه‌گیری می‌کند. به همین دلیل، فقط بر روی رویدادهای ورودی از اقدامات مجزا مانند کلیک، ضربه و فشار دادن کلید تمرکز می‌کند.
فعل و انفعالات دیگر، مانند اسکرول و بزرگنمایی، اقدامات مستمری هستند و محدودیت‌های عملکرد کاملاً متفاوتی دارند (همچنین، مرورگرها اغلب می‌توانند تاخیر خود را با اجرای آنها در یک موضوع جداگانه پنهان کنند).
به عبارت دیگر، FID بر روی R (پاسخگویی) در مدل عملکرد RAIL تمرکز دارد، در حالی که اسکرول و بزرگنمایی بیشتر مربوط به A (انیمیشن) است و کیفیت عملکرد آنها باید جداگانه ارزیابی شود.
اگر کاربری تعاملی با سایت شما نداشت چه اتفاقی می‌افتد؟
همه کاربران در هر بار بازدید با سایت شما ارتباط برقرار نخواهند کرد، و همه تعاملات مربوط به FID نیستند (همانطور که در بخش قبلی ذکر شد). بعلاوه، اولین تعاملات برخی از کاربران در مواقع بد (زمانی که ترد اصلی برای مدت زمان طولانی مشغول است) انجام خواهند شد و اولین تعاملات برخی دیگر از کاربران در اوقات خوب (زمانی که ترد اصلی کاملاً بیکار است) خواهند بود.
این بدان معناست که برخی از کاربران هیچ مقدار FID ندارند، برخی از کاربران دارای مقادیر FID کم و برخی از کاربران احتمالاً مقادیر FID بالایی دارند.
نحوه ردیابی، گزارش و تجزیه و تحلیل FID احتمالاً کاملاً متفاوت از سایر معیارهایی است که شما تا حالا استفاده کرده‌اید. بخش بعدی چگونگی انجام این کار را توضیح می‌دهد.
چرا فقط تأخیر ورودی را در نظر می‌گیریم؟
همانطور که در بالا ذکر شد، FID فقط “تأخیر” در پردازش رویداد را اندازه‌گیری می‌کند. این معیار نه زمان پردازش رویداد را اندازه می‌گیرد و نه زمانی را که مرورگر برای به روزرسانی UI پس از اجرای برنامه‌های کنترل رویداد نیاز دارد.
اگرچه این زمان برای کاربر مهم است و تجربه را تحت تأثیر قرار می‌دهد، اما در این معیار گنجانده نشده است، زیرا انجام این کار می‌تواند باعث ایجاد انگیزه در برنامه‌نویسان برای افزودن راهکارهایی شود که در واقع باعث بدتر شدن تجربه می‌شوند. یعنی آنها می‌توانند برای جدا کردن از وظیفه مرتبط با رویداد، منطق کنترل‌کننده رویداد خود را در یک کال‌بک ناهمگام قرار دهند (از طریق setTimeout () یا requestAnimationFrame ()). نتیجه می‌تواند بهبود در نمره معیار باشد در حالی که پاسخ کندتری توسط کاربر درک می‌شود.
با این حال، در حالی که FID فقط میزان “تأخیر” تأخیر رویداد را اندازه‌گیری می‌کند، توسعه‌دهندگانی که می‌خواهند بیشتر چرخه عمر رویداد را ردیابی کنند، می‌توانند با استفاده از API زمانبندی رویداد این کار را انجام دهند.
اندازه‌گیری معیار تأخیر ورودی اول (FID)
FID معیاری است که فقط در حالت عملیاتی قابل اندازه‌گیری است، زیرا برای تعامل با صفحه شما به یک کاربر واقعی نیاز دارد. می توانید FID را با ابزار زیر اندازه‌گیری کنید.
اندازه‌گیری معیار تأخیر ورودی اول (FID) در جاوااسکریپت
برای اندازه‌گیری FID در JavaScript، می‌توانید از Event Timing API استفاده کنید. مثال زیر نحوه ایجاد PerformanceObserver را نشان می‌دهد که ورودی‌های ورودی اول را گوش می‌کند و آنها را در کنسول ثبت می‌کند:
|
1 2 3 4 5 6 |
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 خواهد بود. با این حال، همه ورودی‌های ورودی اول برای اندازه‌گیری FID معتبر نیستند.
در بخش زیر تفاوت بین گزارش‌های API و نحوه محاسبه FID ذکر شده است:
-
API، ورودی‌های ورودی اول را برای صفحات بارگیری شده در یک برگه پس زمینه ارسال می‌کند اما هنگام محاسبه FID نباید از این صفحات چشم پوشی کرد.
-
اگر صفحه قبل از اولین ورودی صفحه پس زمینه داشته باشد، API، ورودی‌های ورودی اول را نیز ارسال می‌کند، اما هنگام محاسبه FID، این صفحات نیز باید نادیده گرفته شوند (ورودی‌ها فقط درصورتی که صفحه در کل زمان در پیش زمینه باشد در نظر گرفته می‌شوند).
-
هنگام بازگرداندن صفحه از کش بک/ فرانت، API، ورودی‌های ورودی اول را گزارش نمی‌کند، اما FID باید در این موارد اندازه‌گیری شود زیرا کاربران آنها را به عنوان بازدیدهای صفحه تجربه می‌کنند.
-
API، ورودی‌هایی را که درون iframes رخ می‌دهند گزارش نمی‌کند، اما برای اندازه‌گیری صحیح FID باید آنها را در نظر بگیرید. فریم‌های فرعی می‌توانند با استفاده از API ورودی‌های ورودی اول خود را برای تجمیع در فریم والد گزارش دهند.
توسعه‌دهندگان به جای اینکه همه این تفاوت‌های ظریف را بخاطر بسپارند، می‌توانند برای اندازه‌گیری FID از کتابخانه جاوا اسکریپت web-vitals استفاده کنند که این اختلافات را برای شما کنترل می‌کند (در صورت امکان).
|
1 2 3 |
import {getFID} from 'web-vitals'; // Measure and log FID as soon as it's available. getFID(console.log); |
تحلیل و گزارش FID
با توجه به واریانس مورد انتظار در مقادیر FID، بسیار مهم است که هنگام گزارش دادن در FID به توزیع مقادیر توجه کرده و روی درصدهای بالاتر تمرکز کنید.
در حالی که انتخاب درصد برای همه آستانه های (Core Web Vital) ۷۵ درصد است، اما در مورد FID اکیداً توصیه می‌کنیم که درصدهای ۹۵ تا ۹۹ را بخاطر داشته باشید، زیرا این موارد مربوط به اولین برداشت کاربران از سایت شما خواهد بود.
حتی بهتر است گزارشات خود را بر اساس دسته یا نوع دستگاه تقسیم کنید. به عنوان مثال، اگر گزارشات جداگانه‌ای برای دسکتاپ و موبایل اجرا می‌کنید، مقدار FID مورد توجه شما در دسکتاپ باید ۹۵–۹۹ درصد کاربران دسکتاپ باشد و مقدار FID مورد توجه شما در تلفن همراه باید ۹۵–۹۹ کاربران موبایل باشد.
بهبود امتیاز FID
در مقاله‌ای جداگانه به طور کامل در مورد راه‌های بهبود FID صحبت کرده‌ایم که برای مشاهده آن مقاله می‌توانید به آن مراجعه کنید. (لینک)
منبع: