FID چیست؟ راه های بهبود First Input Delay

First Input Delay سه کلمهٔ ساده است که اتفاقاً به مفهوم پیچیده‌ای اشاره دارد. همین ابتدا بگوییم که اگر پایین بودن امتیاز FID شما را به این صفحه کشانده است، کارهای زیادی برای انجام دادن دارید. اما جای نگرانی نیست. در این مقاله با شما هستیم تا بررسی کنیم اصلاً FID چیست و سرکله‌اش از کجا پیدا می‌شود؟ سپس ساده‌ترین و موثرترین راهکارهای بهینه‌سازی آن را ارائه کنیم.

FID چیست؟

منظور از FID سرواژه‌ای از عبارت First Input Delay است که به فارسی «تأخیر اولین ورودی داده» ترجمه می‌شود. FID یکی از فاکتورهای اصلی سنجش پرفورمنس سایت با معیارهای حیاتی‌ وب است. این فاکتور درواقع نشان می‌دهد که بین تعامل کاربر با صفحه تا زمانی که مرورگر بتواند واقعاً به این درخواست پاسخ بدهد، چقدر فاصله است. این فاکتور کمی پیچیده‌تر از سایر فاکتورهای حیاتی وب است و نمی‌توان آن را در محیط تست شبیه‌سازی کرد.

عدد خوب برای FID چیست؟

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

با تمام این‌ها، گوگل عدد ۲.۵ ثانیه را برای فاکتور FID خوب می‌داند. عدد ۴ و بالاتر از آن بسیار ضعیف است. هر عددی بین ۲.۵ و ۴ در ابزارهای گوگل با عنوان Needs improvement نمایش داده می‌شود و به بهینه‌سازی نیاز دارد.

چرا عدد FID سایت بالا می‌رود؟

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

پیشنهاد خواندن: ‌TTFB چیست؟ راه های بهبود TTFB یا Time to First Byte

FID در جزئیات چگونه است؟

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

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

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

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

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

حالا فرض کنید اگر کاربر بخواهد همان حوالی طولانی‌ترین تسک با صفحه تعامل برقرار کند چه خواهد شد:

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

اگر تعامل event listener نداشته باشد چه؟

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

مثلاً تمام المان‌های HTML زیر باید پیش از پاسخ به تعامل کاربر، منتظر تکمیل تسک رشتهٔ اصلی بمانند:

فیلدهای نوشتاری، چک باکس‌ها و دکمه‌های رادیویی (<input>، <textarea>)
انتخاب در منوهای کشویی (<select>)
لینک‌ها (<link>)

چرا فقط باید اولین ورودی (input) را در نظر بگیریم؟

این که تأخیر از هر نوع ورودی کاملاً می‌تواند روی تجربهٔ کاربری تاثیربگذارد، درست است. اما تأخیر اولین ورودی به دلایل زیر مهم‌تر است:

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

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

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

اصلاً چه مواردی به عنوان اولین ورودی به حساب می‌آیند؟

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

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

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

طبیعی است که تمام بازدیدکنندگان سایت شما تا مرحلهٔ تعامل پیش نروند. اصلاً تمام تعامل‌ها هم لزوماً به FID ربط ندارند. تازه حتی برخی از اولین تعاملات کاربر در زمان‌های مشغول بودن و برخی دیگر از تعامل‌ها در زمان بیکاری رشتهٔ اصلی صورت می‌گیرند.

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

چطور FID را اندازه‌گیری کنیم؟

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

ابزارهایی که می‌توانند در تخمین FID به شما کمک کنند، عبارتند از:
گزارش‌های تجربه کاربری در گوگل کروم
PageSpeed Insights
گزارش Core Web Vitals در ابزار سرچ کنسول
کتابخانه جاوا اسکریپت web-vitals

اگر کارتان با API هم خوب است، می‌توانید از Event Timing API هم برای اندازه گیری FID در جاوا اسکریپت استفاده کنید.

پیشنهاد خواندن: CLS چیست؟ راه حل بهبود CLS یا Cumulative Layout Shift

آموزش کامل بهبود FID

خیلی خب! به ماجرای اصلی خوش آمدید. حالا شناخت خوبی از FID دارید و می‌توانید بهینه‌سازی را آغاز کنید. برای این بهینه‌سازی ۴ راه‌کار پیش روی شماست:

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

در ادامه هریک از این راهکارها را به تفصیل بررسی خواهیم کرد.

نحوهٔ خرد کردن تسک‌های طولانی جاوا اسکریپت

به‌طور کلی هر تسکی که بیش از ۵۰ میلی ثانیه، رشتهٔ اصلی را درگیر کند؛ تسک سنگینی است که احتمال Bloat شدن را به همراه دارد. این تسک‌ها اصطلاحاً UI سایت شما را فریز می‌کنند و به کاربر اجازه تعامل نمی‌دهند. پیش از هر چیز لازم است با استفاده از یک ابزار حرفه‌ای مثل Chrome Dev tool این اسکریپت‌های سنگین را شناسایی کنید. سپس با مهارت‌های جاوا اسکریپت خود آن‌ها را به تسک‌هایی تبدیل کنید که زیر ۵۰ میلی‌ثانیه انجام شوند. فیل والتون در کتاب خود Idle Until Urgent به‌خوبی نحوهٔ انجام این کارها را توضیح داده است.

نحوهٔ بهینه‌سازی صفحات به سمت تعامل‌محور

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

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

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

حذف یا انتقال اسکریپت‌های سنگین غیرضروری نیز راهکار خوبی برای بهبود تعامل است.

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

داده‌های درون خطی بزرگ می‌توانند زمان آنالیز HTML را کاهش دهند و بر معیارهای رنگ و تعامل تأثیر بگذارند. بهتر است مقدار داده‌هایی که باید در سمت کلاینت پردازش شوند را به حداقل برسانید.

اجرای اسکریپت شخص ثالث می‌تواند تأخیر تعامل را نیز به تأخیر بیندازد.

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

بسیاری از سایت‌ها دارای برچسب‌ها و تجزیه و تحلیل‌های شخص ثالث هستند که می‌توانند شبکه را مشغول نگه دارند و موضوع اصلی را به طور دوره‌ای پاسخگو نمی‌شوند و بر تأخیر تعامل تأثیر می‌گذارند. بارگیری درخواستی کد شخص ثالث را کاوش کنید. (مثلاً ممکن است تبلیغات below-the-fold تا زمانی که به کاربر تا نزدیکی viewport اسکرول نکند، بارگذاری نشوند)

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

نحوه بهینه‌سازی Web Worker ها

بلاک شدن رشتهٔ اصلی یکی از اصلی‌ترین دلایل تأخیر ورودی است. Web Worker ها امکان اجرای جاوا اسکریپت را بر روی یک رشته در پس‌زمینه فراهم می‌کنند. حال اگر عملیات غیر UI به یک رشتهٔ مجزا انتقال یابد، زمان بلاک شدن رشتهٔ اصلی کاهش یافته و به بهینه‌سازی فاکتور FID سایت نزدیک‌تر خواهیم شد.

برای به‌کارگیری ساده‌تر Web Worker ها می‌توانید از این کتابخانه‌ها کمک بگیرید:

Comlink: این کتابخانه postMessage را خلاصه می‌کند و استفاده از آن را آسان‌تر می‌کند.
Workway: این کتابخانه منبع خوبی برای ارائه وب‌ورکرهای عمومی است.
Workerize: با استفاده از این کتابخانه می‌توانید ماژول‌‌ها را به وب‌ورکر منتقل کنید.

نحوهٔ کاهش زمان اجرای جاوا اسکریپت

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

جاوا اسکریپت استفاده نشده را به تعویق بیندازید.
polyfill‌های استفاده نشده را به حداقل برسانید.

چطور جاوا اسکریپت‌های استفاده نشده را به تعویق بیندازیم؟

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

تب Coverage در Chrome DevTools می‌تواند به شما بگوید که چه مقدار از جاوا اسکریپت در صفحه وب شما استفاده نمی‌شود.

بررسی جاوا اسکریپت در تب Coverage گوگل کروم

برای کاهش جاوا اسکریپت استفاده نشده می‌توانید:

بسته نرم افزاری خود را با کد به چند تکه تقسیم کنید.
جاوا اسکریپت غیرضروری را (مثل اسکریپت‌های شخص ثالث) استفاده از async یا defer به تعویق بیندازید.

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

import(‘module.js’).then((module) => {

// Do something with the module.

})

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

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

اگر از webpack، Rollup یا Parcel به عنوان باندلر ماژول استفاده می‌کنید، پیشنهاد می‌کنیم از پشتیبانی ایمپورت داینامیک آن‌ها استفاده کنید.

به یاد داشته باشید که وایرفریم‌های سمت کلاینت، مانند React، Angular و Vue،امکان lazyloading را ساده‌تر می‌کنند.

سوالات متداول

۱. FID‌ چیست؟

یکی از فاکتورهای حیاتی وب به‌نام First Imput Delay است که مدت زمان بین ارسال درخواست کاربر تا قابل تعامل شدن صفحه وب‌ را اندازه می‌گیرد.

۲. عدد خوب برای FID چیست؟

از نظر گوگل عدد ۲.۵ ثانیه برای فاکتور FID خوب، عدد ۴ و بالاتر از آن بسیار ضعیف و هر عددی بین ۲.۵ و ۴ نیازمند بهبود است.

۳. چطور FID را بهینه‌سازی کنیم؟

بهترین راه برای بهینه‌سازی فاکتور FID، فشرده‌سازی جاوا اسکریپت و حذف اسکریپت‌های اضافه و یا کاهش زمان کار اسکریپت‌ها و وب‌ورکرهاست.

جمع بندی

در این مقاله بررسی کردیم که FID چیست و بهینه سازی فاکتور FID سایت چطور انجام می‌شود. با این حال همیشه بخشی از دانش، نزد دیگران است. درست به‌همین دلیل پیشنهاد می‌کنیم اگر روش‌های دیگری برای بهبودFirst Input Delay می‌شناسید از بخش نظرات زیر همین پست با سایر کاربران به اشتراک بگذارید.

نعیمه نخعی

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

نظر شما راجع به این محتوا چیست؟