اولین تاخیر ورودی (FID) زمانی است که کاربر برای اولین بار با صفحه شما تعامل می کند تا زمانی که صفحه پاسخ می دهد. پاسخگویی را اندازه گیری می کند و یکی از سه معیار اصلی Web Vitals است که گوگل برای اندازه گیری تجربه صفحه از آن استفاده می کند.
تعاملات نمونه عبارتند از:
- با کلیک بر روی یک لینک یا دکمه.
- وارد کردن متن در یک فیلد خالی
- انتخاب یک منوی کشویی
- کلیک کردن بر روی یک چک باکس.
برخی از رویدادها مانند پیمایش یا بزرگ‌نمایی شمارش نمی‌شوند.
بیایید بررسی کنیم که FID شما چقدر باید سریع باشد و چگونه آن را بهبود ببخشید.
مقدار FID خوب کمتر از 100 میلی‌ثانیه است و باید براساس داده‌های گزارش تجربه کاربر Chrome (CrUX) باشد. این داده‌های کاربران واقعی Chrome است که در سایت شما هستند و اشتراک‌گذاری این اطلاعات را انتخاب کرده‌اند. برای پاسخگویی در کمتر از 100 میلی ثانیه به 75 درصد از تعاملات نیاز دارید.
صفحه شما ممکن است در یکی از سطل های زیر طبقه بندی شود:
- خوب: <=100 میلی‌ثانیه
- نیاز به بهبود: > 100 میلی ثانیه و <=300 میلی ثانیه
- ضعیف: > 300 میلی‌ثانیه
داده های FID
95.3٪ از سایت ها در آوریل 2023 در سطل FID خوب قرار دارند. این میانگین در سراسر سایت است. همانطور که اشاره کردیم، برای اینکه در اینجا خوب نشان داده شود، به 75٪ از تعاملات نیاز دارید تا در کمتر از 100 میلی ثانیه پاسخ دهید.
اکثر صفحات در اکثر سایت ها بررسی CWV را برای FID پاس می کنند. من فکر نمی‌کنم این واقعاً بهترین روش برای اندازه‌گیری پاسخگویی باشد، و Google در مارس 2024 FID را با Interaction to Next Paint (INP) جایگزین خواهد کرد. تعاملاتی که کاربر ایجاد می کند
وقتی مطالعه‌ای را روی Core Web Vitals انجام دادیم، متوجه شدیم که تقریباً هیچ‌کس نیازی به نگرانی در مورد FID در اتصالات دسک‌تاپ ندارد و تعداد کمی از افراد باید در مورد آن در تلفن همراه نگران باشند.
تعداد کمی از سایت ها نیاز به نگرانی در مورد FID دارند، حتی در اتصالات کندتر، زیرا بیشتر صفحات آنها در حال عبور است.
داده های سطح صفحه ما از مطالعه همین داستان را بیان می کند. به نظر نمی رسد FID برای اکثر صفحات نگران کننده باشد.
تنها شماره FID که مهم است از گزارش تجربه کاربر Chrome (CrUX) می آید، که داده های کاربران واقعی Chrome است که انتخاب می کنند داده های خود را به اشتراک بگذارند.
این داده‌های میدانی نامیده می‌شود و بهترین ایده را از عملکرد FID در دنیای واقعی در شرایط مختلف شبکه، دستگاه‌ها، حافظه پنهان، و غیره به شما می‌دهد. همچنین این همان چیزی است که در واقع توسط Google برای Core Web Vitals اندازه‌گیری خواهید شد.
برای آزمایش‌های ثابت و قابل تکرار، داده‌های آزمایشگاهی نیز وجود دارد که با شرایط یکسان آزمایش می‌کنند. FID در تست های آزمایشگاهی در دسترس نیست زیرا ابزارهای آزمایش روی چیزی کلیک نمی کنند. با این حال، می‌توانید از زمان مسدودسازی کل (TBT) به عنوان یک معیار جایگزین استفاده کنید. با بهبود فرآیندهایی که مسدود شده اند، FID خود را نیز بهبود می بخشید.
اندازه گیری FID برای یک URL واحد
Pagespeed Insights داده‌های فیلد سطح صفحه را می‌کشد که در غیر این صورت نمی‌توانید در مجموعه داده CrUX پرس و جو کنید. همچنین داده‌های مبدأ را به شما می‌دهد تا بتوانید عملکرد صفحه را با کل سایت مقایسه کنید و آزمایش‌های آزمایشگاهی را بر اساس Google Lighthouse اجرا کنید تا به شما TBT بدهد.
اندازه گیری FID برای بسیاری از URL ها یا کل سایت
می‌توانید داده‌های CrUX را در کنسول جستجوی Google دریافت کنید که در دسته‌های خوب، نیاز به بهبود و ضعیف قرار دارند.
با کلیک بر روی یکی از مسائل، گروه‌های صفحه‌ای که تحت تأثیر قرار گرفته‌اند را به تفکیک تقسیم می‌کنید. گروه ها صفحاتی با مقادیر مشابه هستند که احتمالاً از یک الگو استفاده می کنند. شما تغییرات را یک بار در قالب ایجاد می کنید و این تغییرات در صفحات گروه برطرف می شود.
اگر هم داده‌های آزمایشگاهی و هم داده‌های میدانی را در مقیاس می‌خواهید، تنها راه برای به دست آوردن آن از طریق API PageSpeed Insights است. می‌توانید با حسابرسی سایت Ahrefs به راحتی به آن متصل شوید و گزارش‌هایی از جزئیات عملکرد خود دریافت کنید. این برای سایت های تایید شده با حساب Ahrefs Webmaster Tools (AWT) رایگان است.
توجه داشته باشید که داده‌های Core Web Vitals نشان داده شده توسط کاربر-عاملی که برای خزیدن خود در طول راه‌اندازی انتخاب کرده‌اید تعیین می‌شود. اگر از تلفن همراه خزیده باشید، مقادیر CWV تلفن همراه را از API دریافت خواهید کرد.
رقابت جاوا اسکریپت برای موضوع اصلی. فقط یک رشته اصلی وجود دارد و جاوا اسکریپت برای اجرای وظایف بر روی آن رقابت می کند.
جاوا اسکریپت باید به نوبت روی رشته اصلی اجرا شود. این مانند اجاق گاز یک شعله است که در آن باید یک غذا را در یک زمان بپزید، اما چندین غذا برای پختن دارید.
در حالی که یک کار در حال اجرا است، صفحه نمی تواند به ورودی کاربر پاسخ دهد. این تاخیری است که احساس می شود. هر چه کار طولانی تر باشد، تاخیر بیشتری توسط کاربر تجربه می شود.
وقفه های بین کارها فرصت هایی هستند که صفحه برای تغییر به وظیفه ورودی کاربر و پاسخ به آنچه می خواستند انجام دهد. این در دستگاه‌های کندتر بدتر است، زیرا پردازش جاوا اسکریپت بیشتر طول می‌کشد و باعث تأخیر بیشتری می‌شود.
در PageSpeed Insights، یک برگه TBT را خواهید دید که دارای مشکلات مربوط به مسدود شدن رشته اصلی است. اینها مسائلی هستند که می خواهید برای بهبود FID حل کنید.
اکثر صفحات چک FID را پاس می کنند. با این حال، اگر باید روی FID کار کنید، فقط چند مورد وجود دارد که می توانید روی آنها کار کنید:
1. مقدار جاوا اسکریپت را کاهش دهید
اگر می توانید میزان اجرای جاوا اسکریپت را کاهش دهید، ابتدا این کار را انجام دهید. در اوایل بارگذاری صفحه روی جاوا اسکریپت تمرکز کنید. اگر بهینه‌سازی زیادی انجام نشده باشد، بخش اولیه فرآیند بارگذاری را می‌توان با تعداد زیادی جاوا اسکریپت پر کرد که همه تلاش می‌کنند روی آن رشته اصلی اجرا شوند.
2. در صورت امکان جاوا اسکریپت را بعداً بارگیری کنید
هر جاوا اسکریپتی که فوراً به آن نیاز ندارید باید بعداً بارگیری شود. دو راه اصلی برای انجام این کار وجود دارد – ویژگی‌های defer و async. این ویژگی ها را می توان به تگ های اسکریپت شما اضافه کرد.
معمولاً اسکریپتی که دانلود می شود، تجزیه کننده را هنگام دانلود و اجرا مسدود می کند. Async اجازه می دهد تجزیه و دانلود به طور همزمان انجام شود اما همچنان تجزیه را در طول اجرای اسکریپت مسدود می کند. Defer تجزیه را در حین دانلود مسدود نمی کند و فقط پس از اتمام تجزیه HTML اجرا می شود.
کدام را باید استفاده کنید؟ برای هر چیزی که قبلاً می خواهید یا وابستگی دارد، من به سمت همگام سازی متمایل می شوم.
به عنوان مثال، من تمایل دارم از async در برچسب های تجزیه و تحلیل استفاده کنم تا کاربران بیشتری ثبت شوند. شما می خواهید هر چیزی را که لازم نیست به بعد موکول کنید یا وابستگی ندارد. افزودن ویژگی ها بسیار آسان است.
این نمونه ها را بررسی کنید:
طبیعی:
<script src="></script>
همگام سازی:
<script src=" async></script>
به تعویق انداختن:
<script src=" defer></script>
3. کارهای طولانی را از بین ببرید
گزینه دیگر این است که جاوا اسکریپت را جدا کنید تا زمان کمتری اجرا شود. شما آن کارهای طولانی را که پاسخ به ورودی کاربر را به تأخیر می اندازند، برمی دارید و آنها را به کارهای کوچکتر تقسیم می کنید که برای مدت زمان کمتری مسدود می شوند. این کار با تقسیم کد انجام می شود که وظایف را به تکه های کوچکتر تقسیم می کند.
4. از وب کارگران استفاده کنید
همچنین گزینه انتقال بخشی از جاوا اسکریپت به یک سرویس دهنده وجود دارد. من اشاره کردم که جاوا اسکریپت برای یک رشته اصلی مرورگر رقابت می کند، اما این یک راه حل است که به آن مکان دیگری برای اجرا می دهد.
تا جایی که ذخیره سازی در حافظه پنهان پیش می رود، برخی معاوضه ها وجود دارد. و سرویس‌کار نمی‌تواند به DOM دسترسی پیدا کند، بنابراین نمی‌تواند به‌روزرسانی یا تغییری انجام دهد. اگر می خواهید جاوا اسکریپت را به یک سرویس دهنده منتقل کنید، واقعاً باید توسعه دهنده ای داشته باشید که بداند آنها چه کار می کنند.
5. از پیش رندر یا رندر سمت سرور (SSR) استفاده کنید
اگر از یک چارچوب جاوا اسکریپت استفاده می کنید، جاوا اسکریپت زیادی برای بارگیری صفحه مورد نیاز است. پردازش جاوا اسکریپت در مرورگر ممکن است کمی طول بکشد و این می تواند باعث تاخیر شود. اگر از پیش اجرا یا SSR استفاده می کنید، این بار را از مرورگر به سرور منتقل می کنید.
افکار نهایی
اگرچه FID در مارس 2024 با INP جایگزین می شود، هنوز هم ارزش کار روی بهبود FID را دارد. همان چیزهایی که برای بهبود TBT و FID روی آنها کار می کنید باید INP را نیز بهبود بخشند.
اگر سوالی دارید به من پیام دهید در توییتر.