همه ما می دانیم که چقدر مهم است که تاثیر اولیه خوبی داشته باشیم. هنگام ملاقات با افراد جدید مهم است، و همچنین هنگام ایجاد تجربیات در وب مهم است.
در وب، اولین برداشت خوب میتواند بین تبدیل شدن یک کاربر وفادار به کاربر یا رفتن او و عدم بازگشت او تفاوت ایجاد کند. سوال این است که چه چیزی باعث ایجاد یک تأثیر خوب می شود و چگونه می توانید نوع تأثیری که احتمالاً روی کاربران خود ایجاد می کنید را اندازه گیری کنید؟
در وب، اولین برداشتها میتوانند اشکال مختلفی داشته باشند—ما اولین برداشتها از طراحی و جذابیت بصری یک سایت و همچنین اولین برداشتها از سرعت و واکنشپذیری آن را داریم.
در حالی که اندازه گیری میزان علاقه کاربران به طراحی سایت با API های وب دشوار است، اما اندازه گیری سرعت و واکنش پذیری آن چنین نیست!
اولین برداشتی که کاربران از سرعت بارگذاری سایت شما با First Contentful Paint (FCP) اندازه گیری می کنند دارند. اما اینکه سایت شما چقدر سریع می تواند پیکسل ها را روی صفحه نمایش دهد، تنها بخشی از داستان است. به همان اندازه مهم این است که وقتی کاربران سعی می کنند با آن پیکسل ها تعامل داشته باشند، سایت شما چقدر واکنش گرا است!
متریک اولین تاخیر ورودی (FID) به اندازه گیری اولین برداشت کاربر از تعامل و پاسخگویی سایت شما کمک می کند.
FID چیست؟
FID از زمانی که کاربر برای اولین بار با یک صفحه تعامل می کند (یعنی زمانی که روی یک پیوند کلیک می کند، روی یک دکمه ضربه می زند یا از کنترل سفارشی مبتنی بر جاوا اسکریپت استفاده می کند) تا زمانی که مرورگر واقعاً قادر به پردازش است، اندازه گیری می کند. کنترل کننده رویداد در پاسخ به آن تعامل.
نمره FID خوب چیست؟
برای ارائه یک تجربه کاربری خوب، سایت ها باید تلاش کنند تا تاخیر ورودی اول 100 میلی ثانیه یا کمتر داشته باشند. برای اطمینان از رسیدن به این هدف برای اکثر کاربران خود، یک آستانه خوب برای اندازه گیری صدک 75 بارگذاری صفحه است که در دستگاه های تلفن همراه و دسکتاپ تقسیم بندی شده است.
FID به تفصیل
بهعنوان توسعهدهندگانی که کدی را مینویسند که به رویدادها پاسخ میدهد، اغلب تصور میکنیم که کد ما بلافاصله اجرا میشود - به محض اینکه رویداد اتفاق افتاد. اما بهعنوان کاربر، همه ما اغلب برعکس این موضوع را تجربه کردهایم - یک صفحه وب را در تلفن خود بارگذاری کردهایم، سعی کردهایم با آن تعامل داشته باشیم، و وقتی هیچ اتفاقی نیفتاده ناامید شدهایم.
به طور کلی، تاخیر ورودی (معروف به تاخیر ورودی) به این دلیل اتفاق میافتد که رشته اصلی مرورگر مشغول انجام کار دیگری است، بنابراین (هنوز) نمیتواند به کاربر پاسخ دهد. یکی از دلایل رایج ممکن است این اتفاق بیفتد این است که مرورگر مشغول تجزیه و اجرای یک فایل جاوا اسکریپت بزرگ است که توسط برنامه شما بارگذاری شده است. در حالی که این کار را انجام می دهد، نمی تواند هیچ شنونده رویدادی را اجرا کند زیرا جاوا اسکریپتی که بارگیری می کند ممکن است به آن دستور دهد که کار دیگری انجام دهد.
جدول زمانی زیر را برای بارگذاری یک صفحه وب معمولی در نظر بگیرید:
تجسم بالا صفحهای را نشان میدهد که چند درخواست شبکه برای منابع (به احتمال زیاد فایلهای CSS و JS) ارائه میکند و - پس از پایان دانلود آن منابع - در رشته اصلی پردازش میشوند.
این منجر به دورههایی میشود که در آن نخ اصلی بهطور لحظهای مشغول است، که با بلوکهای کاری بژ رنگ نشان داده میشود.
تأخیرهای طولانی ورودی اول معمولاً بین First Contentful Paint (FCP) و Time to Interactive (TTI) رخ می دهد زیرا صفحه برخی از محتوای خود را ارائه کرده است اما هنوز به طور قابل اعتماد تعاملی نیست. برای نشان دادن چگونگی این اتفاق، FCP و TTI به جدول زمانی اضافه شدهاند:
ممکن است متوجه شده باشید که زمان مناسبی (از جمله سه کار طولانی ) بین FCP و TTI وجود دارد، اگر کاربر سعی کند در این مدت با صفحه تعامل داشته باشد (مثلاً با کلیک کردن روی یک پیوند)، تاخیر ایجاد می شود. بین زمانی که کلیک دریافت می شود و زمانی که موضوع اصلی قادر به پاسخگویی است.
در نظر بگیرید که اگر کاربر سعی کند با صفحه نزدیک به ابتدای طولانی ترین کار تعامل داشته باشد، چه اتفاقی می افتد:
از آنجا که ورودی زمانی اتفاق میافتد که مرورگر در وسط اجرای یک کار است، باید منتظر بماند تا کار کامل شود تا بتواند به ورودی پاسخ دهد. زمانی که باید منتظر بماند مقدار 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 را با ابزارهای زیر اندازه گیری کنید.
ابزارهای میدانی
- گزارش تجربه کاربر Chrome
- PageSpeed Insights
- کنسول جستجو (گزارش Core Web Vitals)
- کتابخانه جاوا اسکریپت
web-vitals
اندازه گیری 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
با گرفتن دلتا بین مهرهای 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 ارائه کنید.
،همه ما می دانیم که چقدر مهم است که تاثیر اولیه خوبی داشته باشیم. هنگام ملاقات با افراد جدید مهم است، و همچنین هنگام ایجاد تجربیات در وب مهم است.
در وب، اولین برداشت خوب میتواند بین تبدیل شدن یک کاربر وفادار به کاربر یا رفتن او و عدم بازگشت او تفاوت ایجاد کند. سوال این است که چه چیزی باعث ایجاد یک تأثیر خوب می شود و چگونه می توانید نوع تأثیری که احتمالاً روی کاربران خود ایجاد می کنید را اندازه گیری کنید؟
در وب، اولین برداشتها میتوانند اشکال مختلفی داشته باشند—ما اولین برداشتها از طراحی و جذابیت بصری یک سایت و همچنین اولین برداشتها از سرعت و واکنشپذیری آن را داریم.
در حالی که اندازه گیری میزان علاقه کاربران به طراحی سایت با API های وب دشوار است، اما اندازه گیری سرعت و واکنش پذیری آن چنین نیست!
اولین برداشتی که کاربران از سرعت بارگذاری سایت شما با First Contentful Paint (FCP) اندازه گیری می کنند دارند. اما اینکه سایت شما چقدر سریع می تواند پیکسل ها را روی صفحه نمایش دهد، تنها بخشی از داستان است. به همان اندازه مهم این است که وقتی کاربران سعی می کنند با آن پیکسل ها تعامل داشته باشند، سایت شما چقدر واکنش گرا است!
متریک اولین تاخیر ورودی (FID) به اندازه گیری اولین برداشت کاربر از تعامل و پاسخگویی سایت شما کمک می کند.
FID چیست؟
FID از زمانی که کاربر برای اولین بار با یک صفحه تعامل می کند (یعنی زمانی که روی یک پیوند کلیک می کند، روی یک دکمه ضربه می زند یا از کنترل سفارشی مبتنی بر جاوا اسکریپت استفاده می کند) تا زمانی که مرورگر واقعاً قادر به پردازش است، اندازه گیری می کند. کنترل کننده رویداد در پاسخ به آن تعامل.
نمره FID خوب چیست؟
برای ارائه یک تجربه کاربری خوب، سایت ها باید تلاش کنند تا تاخیر ورودی اول 100 میلی ثانیه یا کمتر داشته باشند. برای اطمینان از رسیدن به این هدف برای اکثر کاربران خود، یک آستانه خوب برای اندازه گیری صدک 75 بارگذاری صفحه است که در دستگاه های تلفن همراه و دسکتاپ تقسیم بندی شده است.
FID به تفصیل
بهعنوان توسعهدهندگانی که کدی را مینویسند که به رویدادها پاسخ میدهد، اغلب تصور میکنیم که کد ما بلافاصله اجرا میشود - به محض اینکه رویداد اتفاق افتاد. اما بهعنوان کاربر، همه ما اغلب برعکس این موضوع را تجربه کردهایم - یک صفحه وب را در تلفن خود بارگذاری کردهایم، سعی کردهایم با آن تعامل داشته باشیم، و وقتی هیچ اتفاقی نیفتاده ناامید شدهایم.
به طور کلی، تاخیر ورودی (معروف به تاخیر ورودی) به این دلیل اتفاق میافتد که رشته اصلی مرورگر مشغول انجام کار دیگری است، بنابراین (هنوز) نمیتواند به کاربر پاسخ دهد. یکی از دلایل رایج ممکن است این اتفاق بیفتد این است که مرورگر مشغول تجزیه و اجرای یک فایل جاوا اسکریپت بزرگ است که توسط برنامه شما بارگذاری شده است. در حالی که این کار را انجام می دهد، نمی تواند هیچ شنونده رویدادی را اجرا کند زیرا جاوا اسکریپتی که بارگیری می کند ممکن است به آن دستور دهد که کار دیگری انجام دهد.
جدول زمانی زیر را برای بارگذاری یک صفحه وب معمولی در نظر بگیرید:
تجسم بالا صفحهای را نشان میدهد که چند درخواست شبکه برای منابع (به احتمال زیاد فایلهای CSS و JS) ارائه میکند و - پس از پایان دانلود آن منابع - در رشته اصلی پردازش میشوند.
این منجر به دورههایی میشود که در آن نخ اصلی بهطور لحظهای مشغول است، که با بلوکهای کاری بژ رنگ نشان داده میشود.
تأخیرهای طولانی ورودی اول معمولاً بین First Contentful Paint (FCP) و Time to Interactive (TTI) رخ می دهد زیرا صفحه برخی از محتوای خود را ارائه کرده است اما هنوز به طور قابل اعتماد تعاملی نیست. برای نشان دادن چگونگی این اتفاق، FCP و TTI به جدول زمانی اضافه شدهاند:
ممکن است متوجه شده باشید که زمان مناسبی (از جمله سه کار طولانی ) بین FCP و TTI وجود دارد، اگر کاربر سعی کند در این مدت با صفحه تعامل داشته باشد (مثلاً با کلیک کردن روی یک پیوند)، تاخیر ایجاد می شود. بین زمانی که کلیک دریافت می شود و زمانی که موضوع اصلی قادر به پاسخگویی است.
در نظر بگیرید که اگر کاربر سعی کند با صفحه نزدیک به ابتدای طولانی ترین کار تعامل داشته باشد، چه اتفاقی می افتد:
از آنجا که ورودی زمانی اتفاق میافتد که مرورگر در وسط اجرای یک کار است، باید منتظر بماند تا کار کامل شود تا بتواند به ورودی پاسخ دهد. زمانی که باید منتظر بماند مقدار 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 را با ابزارهای زیر اندازه گیری کنید.
ابزارهای میدانی
- گزارش تجربه کاربر Chrome
- PageSpeed Insights
- کنسول جستجو (گزارش Core Web Vitals)
- کتابخانه جاوا اسکریپت
web-vitals
اندازه گیری 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
با گرفتن دلتا بین مهرهای 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 ارائه کنید.
،همه ما می دانیم که چقدر مهم است که تاثیر اولیه خوبی داشته باشیم. هنگام ملاقات با افراد جدید مهم است، و همچنین هنگام ایجاد تجربیات در وب مهم است.
در وب، اولین برداشت خوب میتواند بین تبدیل شدن یک کاربر وفادار به کاربر یا رفتن او و عدم بازگشت او تفاوت ایجاد کند. سوال این است که چه چیزی باعث ایجاد یک تأثیر خوب می شود و چگونه می توانید نوع تأثیری که احتمالاً روی کاربران خود ایجاد می کنید را اندازه گیری کنید؟
در وب، اولین برداشتها میتوانند اشکال مختلفی داشته باشند—ما اولین برداشتها از طراحی و جذابیت بصری یک سایت و همچنین اولین برداشتها از سرعت و واکنشپذیری آن را داریم.
در حالی که اندازه گیری میزان علاقه کاربران به طراحی سایت با API های وب دشوار است، اما اندازه گیری سرعت و واکنش پذیری آن چنین نیست!
اولین برداشتی که کاربران از سرعت بارگذاری سایت شما با First Contentful Paint (FCP) اندازه گیری می کنند دارند. اما اینکه سایت شما چقدر سریع می تواند پیکسل ها را روی صفحه نمایش دهد، تنها بخشی از داستان است. به همان اندازه مهم این است که وقتی کاربران سعی می کنند با آن پیکسل ها تعامل داشته باشند، سایت شما چقدر واکنش گرا است!
متریک اولین تاخیر ورودی (FID) به اندازه گیری اولین برداشت کاربر از تعامل و پاسخگویی سایت شما کمک می کند.
FID چیست؟
FID از زمانی که کاربر برای اولین بار با یک صفحه تعامل می کند (یعنی زمانی که روی یک پیوند کلیک می کند، روی یک دکمه ضربه می زند یا از کنترل سفارشی مبتنی بر جاوا اسکریپت استفاده می کند) تا زمانی که مرورگر واقعاً قادر به پردازش است، اندازه گیری می کند. کنترل کننده رویداد در پاسخ به آن تعامل.
نمره FID خوب چیست؟
برای ارائه یک تجربه کاربری خوب، سایت ها باید تلاش کنند تا تاخیر ورودی اول 100 میلی ثانیه یا کمتر داشته باشند. برای اطمینان از رسیدن به این هدف برای اکثر کاربران خود، یک آستانه خوب برای اندازه گیری صدک 75 بارگذاری صفحه است که در دستگاه های تلفن همراه و دسکتاپ تقسیم بندی شده است.
FID به تفصیل
بهعنوان توسعهدهندگانی که کدی را مینویسند که به رویدادها پاسخ میدهد، اغلب تصور میکنیم که کد ما بلافاصله اجرا میشود - به محض اینکه رویداد اتفاق افتاد. اما بهعنوان کاربر، همه ما اغلب برعکس این موضوع را تجربه کردهایم - یک صفحه وب را در تلفن خود بارگذاری کردهایم، سعی کردهایم با آن تعامل داشته باشیم، و وقتی هیچ اتفاقی نیفتاده ناامید شدهایم.
به طور کلی، تاخیر ورودی (معروف به تاخیر ورودی) به این دلیل اتفاق میافتد که رشته اصلی مرورگر مشغول انجام کار دیگری است، بنابراین (هنوز) نمیتواند به کاربر پاسخ دهد. یکی از دلایل رایج ممکن است این اتفاق بیفتد این است که مرورگر مشغول تجزیه و اجرای یک فایل جاوا اسکریپت بزرگ است که توسط برنامه شما بارگذاری شده است. در حالی که این کار را انجام می دهد، نمی تواند هیچ شنونده رویدادی را اجرا کند زیرا جاوا اسکریپتی که بارگیری می کند ممکن است به آن دستور دهد که کار دیگری انجام دهد.
جدول زمانی زیر را برای بارگذاری یک صفحه وب معمولی در نظر بگیرید:
تجسم بالا صفحهای را نشان میدهد که چند درخواست شبکه برای منابع (به احتمال زیاد فایلهای CSS و JS) ارائه میکند و - پس از پایان دانلود آن منابع - در رشته اصلی پردازش میشوند.
این منجر به دورههایی میشود که در آن نخ اصلی بهطور لحظهای مشغول است، که با بلوکهای کاری بژ رنگ نشان داده میشود.
تأخیرهای طولانی ورودی اول معمولاً بین First Contentful Paint (FCP) و Time to Interactive (TTI) رخ می دهد زیرا صفحه برخی از محتوای خود را ارائه کرده است اما هنوز به طور قابل اعتماد تعاملی نیست. برای نشان دادن چگونگی این اتفاق، FCP و TTI به جدول زمانی اضافه شدهاند:
ممکن است متوجه شده باشید که زمان مناسبی (از جمله سه کار طولانی ) بین FCP و TTI وجود دارد، اگر کاربر سعی کند در این مدت با صفحه تعامل داشته باشد (مثلاً با کلیک کردن روی یک پیوند)، تاخیر ایجاد می شود. بین زمانی که کلیک دریافت می شود و زمانی که موضوع اصلی قادر به پاسخگویی است.
در نظر بگیرید که اگر کاربر سعی کند با صفحه نزدیک به ابتدای طولانی ترین کار تعامل داشته باشد، چه اتفاقی می افتد:
از آنجا که ورودی زمانی اتفاق میافتد که مرورگر در وسط اجرای یک کار است، باید منتظر بماند تا کار کامل شود تا بتواند به ورودی پاسخ دهد. زمانی که باید منتظر بماند مقدار FID برای این کاربر در این صفحه است.
اگر یک تعامل شنونده رویداد نداشته باشد چه؟
FID دلتا را بین زمان دریافت یک رویداد ورودی و زمانی که موضوع اصلی بعدی بیکار است ، اندازه گیری می کند. این بدان معنی است که FID حتی در مواردی که شنونده رویداد ثبت نشده است اندازه گیری می شود. دلیل این امر به این دلیل است که بسیاری از فعل و انفعالات کاربر نیازی به شنونده رویداد ندارند اما برای اجرای آن نیاز به ابتکار عمل دارند .
به عنوان مثال ، تمام عناصر HTML زیر باید قبل از پاسخ به تعامل کاربر ، منتظر کارهای در حال پیشرفت در موضوع اصلی باشند:
- فیلدهای متن ، کادرهای چک و دکمه های رادیویی (
<input>
،<textarea>
) - Dropdowns را انتخاب کنید (
<select>
) - پیوندها (
<a>
)
چرا فقط اولین ورودی را در نظر بگیرید؟
در حالی که تأخیر از هر ورودی می تواند به یک تجربه کاربر بد منجر شود ، ما در درجه اول توصیه می کنیم اولین تأخیر ورودی را به چند دلیل اندازه گیری کنیم:
- اولین تأخیر ورودی اولین برداشت کاربر از پاسخگویی سایت شما خواهد بود و برداشت های اول در شکل گیری برداشت کلی ما از کیفیت و قابلیت اطمینان یک سایت بسیار مهم است.
- بزرگترین مشکلات تعامل که امروز در وب مشاهده می کنیم در هنگام بار صفحه رخ می دهد. بنابراین ، ما معتقدیم که در ابتدا تمرکز بر بهبود اولین تعامل کاربر سایت بیشترین تأثیر را در بهبود تعامل کلی وب خواهد داشت.
- راه حل های پیشنهادی برای چگونگی رفع تأخیرهای ورودی اول (تقسیم کد ، بارگیری کمتر جاوا اسکریپت و غیره) لزوماً همان راه حل ها برای رفع تأخیر در ورودی آهسته پس از بار صفحه نیستند. با جدا کردن این معیارها می توانیم دستورالعمل های عملکردی خاص تری را برای توسعه دهندگان وب ارائه دهیم.
چه چیزی به عنوان اولین ورودی حساب می شود؟
FID یک متریک است که پاسخگویی صفحه را در حین بار اندازه گیری می کند. به این ترتیب، فقط روی رویدادهای ورودی از اقدامات مجزا مانند کلیک، ضربه زدن و فشار دادن کلید تمرکز می کند.
تعامل دیگر ، مانند پیمایش و بزرگنمایی ، اقدامات مداوم است و دارای محدودیت عملکرد کاملاً متفاوتی است (همچنین ، مرورگرها اغلب با اجرای آنها روی یک موضوع جداگانه قادر به پنهان کردن تأخیر خود هستند).
برای این روش دیگر ، FID روی R (پاسخگویی) در مدل عملکرد ریلی تمرکز دارد ، در حالی که پیمایش و بزرگنمایی بیشتر مربوط به یک (انیمیشن) است و ویژگی های عملکرد آنها باید به طور جداگانه ارزیابی شود.
اگر کاربر هرگز با سایت شما ارتباط برقرار نکند ، چه می شود؟
همه کاربران هر بار که بازدید می کنند با سایت شما تعامل نخواهند داشت. و همه تعامل مربوط به FID نیست (همانطور که در بخش قبلی ذکر شد). علاوه بر این ، اولین تعامل کاربر در مواقع بد خواهد بود (وقتی موضوع اصلی برای مدت طولانی مشغول است) و اولین تعامل کاربر در زمان های خوبی خواهد بود (وقتی موضوع اصلی کاملاً بیکار است).
این بدان معناست که برخی از کاربران مقادیر FID ندارند ، برخی از کاربران مقادیر کم FID دارند و برخی از کاربران احتمالاً مقادیر بالایی FID دارند.
نحوه ردیابی ، گزارش و تجزیه و تحلیل FID احتمالاً کمی متفاوت از سایر معیارهایی است که ممکن است از آنها استفاده کنید. بخش بعدی توضیح می دهد که چگونه بهترین کار را انجام می دهیم.
چرا فقط تأخیر ورودی را در نظر می گیرید؟
همانطور که در بالا ذکر شد ، FID فقط "تأخیر" را در پردازش رویداد اندازه گیری می کند. این طول مدت زمان پردازش رویداد را اندازه گیری نمی کند ، و نه زمانی که مرورگر را برای به روزرسانی UI پس از اجرای کنترل کننده های رویداد می طلبد.
حتی اگر این بار برای کاربر مهم باشد و بر تجربه تأثیر بگذارد ، در این متریک گنجانده نشده است زیرا انجام این کار می تواند توسعه دهندگان را برای اضافه کردن راه حل هایی که در واقع این تجربه را بدتر می کنند ، تحریک کند - یعنی آنها می توانند منطق کنترل کننده رویداد خود را در یک ناهمزمان ببندند پاسخ به تماس (از طریق setTimeout()
یا requestAnimationFrame()
) به منظور جدا کردن آن از کار مرتبط با این رویداد. نتیجه می تواند بهبودی در نمره متریک باشد اما یک پاسخ کندتر همانطور که توسط کاربر درک می شود.
با این حال ، در حالی که FID فقط بخش "تأخیر" از تأخیر رویداد را اندازه گیری می کند ، توسعه دهندگان که می خواهند تعداد بیشتری از چرخه حیات رویداد را ردیابی کنند ، می توانند با استفاده از API زمان بندی رویداد این کار را انجام دهند. برای اطلاعات بیشتر به راهنمای معیارهای سفارشی مراجعه کنید.
نحوه اندازه گیری FID
FID یک متریک است که فقط در این زمینه قابل اندازه گیری است ، زیرا به یک کاربر واقعی نیاز دارد تا با صفحه شما ارتباط برقرار کند. می توانید FID را با ابزارهای زیر اندازه گیری کنید.
ابزارهای میدانی
- گزارش تجربه کاربر Chrome
- PageSpeed Insights
- کنسول جستجو (گزارش اصلی وب ویتالز)
- کتابخانه جاوا اسکریپت
web-vitals
اندازه گیری FID در JavaScript
برای اندازه گیری FID در JavaScript ، می توانید از 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
Simestamps اندازه گیری می شود. در بیشتر موارد ، این مقدار FID خواهد بود. با این حال ، همه ورودی های first-input
برای اندازه گیری FID معتبر نیستند.
در بخش زیر تفاوت های بین آنچه API گزارش می شود و نحوه محاسبه متریک ذکر شده است.
تفاوت بین متریک و API
- API ورودی های
first-input
را برای صفحات بارگذاری شده در یک برگه پس زمینه ارسال می کند اما هنگام محاسبه FID باید آن صفحات نادیده گرفته شود. - اگر صفحه قبل از اولین ورودی رخ داده باشد ، API همچنین ورودی های
first-input
را اعزام می کند ، اما این صفحات نیز هنگام محاسبه FID باید نادیده گرفته شوند (ورودی ها فقط در صورتی در نظر گرفته می شوند که صفحه در پیش زمینه باشد). - API هنگام بازگرداندن صفحه از حافظه نهان عقب/رو به جلو ، ورودی های
first-input
را گزارش نمی کند ، اما FID باید در این موارد اندازه گیری شود زیرا کاربران آنها را به عنوان بازدیدهای صفحه مجزا تجربه می کنند. - API ورودی هایی را که در Iframes رخ می دهد گزارش نمی دهد اما متریک به عنوان بخشی از تجربه کاربر صفحه است. این می تواند به عنوان تفاوت بین Crux و Rum نشان داده شود . برای اندازه گیری صحیح FID باید آنها را در نظر بگیرید. فریم های فرعی می توانند از API برای گزارش ورودی های
first-input
خود به قاب والدین برای جمع آوری استفاده کنند.
تجزیه و تحلیل و گزارش در مورد داده های FID
با توجه به واریانس مورد انتظار در مقادیر FID ، بسیار مهم است که هنگام گزارش در FID ، به توزیع مقادیر نگاه می کنید و روی صدک های بالاتر تمرکز می کنید.
در حالی که انتخاب صدک برای کلیه آستانه های اصلی وب ویتامین 75 است ، به ویژه برای FID ما هنوز هم به شدت توصیه می کنیم به صدک های 95 تا 99 بپردازیم ، زیرا این موارد با اولین تجربیاتی که کاربران با سایت شما دارند مطابقت دارد. و این مناطقی را به شما نشان می دهد که بیشترین پیشرفت را دارند.
این درست است حتی اگر گزارش های خود را بر اساس دسته دستگاه یا نوع دستگاه تقسیم کنید. به عنوان مثال ، اگر گزارش های جداگانه ای را برای دسک تاپ و موبایل اجرا می کنید ، مقدار FID که بیشتر به آن اهمیت می دهید در دسک تاپ باید صدک 95 تا 99 کاربران دسک تاپ باشد ، و ارزش FID شما بیشتر از همه در تلفن همراه اهمیت می دهید باید صدک 95 تا 99 باشد. از کاربران تلفن همراه
چگونه می توان FID را بهبود بخشید
یک راهنمای کامل در مورد بهینه سازی FID در دسترس است تا شما را از طریق تکنیک هایی برای بهبود این متریک راهنمایی کند.
تغییرات
گاهی اوقات ، اشکالات در API های مورد استفاده برای اندازه گیری معیارها و گاهی اوقات در تعاریف خود معیارها کشف می شود. در نتیجه ، گاهی اوقات باید تغییراتی ایجاد شود و این تغییرات به عنوان پیشرفت یا رگرسیون در گزارش های داخلی و داشبورد شما نشان داده می شود.
برای کمک به شما در مدیریت این کار ، تمام تغییرات در اجرای یا تعریف این معیارها در این تغییر شکل ظاهر می شود.
اگر برای این معیارها بازخورد دارید ، می توانید آن را در گروه Google Web-Vitals-Feedback ارائه دهید.