First Input Delay (FID): راهنمای ساده برای درک تاخیر در تعاملات وب
هشدار: First Input Delay (FID) دیگر یک معیار Core Web Vital نیست و در ۹ سپتامبر ۲۰۲۴ با معیار Interaction to Next Paint (INP) جایگزین شده است. توصیه میشود بهجای FID، بر بهبود INP تمرکز کنید.
FID چیست؟
First Input Delay (FID) معیاری است که زمان تاخیر در اولین تعامل کاربر با یک صفحه وب را اندازهگیری میکند. این تعامل میتواند کلیک روی یک لینک، لمس یک دکمه، یا استفاده از کنترلهای سفارشی مبتنی بر جاوااسکریپت باشد. FID فاصله زمانی بین لحظهای که کاربر با صفحه تعامل میکند تا زمانی که مرورگر قادر به پردازش پاسخ به آن تعامل است را محاسبه میکند.
FID نشاندهنده اولین برداشت کاربر از پاسخگویی و تعاملی بودن وبسایت شماست. اولین برداشت در وب، مانند دیدار با افراد جدید، بسیار مهم است و میتواند تعیین کند که آیا کاربر به سایت شما وفادار میماند یا آن را ترک میکند.
چرا FID مهم است؟
یک تجربه کاربری خوب در وبسایت به عوامل مختلفی بستگی دارد، از جمله طراحی بصری، سرعت بارگذاری، و پاسخگویی به تعاملات کاربر. در حالی که اندازهگیری جذابیت طراحی با APIهای وب دشوار است، سرعت و پاسخگویی را میتوان بهراحتی با معیارهایی مانند FID ارزیابی کرد. FID به شما کمک میکند تا درک کنید که سایت شما چقدر سریع به اولین تعامل کاربر پاسخ میدهد، که بخش مهمی از تجربه کاربری است.
نکته کلیدی: FID فقط تاخیر در پردازش رویداد را اندازهگیری میکند، نه کل زمان پردازش رویداد یا بهروزرسانی رابط کاربری. این انتخاب به این دلیل است که گنجاندن کل زمان پردازش ممکن است توسعهدهندگان را به استفاده از راهحلهای غیرهمزمان (مانند setTimeout) تشویق کند که میتواند تجربه کاربری را بدتر کند.
امتیاز خوب برای FID چیست؟
برای ارائه تجربه کاربری خوب، سایتها باید به FID ۱۰۰ میلیثانیه یا کمتر برسند. برای اطمینان از اینکه این هدف برای اکثر کاربران محقق میشود، توصیه میشود معیار را در صدک ۷۵ (75th percentile) بارگذاریهای صفحه، برای دستگاههای موبایل و دسکتاپ بهصورت جداگانه، بررسی کنید.
توضیح تصویر: نموداری که نشان میدهد FID خوب ۱۰۰ میلیثانیه یا کمتر، FID ضعیف بیش از ۳۰۰ میلیثانیه، و مقادیر بین این دو نیاز به بهبود دارند.
نکته: برای اطلاعات بیشتر در مورد تحقیقات و روششناسی پشت این آستانهها، به تعریف آستانههای Core Web Vitals مراجعه کنید.
FID در جزئیات
تاخیر در تعاملات (Input Latency) معمولاً به این دلیل رخ میدهد که نخ اصلی (Main Thread) مرورگر مشغول انجام کارهای دیگر است و نمیتواند بلافاصله به تعامل کاربر پاسخ دهد. یکی از دلایل رایج این مشکل، پردازش فایلهای جاوااسکریپت بزرگ است که نخ اصلی را اشغال میکند و مانع اجرای شنوندههای رویداد (Event Listeners) میشود.
مثال: جدول زمانی بارگذاری صفحه
توضیح تصویر: نموداری که جدول زمانی بارگذاری یک صفحه وب را نشان میدهد، شامل درخواستهای شبکه، پردازش منابع، و دورههای مشغول بودن نخ اصلی.
در این جدول زمانی، بین First Contentful Paint (FCP) (نمایش اولین محتوای صفحه) و Time to Interactive (TTI) (زمان تعاملی شدن کامل صفحه)، دورههایی وجود دارد که نخ اصلی مشغول است. اگر کاربر در این دورهها با صفحه تعامل کند (مثلاً روی یک لینک کلیک کند)، مرورگر باید منتظر تکمیل وظیفه جاری بماند تا بتواند پاسخ دهد. این تاخیر همان FID است.
نکته: اگر کاربر درست قبل از یک دوره مشغول (Idle Period) با صفحه تعامل کند، ممکن است تاخیری وجود نداشته باشد. این تنوع در تاخیر ورودی نشاندهنده اهمیت بررسی توزیع مقادیر FID است.
اگر تعاملی شنونده رویداد نداشته باشد؟
FID حتی در مواردی که شنونده رویداد (Event Listener) ثبت نشده باشد نیز اندازهگیری میشود. عناصری مانند فیلدهای متنی (<input>، <textarea>)، چکباکسها، دکمههای رادیویی، منوهای کشویی (<select>)، و لینکها (<a>) برای پاسخ به تعاملات کاربر نیاز به آزاد بودن نخ اصلی دارند، حتی بدون شنونده رویداد.
چرا فقط اولین ورودی در نظر گرفته میشود؟
تمرکز بر اولین ورودی به دلایل زیر است:
- اولین برداشت: اولین تعامل کاربر، اولین برداشت او از پاسخگویی سایت را شکل میدهد.
- مشکلات بارگذاری: بزرگترین مشکلات تعاملی معمولاً در زمان بارگذاری صفحه رخ میدهند. بهبود FID میتواند تأثیر زیادی بر تجربه کلی وب داشته باشد.
- راهحلهای خاص: راهحلهای بهبود FID (مانند تقسیمبندی کد یا کاهش جاوااسکریپت اولیه) با راهحلهای بهبود تاخیرهای بعدی متفاوت است.
چه چیزی بهعنوان اولین ورودی محسوب میشود؟
FID فقط رویدادهای ورودی گسسته (Discrete) مانند کلیک، لمس، و فشار کلید را در نظر میگیرد. تعاملات پیوسته مانند اسکرول یا زوم، به دلیل تفاوت در محدودیتهای عملکردی و اجرای آنها در نخهای جداگانه، در FID گنجانده نمیشوند. FID بر پاسخگویی (Responsiveness) در مدل عملکرد RAIL تمرکز دارد.
اگر کاربر با سایت تعامل نکند؟
همه کاربران با سایت شما تعامل نمیکنند، و برخی تعاملات ممکن است برای FID مرتبط نباشند. همچنین، برخی کاربران ممکن است در زمانهای بد (وقتی نخ اصلی مشغول است) و برخی در زمانهای خوب (وقتی نخ اصلی آزاد است) تعامل کنند. این باعث میشود برخی کاربران FID نداشته باشند، برخی FID پایین و برخی FID بالا داشته باشند.
چرا فقط تاخیر ورودی در نظر گرفته میشود؟
FID فقط تاخیر در شروع پردازش رویداد را اندازهگیری میکند، نه کل زمان پردازش یا بهروزرسانی رابط کاربری. این انتخاب از تشویق توسعهدهندگان به استفاده از راهحلهای غیرهمزمان که ممکن است تجربه کاربری را بدتر کند، جلوگیری میکند. برای اندازهگیری کاملتر چرخه حیات رویداد، میتوانید از Event Timing API استفاده کنید.
نحوه اندازهگیری FID
FID تنها در محیط واقعی (Field) قابل اندازهگیری است، زیرا نیاز به تعامل واقعی کاربر دارد. ابزارهای زیر برای اندازهگیری FID مناسباند:
ابزارهای واقعی (Field)
- Chrome User Experience Report (CrUX): دادههای ناشناس کاربران واقعی را جمعآوری میکند.
- PageSpeed Insights: گزارشهای FID را بر اساس دادههای CrUX ارائه میدهد.
- Search Console (گزارش Core Web Vitals): عملکرد FID سایت را برای سئو نشان میدهد.
- کتابخانه web-vitals: یک کتابخانه جاوااسکریپت برای اندازهگیری FID.
نکته: FID در آزمایشگاه (Lab) قابل اندازهگیری نیست، اما معیار Total Blocking Time (TBT) که در آزمایشگاه قابل اندازهگیری است، با FID همبستگی دارد و میتواند به بهبود آن کمک کند.
اندازهگیری FID با جاوااسکریپت
برای اندازهگیری FID، میتوانید از Event Timing API استفاده کنید. نمونه کد زیر نشان میدهد چگونه یک PerformanceObserver برای ثبت ورودیهای first-input و محاسبه تاخیر آنها ایجاد کنید:
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});
هشدار: این کد فقط تاخیر ورودیهای first-input را ثبت میکند. محاسبه دقیق FID پیچیدهتر است، زیرا برخی ورودیها (مانند ورودیهای در صفحات پسزمینه یا iframeها) باید در نظر گرفته شوند یا نادیده گرفته شوند.
تفاوتهای بین معیار FID و API
- صفحات پسزمینه: API ورودیهای
first-inputرا برای صفحات بارگذاریشده در پسزمینه گزارش میدهد، اما این موارد نباید در FID محاسبه شوند. - ورودیهای پسزمینه: اگر صفحه قبل از اولین ورودی به پسزمینه منتقل شود، ورودیها نباید در FID گنجانده شوند.
- کش عقب/جلو (Back/Forward Cache): API ورودیها را در صفحات بازگردانیشده از کش گزارش نمیدهد، اما FID باید این موارد را در نظر بگیرد.
- Iframeها: API ورودیهای iframe را گزارش نمیدهد، اما FID باید آنها را برای تجربه کاربری کامل در نظر بگیرد.
نکته: در برخی موارد، مانند iframeهای بیندامنهای، اندازهگیری FID با جاوااسکریپت ممکن نیست.
تحلیل و گزارش دادههای FID
با توجه به تنوع در مقادیر FID، مهم است که توزیع دادهها را بررسی کنید و روی صدکهای بالاتر (مانند صدک ۹۵ تا ۹۹) تمرکز کنید. این صدکها نشاندهنده بدترین تجربیات کاربران هستند و مناطقی را که نیاز به بهبود دارند، مشخص میکنند. حتی اگر گزارشها را بر اساس نوع دستگاه (موبایل یا دسکتاپ) تقسیم کنید، باید صدکهای بالای هر دسته را بررسی کنید.
چگونه FID را بهبود دهیم؟
برای بهبود FID، میتوانید از راهنمای بهینهسازی FID استفاده کنید. برخی از تکنیکهای کلیدی شامل موارد زیر هستند:
- تقسیمبندی کد (Code Splitting): کاهش جاوااسکریپت بارگذاریشده در ابتدا.
- کاهش زمان اجرای جاوااسکریپت: بهینهسازی اسکریپتها برای آزاد کردن نخ اصلی.
- استفاده از کش: بهبود سرعت بارگذاری منابع.
تغییرات و بهروزرسانیها
معیارها و APIهای مربوط به FID ممکن است به دلیل کشف اشکالات یا بهبود تعاریف تغییر کنند. این تغییرات در Changelog ثبت میشوند. برای ارائه بازخورد در مورد FID یا سایر معیارهای Web Vitals، میتوانید به گروه web-vitals-feedback مراجعه کنید.
نتیجهگیری
هرچند FID دیگر یک معیار Core Web Vital نیست، درک آن همچنان برای بهبود پاسخگویی وبسایت مفید است. با تمرکز بر کاهش تاخیر اولین تعامل کاربر، استفاده از ابزارهای واقعی مانند CrUX و PageSpeed Insights، و بهینهسازیهایی مانند کاهش جاوااسکریپت، میتوانید تجربه کاربری بهتری ارائه دهید. اکنون که INP جایگزین FID شده است، توصیه میشود روی بهینهسازی INP تمرکز کنید تا تجربه تعاملی بهتری برای کاربران خود فراهم کنید.