این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

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

Philip Walton

پشتیبانی مرورگر

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

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

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

در حالی که اندازه گیری میزان علاقه کاربران به طراحی سایت با API های وب دشوار است، اما اندازه گیری سرعت و واکنش پذیری آن چنین نیست!

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

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

FID چیست؟

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

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

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

مقادیر خوب FID 2.5 ثانیه یا کمتر هستند، مقادیر ضعیف بیشتر از 4.0 ثانیه هستند و هر چیزی در این بین نیاز به بهبود دارد.

FID به تفصیل

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

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

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

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

نمونه ردیابی بارگذاری صفحه

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

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

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

نمونه ردیابی بارگذاری صفحه با FCP و TTI

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

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

نمونه ردیابی بارگذاری صفحه با FCP، TTI، و FID

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

چرا فقط تاخیر ورودی را در نظر بگیرید؟

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

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

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

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

FID معیاری است که فقط در میدان قابل اندازه گیری است، زیرا نیاز به یک کاربر واقعی برای تعامل با صفحه شما دارد. شما می توانید 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 در جاوا اسکریپت پیچیده تر است. برای جزئیات به زیر مراجعه کنید:

در مثال بالا، مقدار تاخیر ورودی first-input با گرفتن دلتا بین مهرهای startTime و processingStart ورودی اندازه‌گیری می‌شود. در بیشتر موارد این مقدار FID خواهد بود. با این حال، همه ورودی های first-input برای اندازه گیری FID معتبر نیستند.

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

تفاوت بین متریک و API

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

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

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

در حالی که انتخاب صدک برای تمام آستانه های Core Web Vitals 75 است، به ویژه برای FID، ما همچنان اکیداً توصیه می کنیم که صدک های 95-99 را بررسی کنید، زیرا این صدک ها با اولین تجربیات بدی که کاربران با سایت شما دارند مطابقت دارد. و زمینه هایی را به شما نشان می دهد که نیاز به بهبود بیشتری دارند.

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

نحوه بهبود FID

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

تغییرات

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

برای کمک به شما در مدیریت این موضوع، همه تغییرات در اجرا یا تعریف این معیارها در این Changelog ظاهر می‌شود.

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