FID چیست | تفاوت‌های بین Metric و API در FID

در مقاله FID چیست تفاوت‌های بین Metric و API به ادامه مقالات وب ویتال و سه بخش اصلی Core Web Vitals می پردازیم که در مقاله قبلی به طور کامل و جامع CLS را به شما آموزش دادیم. در این مقاله از سری مقالات تیک4 قصد داریم شما را تعریف FID و تفاوت‌های بین Metric و API آشنا کنیم. باما همراه باشید.

First Input Delay (FID) یا تأخیر اولین ورودی

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

همه ما می‌دانیم که خوب بودن اولین برداشت چقدر مهم است. این امر در ملاقات افراد جدید و همچنین به وجود آمدن تجربیاتی در مورد وب اینترنتی هم اهمیت دارد.

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

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

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

FID چیست؟

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

چه امتیازی برای FID خوب است؟

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

برای یادگیری بیشتر در موردتحقیق و روش تحقیق در این زمینه به مبحث تعریف درگاه‌های متریک‌های Core Web Vitals مراجعه کنید.

 جزئیات مربوط به FID

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

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

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

مشکلات پیش‌بینی‌نشده

FID فقط تأخیر در پردازش رویداد است. زمان خود پردازش رویداد و وقتی را که مرورگر می‌گیرد تا بعد از اجرای event handler ها UI را به‌روزرسانی کند، اندازه‌گیری نمی‌کند. وقتی این زمان بر تجربه کاربر اثر دارد باید آن را بخشی از FID محسوب کرد که توسعه‌دهندگان را به پاسخگویی غیر هم‌زمان به رویدادها ترغیب کند و این متریک را ارتقاء دهند. علت اینکه چرا تنها تأخیر ورودی بررسی می‌شود را در قسمت زیر با جزئیات ملاحظه نمایید. با ادامه مقاله FID چیست تفاوت‌های بین Metric و API با ما همراه باشید.

بررسی زمان‌بندی ذیل برای بارگذاری یک صفحه اینترنتی خاص:

تصویر بالا نشان می‌دهد یک صفحه دو درخواست وب برای منابعی (بیشتر فایلهای CSS و JS) را ایجاد می‌کند و پس‌ازاینکه دانلود این منابع به پایان می‌رسد آن‌ها را در thread اصلی پردازش می‌کند.

این نتایج در دوره‌هایی که thread اصلی به‌طور لحظه‌ای مشغول است با بلوک‌های وظیفه بارنگ بژ مشخص می‌شود.

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

شما ممکن است یاد داشته باشید که مقدار مناسبی از زمان (شامل سه وظیفه طولانی) بین FCP و TTI وجود دارد، اگر کاربر سعی کند طی آن زمان با صفحه تعامل داشته باشد (مانند: کلیک یک لینک)، یک تأخیر بین زمانی که کلیک می‌کند و زمانی که thread اصلی قادر به پاسخگویی است رخ خواهد داد.با ادامه مقاله FID چیست تفاوت‌های بین Metric و API با ما همراه باشید.

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

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

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

FID دلتای بین زمانی که یک رویداد ورودی دریافت می‌شود و زمانی که thread اصلی بی‌کاری بعدی است را اندازه‌گیری می‌کند. این بدان معناست که FID حتی مواردی را اندازه می‌گیرد که event listener ثبت‌نشده است. دلیل این امر این است که در بسیاری از تعاملات کاربران به event listener نیاز ندارند اما لازم استthread اصلی برای اجرا بی‌کار باشد.

به‌عنوان‌مثال، تمام المان‌های HTML زیر لازم است برای task های در حال اجرا در thread اصلی صبر کنند تا مورد قبلی برای پاسخ‌دهی به تعاملات کاربران تکمیل گردد:

• فیلدهای وظیفه، کادر انتخابی و کلیدهای رادیویی (<input>, <textarea>)
• کشویی‌های انتخاب (<select>)
• لینک‌ها <a>

چرا فقط اولین ورودی بررسی می‌شود؟

در حالیکه یک تأخیر از هر ورودی می‌تواند منجر به تجربه بدی برای کاربر گردد، ما اساساً اندازه‌گیری تأخیر اولین ورودی را به چند دلیل توصیه می‌کنیم:

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

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

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

تعامل‌های دیگر مانند اسکرول ها و زوم عملکردهای پیوسته هستند و محدودیت‌های عملیاتی کاملاً متفاوتی دارند (همچنین مرورگرها اغلب قادرند رکودهای خود را با اجرای آن‌ها در thread جداگانه پنهان کنند).

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

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

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

این بدان معنی است برخی کاربران هیچ مقداری FID نخواهند داشت، بعضی مقادیر کم FID خواهند داشت و تعدادی هم احتمالاً مقادیر بالای FID خواهند داشت.

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

چرا فقط تأخیر ورودی را بررسی می‌کنند؟

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

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

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

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

FID نیازمند کاربر واقعی است بنابراین نمی‌توان آن را در آزمایشگاه اندازه‌گیری کرد. اگرچه متریک Total Blocking Time(TBT) یا کل زمان بلوکه کردن قابل‌اندازه‌گیری در آزمایشگاه است ولی کاملاً با FID در یک فیلد وابستگی دارد و همچنین پیامدهایی دارد که بر تعامل تأثیرگذار است. بهینه‌سازی‌ها که TBT را در آزمایشگاه ارتقا می‌دهد باید FID را هم برای کاربران شما بهتر سازد. با ادامه مقاله FID چیست تفاوت‌های بین Metric و API با ما همراه باشید.

ابزارهای فیلد

• گزارش تجربی کاربران کروم
• دیدگاه‌ها در مورد سرعت صفحه
• کنسول‌های جستجو (گزارش Core Web Vitals)
• کتابخانه جاوا اسکریپت web-vitals

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

برای اندازه‌گیری FID در جاوا اسکریپت، شما می‌توانید از API زمان‌بندی رویداد استفاده کنید. مثال موجود نشان می‌دهد که چگونه PerformanceObserver ایجاد کنید که گوش‌به‌زنگ وارد شدن first-input باشد و آن‌ها را در کنسول ثبت کند:

هشدار: این کد چگونگی ثبت وارد شدن اولین ورودی به کنسول را نشان می‌دهد و تأخیر آن‌ها را محاسبه می‌کند. بااین‌وجود، اندازه‌گیری FID در جاوا اسکریپت بسیار پیچیده است. جزئیات را در بخش زیر ببینید:

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 از طریق گرفتن دلتای بین startTime و processingStart اندازه‌گیری می‌شود. در اکثر موارد این مقدار FID خواهد بود، بااین‌وجود همه اطلاعات وارده اولین ورودی برای اندازه‌گیری FID باارزش نیستند.

بخش بعدی فهرستی است از تفاوت‌های بین آنچه API گزارش می‌دهد و چگونگی محاسبه متریک. با ادامه مقاله FID چیست تفاوت‌های بین Metric و API با ما همراه باشید.

تفاوت‌های بین Metric و API

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

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

import {getFID} from 'web-vitals';

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

شما می‌توانید به کد منبع برای getFID) رجوع کنید که مثال کاملی است از چگونگی اندازه‌گیری FID در جاوا اسکریپت.

در برخی موارد (مانند آی فریم‌های متقاطع) امکان اندازه‌گیری FID در جاوا اسکریپت وجود ندارد. بخش محدودیت‌های آزمایشگاه web-vitals را با جزئیات مشاهده نمایید.

تحلیل و گزارش داده‌های FID

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

به دلیل اینکه درصد انتخابی برای آستانه تمام Core Web Vital ها 75 است، تأکید ما برای FID توجه به درصد 95 تا 99 است و این به اولین تجربه بد کاربر نسبت به سایت شما مربوط خواهد بود و این امر به شما نشان می‌دهد که کدام محدوده‌ها نیاز به اصلاح بیشتر دارد.

این حقیقت است حتی اگر گزارش شما بر اساس نوع یا طبقه دستگاهتان تقسیم‌بندی شده باشد. به‌عنوان‌مثال، اگر شما گزارش‌های مجزا برای کامپیوتر و موبایل ارائه دهید، مقدار FID که بیشترین اهمیت را روی کامپیوتر شما بدهد باید 95 تا 99 از کامپیوتر کاربران باشد و مقدار FID که بیشترین اهمیت را روی موبایل شما بدهد باید 95 تا 99 از موبایل کاربران باشد. با ادامه مقاله FID چیست تفاوت‌های بین Metric و API با ما همراه باشید.

چگونه FID را ارتقا دهیم؟

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

ازآنجاکه FID یک متریک فیلد است (و لایت هاوس یک ابزار متریک آزمایشگاهی)، راهنما برای ارتقا FID شبیه راهنما برای پیشرفت متریک آزمایشگاهی TBT است.

برای تفحص بیشتر در مورد چگونگی ارتقاء FID به Optimize FID مراجعه کنید. برای راهنمایی بیشتر در مورد تکنیک‌های عملکردی خاص که می‌تواند FID را هم ارتقا دهد به لینک زیر مراجعه نمایید:

گزارش تغییرات

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

امیدواریم از مقاله FID چیست تفاوت‌های بین Metric و API بهره کافی را برده باشید. از قسمت دیدگاه ها باما در ارتباط باشید.