تعامل با رنگ بعدی (INP)

Jeremy Wagner

Barry Pollard

تاریخ انتشار: 06 می 2022، آخرین به روز رسانی: 9 سپتامبر 2025

داده‌های استفاده از کروم نشان می‌دهد که ۹۰٪ از زمان کاربر در یک صفحه پس از بارگیری آن صرف می‌شود، بنابراین، اندازه‌گیری دقیق پاسخ‌دهی در طول چرخه عمر صفحه مهم است. این چیزی است که متریک INP ارزیابی می کند.

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

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

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

در ویدیوی زیر، مثال سمت راست بازخورد بصری فوری را نشان می دهد که آکاردئون در حال باز شدن است. پاسخگویی ضعیف به عنوان مثال در سمت چپ نشان داده شده است، و اینکه چگونه می تواند تجربه کاربری ضعیفی ایجاد کند.

این راهنما توضیح می‌دهد که INP چگونه کار می‌کند، چگونه آن را اندازه‌گیری می‌کند و به منابعی برای بهبود آن اشاره می‌کند.

INP چیست؟

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

تعامل گروهی از کنترل‌کننده‌های رویداد است که در طول یک حرکت منطقی کاربر فعال می‌شوند. برای مثال، فعل و انفعالات «ضربه» روی یک دستگاه صفحه لمسی شامل چندین رویداد مانند pointerup ، pointerdown و click است. یک تعامل می تواند توسط جاوا اسکریپت، CSS، کنترل های داخلی مرورگر (مانند عناصر فرم)، یا ترکیبی از آنها هدایت شود.

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

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

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

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

• INP زیر یا در 200 میلی ثانیه به این معنی است که یک صفحه دارای پاسخگویی خوبی است.
• INP بالاتر از 200 میلی ثانیه و کمتر یا در 500 میلی ثانیه به این معنی است که پاسخگویی صفحه نیاز به بهبود دارد .
• INP بالای 500 میلی ثانیه به این معنی است که یک صفحه پاسخگویی ضعیفی دارد.

چه چیزی در یک تعامل وجود دارد؟

محرک اصلی تعامل اغلب جاوا اسکریپت است، اگرچه مرورگرها تعامل را از طریق کنترل هایی که توسط جاوا اسکریپت پشتیبانی نمی شوند، مانند چک باکس ها، دکمه های رادیویی، و کنترل هایی که توسط CSS ارائه می شوند، ارائه می دهند.

به عنوان اهداف INP، تنها انواع تعامل زیر مشاهده می شود:

• کلیک کردن با ماوس.
• ضربه زدن بر روی دستگاه دارای صفحه لمسی.
• فشار دادن یک کلید روی صفحه کلید فیزیکی یا صفحه کلید.

فعل و انفعالات در سند اصلی یا در فریم های تعبیه شده در سند رخ می دهد - برای مثال کلیک کردن روی پخش روی یک ویدیوی جاسازی شده. کاربران نهایی نمی دانند در iframe چه چیزی وجود دارد یا نه، بنابراین، INP درون iframe برای اندازه گیری تجربه کاربر برای صفحه سطح بالا مورد نیاز است. از آنجایی که APIهای وب جاوا اسکریپت به محتویات iframe دسترسی ندارند، ممکن است به عنوان تفاوتی بین CrUX و RUM نشان داده شود.

تعاملات می تواند شامل چندین رویداد باشد. به عنوان مثال، یک ضربه کلید شامل رویدادهای keydown ، keypress ، و keyup است. فعل و انفعالات ضربه‌ای حاوی رویدادهای pointerup و pointerdown هستند. رویدادی با طولانی‌ترین مدت در تعامل، چیزی است که به تأخیر کلی تعامل کمک می‌کند.

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

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

INP چه تفاوتی با تاخیر ورودی اول (FID) دارد؟

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

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

اگر مقدار INP گزارش نشود چه؟

این امکان وجود دارد که یک صفحه هیچ مقدار INP را برگرداند. این ممکن است به دلایل مختلفی رخ دهد، از جمله موارد زیر:

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

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

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

در میدان

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

اگر وب‌سایت شما واجد شرایط گنجاندن در گزارش تجربه کاربر Chrome (CrUX) باشد، می‌توانید به سرعت داده‌های میدانی برای INP از طریق CrUX در PageSpeed ​​Insights (و سایر موارد حیاتی وب اصلی) دریافت کنید. حداقل می توانید یک تصویر در سطح مبدا از INP وب سایت خود دریافت کنید، اما در برخی موارد، می توانید داده های سطح URL را نیز دریافت کنید.

با این حال، در حالی که CrUX می تواند به شما بگوید که آیا مشکلی وجود دارد ، نمی تواند به شما بگوید که چه چیزی باعث این مشکل شده است. یک راه حل RUM می تواند به شما کمک کند تا جزئیات بیشتری در مورد صفحات، کاربران یا تعاملات کاربرانی که مشکلات پاسخگویی را تجربه می کنند کشف کنید. توانایی نسبت دادن INP به تعاملات فردی از حدس و گمان و تلاش بیهوده جلوگیری می کند.

در آزمایشگاه

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

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

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

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

برای اندازه‌گیری INP در جاوا اسکریپت، باید زمان‌بندی رویدادها را برای همه تعامل‌ها اندازه‌گیری کنید، و سپس صدک ۹۸ را در تمام این تعاملات در هنگام بارگیری صفحه بگیرید. می توانید به کد منبع کتابخانه جاوا اسکریپت web vitals مراجعه کنید که حاوی یک پیاده سازی مرجع در مورد نحوه محاسبه INP است.

در بیشتر موارد، مقدار INP فعلی در زمانی که صفحه در حال بارگیری است، مقدار INP نهایی برای آن صفحه است، اما چند استثنا مهم وجود دارد که در بخش بعدی ذکر شد. کتابخانه جاوا اسکریپت web vitals این موارد را تا آنجا که ممکن است، در محدوده محدودیت های API های وب، حساب می کند.

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

• ورودی های event زیر 104 میلی ثانیه به طور پیش فرض با استفاده از ناظران عملکرد گزارش نمی شوند. زمانی که یک ناظر عملکرد با استفاده از پارامتر durationThreshold ثبت می‌شود، می‌توان این پیش‌فرض را تغییر داد، اما حتی این مقدار حداقل 16 میلی‌ثانیه است. به همین دلیل، توصیه می‌شود که ورودی first-input را نیز رعایت کنید، که همچنین یک ورودی زمان‌بندی رویداد است، اما تضمین می‌شود که حتی زمانی که مدت آن کمتر از durationThreshold باشد، قابل مشاهده است. این کمک می کند تا اطمینان حاصل شود که صفحات دارای تعامل همیشه مقداری INP را گزارش می دهند.
• محاسبه صدک ها از نظر فنی کاملاً مستلزم نگه داشتن تمام نمونه ها در حافظه است که می تواند پرهزینه باشد. اما می‌توانید صدک‌ها، به‌ویژه صدک‌های واقعاً بالا مانند p98 را با نگه‌داشتن فهرست کوچکی از بدترین برهمکنش‌های N تقریبی کنید. 10 یک انتخاب رایج است.
• اگر صفحه ای از حافظه پنهان عقب/ جلو بازیابی شود، مقدار INP آن باید به صفر بازنشانی شود زیرا کاربران این را به عنوان یک بازدید از صفحه مجزا تجربه می کنند.
• API ورودی‌های event را برای فعل و انفعالاتی که در iframe رخ می‌دهد گزارش نمی‌کند، اما معیار اندازه‌گیری آن را به‌عنوان بخشی از تجربه کاربر از صفحه انجام می‌دهد. این می تواند به عنوان تفاوت بین CrUX و RUM نشان داده شود . برای اندازه گیری صحیح INP باید آنها را در نظر بگیرید. فریم‌های فرعی می‌توانند از API برای گزارش ورودی‌های event-timing خود به فریم والد استفاده کنند.

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

• کاربران ممکن است یک برگه را برای مدت بسیار طولانی باز نگه دارند - روزها، هفته ها، ماه ها. در واقع، یک کاربر ممکن است هرگز یک برگه را نبندد.
• در سیستم‌عامل‌های تلفن همراه، مرورگرها معمولاً برای برگه‌های پس‌زمینه، بازخوانی بارگیری صفحه را اجرا نمی‌کنند و گزارش مقدار «نهایی» را دشوار می‌کند.

برای رسیدگی به چنین مواردی، INP باید هر زمان که یک صفحه پس‌زمینه است گزارش شود - علاوه بر هر زمانی که بارگیری می‌شود ( رویداد visibilitychange هر دوی این سناریوها را پوشش می‌دهد). و سیستم های تحلیلی که این داده ها را دریافت می کنند، باید مقدار INP نهایی را در باطن محاسبه کنند.

توسعه‌دهندگان می‌توانند به جای حفظ کردن و دست‌وپنجه نرم کردن با همه این موارد، از کتابخانه جاوا اسکریپت web-vitals برای اندازه‌گیری INP استفاده کنند، که همه چیزهایی را که قبلاً ذکر شد، به‌جز مورد iframe به حساب می‌آورد:

import {onINP} from 'web-vitals';

// Measure and log INP in all situations
// where it needs to be reported.
onINP(console.log);

نحوه بهبود INP

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

تغییرات

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

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

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

دانش خود را تست کنید