تاخیر ورودی اول (FID)

Philip Walton

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

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

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

اگرچه اندازه‌گیری میزان رضایت کاربران از طراحی سایت با استفاده از APIهای وب دشوار است، اما اندازه‌گیری سرعت و واکنش‌گرایی آن کار دشواری است!

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

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

FID چیست؟

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

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

برای ارائه یک تجربه کاربری خوب، سایت‌ها باید تلاش کنند تا اولین تأخیر ورودی ۱۰۰ میلی‌ثانیه یا کمتر داشته باشند. برای اطمینان از اینکه این هدف را برای اکثر کاربران خود محقق می‌کنید، یک آستانه خوب برای اندازه‌گیری، صدک ۷۵ام بارگذاری صفحات است که در دستگاه‌های تلفن همراه و دسکتاپ تقسیم‌بندی شده است.

جزئیات FID

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

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

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

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

این منجر به دوره‌هایی می‌شود که رشته اصلی موقتاً مشغول است، که با بلوک‌های وظیفه به رنگ بژ نشان داده شده است.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

چرا فقط تأخیر ورودی را در نظر می‌گیریم؟

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

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

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

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

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

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

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

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

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

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

تفاوت‌های بین معیار و API

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

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

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

در حالی که انتخاب صدک برای همه آستانه‌های Core Web Vitals عدد ۷۵ است، به طور خاص برای FID، ما اکیداً توصیه می‌کنیم که صدک‌های ۹۵ تا ۹۹ را در نظر بگیرید، زیرا این اعداد مربوط به اولین تجربیات بدی هستند که کاربران با سایت شما دارند. و این به شما نشان می‌دهد که چه حوزه‌هایی نیاز به بیشترین بهبود دارند.

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

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

یک راهنمای کامل در مورد بهینه‌سازی FID موجود است تا شما را در تکنیک‌های بهبود این معیار راهنمایی کند.

تغییرات

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

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

اگر در مورد این معیارها بازخوردی دارید، می‌توانید آن را در گروه گوگل web-vitals-feedback ارائه دهید.