Interaction to Next Paint (INP) معیاری با ثبات Core Web Vital است که پاسخگویی صفحه را با استفاده از دادههای Event Timing API ارزیابی میکند. INP تأخیر تمام تعاملات کلیک، ضربه و صفحه کلید را با یک صفحه در طول عمر آن مشاهده میکند و طولانیترین مدت را گزارش میکند، بدون توجه به موارد پرت. INP پایین به این معنی است که صفحه به طور مداوم قادر است به اکثریت قریب به اتفاق تعاملات کاربر به سرعت پاسخ دهد.
پاسخگویی خوب به این معنی است که یک صفحه به سرعت به تعاملات پاسخ می دهد. هنگامی که یک صفحه به یک تعامل پاسخ می دهد، مرورگر بازخورد بصری را در فریم بعدی ارائه می دهد تا نشان دهد که تعامل موفق بوده است. به عنوان مثال، می تواند در مورد موارد زیر بازخورد ارائه دهد:
- اینکه آیا کالایی که به سبد خرید آنلاین اضافه میکنید واقعاً اضافه میشود یا خیر.
- آیا منوی پیمایش تلفن همراه باز شده است یا خیر.
- اینکه آیا محتویات یک لاگین توسط سرور احراز هویت می شود یا خیر.
برخی از تعاملات به طور طبیعی بیشتر از سایرین طول می کشد، اما برای تعاملات پیچیده، بسیار مهم است که به سرعت برخی بازخوردهای بصری اولیه را ارائه دهید تا به کاربر بگویید چیزی در حال رخ دادن است. زمان تا رنگ بعدی اولین فرصت برای انجام این کار است. بنابراین، هدف INP اندازهگیری تمام اثرات نهایی تعامل (مانند واکشی شبکه و بهروزرسانیهای رابط کاربری از سایر عملیات ناهمزمان) نیست، بلکه زمانی است که در آن رنگ بعدی مسدود میشود. با به تأخیر انداختن بازخورد بصری، باعث میشوید کاربران فکر کنند صفحه به اقدامات آنها پاسخ نمیدهد.
هدف INP به حداقل رساندن زمان از زمانی که کاربر یک تعامل را آغاز می کند تا فریم بعدی رنگ آمیزی می شود، برای همه یا بیشتر تعاملاتی که کاربر شروع می کند.
INP با مشاهده تمام فعل و انفعالات انجام شده با یک صفحه محاسبه می شود. برای اکثر سایت ها، تعامل با بدترین تاخیر به عنوان INP گزارش می شود. با این حال، برای صفحاتی که تعداد تعاملات زیادی دارند، سکسکههای تصادفی میتواند منجر به یک تعامل غیرمعمول با تأخیر بالا در سایتهایی شود که در غیر این صورت پاسخگو هستند. هر چه تعاملات بیشتر باشد، احتمال وقوع آن بیشتر است. برای مقابله با این، و اندازه گیری بهتری از پاسخگویی واقعی برای آن نوع صفحات، یک بالاترین تعامل را برای هر 50 تعامل نادیده می گیریم. از آنجایی که اکثریت قریب به اتفاق تجربههای صفحه بیش از 50 تعامل ندارند، مرورگر تقریباً همیشه همچنان بدترین تعامل را گزارش میکند. سپس صدک 75 از تمام بازدیدهای صفحه طبق معمول گزارش میشود، که بیشتر موارد پرت را حذف میکند تا ارزشی بیشتر از تجربه کاربری عمومی ارائه دهد.
تعامل گروهی از کنترلکنندههای رویداد است که در طول یک حرکت منطقی کاربر فعال میشوند. برای مثال، فعل و انفعالات «ضربه» روی یک دستگاه صفحه لمسی شامل چندین رویداد مانند pointerup
، pointerdown
و click
است. یک تعامل می تواند توسط جاوا اسکریپت، CSS، کنترل های داخلی مرورگر مانند عناصر فرم، یا ترکیبی از این موارد انجام شود.
تأخیر تعامل شامل طولانیترین مدت زمان گروهی از کنترلکنندههای رویداد است که تعامل را هدایت میکند، از زمانی که کاربر تعامل را آغاز میکند تا زمانی که فریم بعدی با بازخورد بصری ارائه میشود.
نکته کلیدی: برای جزئیات بیشتر در مورد نحوه اندازه گیری INP، به "در یک تعامل چیست؟" .
نمره INP خوب چیست؟
برای اطمینان از ارائه تجربیات کاربر با پاسخگویی خوب، یک آستانه خوب برای اندازه گیری صدک 75 بارگیری صفحه ثبت شده در این زمینه است که در دستگاه های تلفن همراه و دسکتاپ تقسیم بندی شده است:
- INP برابر یا کمتر از 200 میلی ثانیه به این معنی است که صفحه شما پاسخگویی خوبی دارد.
- INP بین 200 میلی ثانیه تا 500 میلی ثانیه به این معنی است که پاسخگویی صفحه شما نیاز به بهبود دارد .
- INP بیشتر از 500 میلی ثانیه به این معنی است که صفحه شما پاسخگویی ضعیفی دارد.
چه چیزی در یک تعامل وجود دارد؟
محرک اصلی تعامل اغلب جاوا اسکریپت است، اگرچه مرورگرها تعامل را از طریق کنترل هایی که توسط جاوا اسکریپت پشتیبانی نمی شوند، مانند چک باکس ها، دکمه های رادیویی، و کنترل هایی که توسط CSS ارائه می شوند، ارائه می دهند.
برای اهداف INP، فقط انواع تعامل زیر مشاهده می شود:
- کلیک کردن با ماوس.
- ضربه زدن بر روی دستگاه دارای صفحه لمسی.
- فشار دادن یک کلید روی صفحه کلید فیزیکی یا صفحه کلید.
نکته کلیدی: شناور کردن و پیمایش در INP فاکتور نمی شود. با این حال، پیمایش با صفحه کلید (نوار فاصله، صفحه به بالا، صفحه پایین، و غیره) شامل یک ضربه زدن به کلید است، که می تواند رویدادهای دیگری را که INP اندازه گیری می کند ، ایجاد کند. هر پیمایش حاصل در محاسبه INP لحاظ نمی شود.
فعل و انفعالات در سند اصلی یا در فریم های تعبیه شده در سند رخ می دهد - برای مثال، کلیک کردن روی پخش روی یک ویدیوی جاسازی شده. از آنجایی که کاربران نهایی نمیدانند کدام قسمتهای صفحه در iframes هستند، باید INP را در iframes اندازهگیری کنید تا آن را برای کل صفحه به دقت اندازهگیری کنید. با این حال، APIهای وب جاوا اسکریپت به محتوای iframe دسترسی ندارند و ممکن است نتوانند INP را در یک iframe اندازه گیری کنند. این به عنوان تفاوت بین CrUX و RUM نشان می دهد.
تعاملات می تواند شامل چندین رویداد باشد. برای مثال، یک ضربه کلید شامل رویدادهای keydown
، keypress
، و keyup
و تعاملات ضربه شامل رویدادهای pointerup
و pointerdown
است. رویدادی با طولانیترین مدت در تعامل به عنوان تأخیر تعامل انتخاب میشود.
INP زمانی محاسبه میشود که کاربر صفحه را ترک میکند و در نتیجه یک مقدار واحد نماینده پاسخگویی کلی صفحه در طول چرخه عمر آن است. INP پایین به این معنی است که یک صفحه به طور قابل اعتمادی به ورودی کاربر پاسخ می دهد.
INP چه تفاوتی با تاخیر ورودی اول (FID) دارد؟
INP متریک جانشین تاخیر ورودی اول (FID) است. در حالی که هر دو معیار پاسخگویی هستند، FID فقط تاخیر ورودی اولین تعامل در یک صفحه را اندازه گیری کرد. INP با در نظر گرفتن تمام فعل و انفعالات صفحه، از تأخیر ورودی، تا زمانی که برای اجرای کنترلکننده رویداد طول میکشد، و در نهایت تا زمانی که مرورگر فریم بعدی را نقاشی کند، FID را بهبود میبخشد.
این تفاوت ها به این معنی است که هر دو INP و FID انواع مختلفی از معیارهای پاسخگویی هستند. در جایی که FID یک معیار پاسخگویی بار بود که برای ارزیابی اولین تأثیر صفحه بر کاربر طراحی شده بود، INP یک شاخص قابل اعتمادتر از پاسخگویی کلی است، صرف نظر از اینکه چه زمانی در طول عمر صفحه تعاملات رخ می دهد.
اگر مقدار INP گزارش نشود چه؟
این امکان وجود دارد که یک صفحه هیچ مقدار INP برگرداند. این ممکن است به دلایل مختلفی رخ دهد، از جمله موارد زیر:
- صفحه بارگیری شد، اما کاربر هرگز با آن تعامل نداشت.
- صفحه بارگیری شد، اما کاربر با استفاده از حرکاتی که اندازهگیری نمیشوند، مانند پیمایش یا نگه داشتن ماوس روی عناصر، با آن تعامل داشت.
- این صفحه توسط یک ربات قابل دسترسی است، مانند یک خزنده جستجو یا مرورگر بدون سر، که برای تعامل با صفحه برنامهنویسی نشده است.
نحوه اندازه گیری INP
INP را می توان هم در میدان و هم در آزمایشگاه با استفاده از ابزارهای مختلف اندازه گیری کرد.
نکته کلیدی: بهترین راه برای اندازه گیری INP وب سایت شما، جمع آوری معیارها از کاربران واقعی در این زمینه است. اگر عادت دارید برای ارزیابی عملکرد به دادههای آزمایشگاهی تکیه کنید، توصیه میکنیم چرا دادههای آزمایشگاهی و میدانی میتوانند متفاوت باشند (و چه باید کرد) را بخوانید.
در میدان
در حالت ایده آل، سفر شما به سمت بهینه سازی INP با داده های میدانی شروع می شود. در بهترین حالت، دادههای میدانی از مانیتورینگ کاربر واقعی (RUM) نه تنها مقدار INP صفحه را به شما میدهد، بلکه دادههای متنی را نیز به شما میدهد که نشان میدهد چه تعامل خاصی مسئول مقدار INP بوده است، خواه این تعامل در حین یا پس از بارگذاری صفحه رخ داده باشد. نوع تعامل (کلیک، فشار کلید، یا ضربه زدن) و سایر اطلاعات ارزشمند.
اگر وبسایت شما واجد شرایط گنجاندن در گزارش تجربه کاربر Chrome (CrUX) باشد، میتوانید به سرعت دادههای فیلد INP را از طریق CrUX در PageSpeed Insights در کنار دادههای دیگر Core Web Vitals دریافت کنید. حداقل می توانید یک تصویر در سطح مبدا از INP وب سایت خود دریافت کنید، اما در برخی موارد، می توانید داده های سطح صفحه را نیز دریافت کنید.
با این حال، در حالی که CrUX می تواند به شما بگوید که یک مشکل در سطح بالایی وجود دارد ، اغلب جزئیات کافی برای کمک به درک کامل مشکل ارائه نمی دهد. یک راه حل RUM می تواند به شما کمک کند تا جزئیات بیشتری در مورد صفحات، کاربران یا تعاملات کاربرانی که تعاملات آهسته دارند را کشف کنید. توانایی نسبت دادن INP به تعاملات فردی به جلوگیری از حدس و گمان و تلاش بیهوده کمک می کند.
در آزمایشگاه
در حالت بهینه، میخواهید پس از دریافت دادههای میدانی که نشان میدهد تعاملات آهستهای دارید، آزمایش را در آزمایشگاه شروع کنید. با این حال، در غیاب دادههای میدانی، راهبردهایی برای بازتولید برهمکنشهای آهسته در آزمایشگاه وجود دارد. استراتژیها شامل دنبال کردن جریانهای مشترک کاربر و آزمایش تعاملات در طول مسیر، و همچنین تعامل با صفحه در حین بارگذاری، زمانی که رشته اصلی اغلب شلوغترین است، به منظور افشای تعاملات آهسته در طول آن بخش حیاتی از تجربه کاربر است.
نحوه بهبود INP
برای راهنمایی در مورد شناسایی تعاملات کند در میدان و استفاده از داده های آزمایشگاهی برای بهینه سازی آنها، مجموعه راهنماهای ما را در مورد بهینه سازی INP ببینید.
تغییرات
گاهی اوقات، اشکالات در APIهای مورد استفاده برای اندازه گیری معیارها و گاهی اوقات در تعاریف خود معیارها کشف می شود. در نتیجه، گاهی اوقات باید تغییراتی ایجاد شود و این تغییرات میتواند به صورت بهبود یا پسرفت در گزارشهای داخلی و داشبورد شما نشان داده شود.
برای کمک به مدیریت این موضوع، همه تغییرات در پیاده سازی یا تعریف این معیارها در این Changelog نشان داده شده است.
اگر بازخوردی برای این معیارها دارید، آن را در گروه web-vitals-feedback Google ارائه کنید.