INP چیست و چه تاثیری بر تجربه کاربر دارد؟

در یکی از پروژه‌های فروشگاهی که سال گذشته روی آن کار می‌کردم، سایتی با LCP زیر ۲ ثانیه و CLS زیر ۰.۰۵ داشت، اما امتیاز Core Web Vitals همچنان قرمز بود. وقتی گزارش Search Console را باز کردم، متوجه شدم که INP (Interaction to Next Paint) سایت، بالای ۸۰۰ میلی‌ثانیه است. کاربران در نظرات شکایت داشتند که دکمه خرید، با تأخیر پاسخ می‌دهد و منوی کشویی، با لگ باز می‌شود. علت روشن بود: یک افزونۀ سنگین، روی رویداد scroll و click، کد جاوااسکریپت پیچیده‌ای اجرا می‌کرد که Main Thread را قفل می‌کرد. بعد از بهینه‌سازی، INP به ۱۸۰ میلی‌ثانیه رسید و نرخ تبدیل موبایل، ۱۵ درصد بهبود یافت. این تجربه نشان می‌دهد که INP، یکی از مهم‌ترین معیارهای تجربه کاربری است که گاهی نادیده گرفته می‌شود. در این مقاله، بر اساس تجربه‌های مهندسی، INP را بررسی می‌کنم.

طبق گزارش Google، INP در مارس ۲۰۲۴ به عنوان جانشین FID (First Input Delay) معرفی شد و امروز یکی از سه معیار اصلی Core Web Vitals است. طبق گزارش Chrome User Experience Report، حدود ۴۰ درصد از سایت‌ها، INP بالای ۲۰۰ میلی‌ثانیه دارند که در محدوده "نیازمند بهبود" قرار می‌گیرد. طبق گزارش Web Almanac، میانگین INP در سایت‌های موبایل، حدود ۲۵۰ میلی‌ثانیه است، در حالی که در سایت‌های بهینه، حدود ۱۰۰ میلی‌ثانیه است. این آمارها نشان می‌دهد که INP یکی از چالش‌برانگیزترین معیارهای Core Web Vitals است. اگر با مفاهیم پایه‌ای آشنا نیستید، ابتدا Core Web Vitals چیست و LCP چیست و چگونه آن را بهینه کنیم را مطالعه کنید.

INP در یک تعریف دقیق

INP (Interaction to Next Paint) یکی از سه معیار Core Web Vitals است که تأخیر بین تعامل کاربر و پاسخ بصری مرورگر را می‌سنجد. به زبان ساده، INP زمان بین لحظه‌ای که کاربر روی یک عنصر کلیک یا لمس می‌کند، و لحظه‌ای که مرورگر تغییر بصری را به کاربر نمایش می‌دهد را اندازه‌گیری می‌کند. مفهوم Interaction to Next Paint (INP) توسط Google معرفی شد و امروز به عنوان یکی از مهم‌ترین معیارهای تجربه کاربری شناخته می‌شود.

سه فاز اصلی INP: اول، Input Delay که زمان بین تعامل کاربر و شروع پردازش رویداد توسط مرورگر است. دوم، Processing Time که زمان اجرای Event Handler است. سوم، Presentation Delay که زمان بین پایان پردازش و رندر تغییر بصری است. INP، مجموع این سه فاز است.

آستانه	INP	وضعیت
خوب (Good)	≤ ۲۰۰ms	تجربه کاربری مطلوب
نیازمند بهبود (Needs Improvement)	۲۰۱-۵۰۰ms	تجربه کاربری ضعیف
ضعیف (Poor)	> ۵۰۰ms	تجربه کاربری نامطلوب

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

INP، صدای کاربر در لحظه تعامل است: هر کلیک، هر لمس، و هر واکنش. تفاوت بین سایت سریع و سایت کند، در همین چند صد میلی‌ثانیه نهفته است.

چرا FID جایگزین شد؟

FID (First Input Delay) معیار قبلی Core Web Vitals برای تعامل بود که فقط تأخیر اولین تعامل کاربر با صفحه را می‌سنجید. اما این معیار، سه محدودیت جدی داشت که در سال‌های اخیر آشکار شد. اول، FID فقط اولین تعامل را می‌سنجید. اگر کاربر ۲۰ بار در صفحه کلیک می‌کرد، FID فقط اولین کلیک را گزارش می‌داد. این یعنی اگر تعامل پنجم به شدت کند بود، FID آن را نشان نمی‌داد.

دوم، FID فقط Input Delay را می‌سنجید. به این معنا که اگر پردازش رویداد ۲ ثانیه طول می‌کشید اما Input Delay پایین بود، FID امتیاز خوبی می‌داد. این یعنی FID، نیمی از داستان را نادیده می‌گرفت.

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

INP در مارس ۲۰۲۴ به عنوان جانشین FID معرفی شد. INP سه محدودیت بالا را حل می‌کند: اول، تمام تعاملات کاربر در طول یک Session را می‌سنجد. دوم، کل چرخه تعامل (Input Delay، Processing Time، Presentation Delay) را پوشش می‌دهد. سوم، تمام عمر صفحه (نه فقط بارگذاری) را در نظر می‌گیرد. طبق گزارش Google، این تغییر، تجربه کاربری را به شکل دقیق‌تری سنجیده می‌شود.

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

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

تعامل کاربر: کلیک روی دکمه
  |
  |--- Input Delay (تأخیر ورودی)
  |     زمان بین کلیک و شروع پردازش رویداد
  |
  |--- Processing Time (زمان پردازش)
  |     زمان اجرای Event Handler
  |
  |--- Presentation Delay (تأخیر نمایش)
        زمان بین پایان پردازش و رندر تغییر بصری

فاز اول، Input Delay: این فاز، زمان بین لحظه‌ای که کاربر روی عنصر کلیک می‌کند و لحظه‌ای که مرورگر شروع به پردازش رویداد می‌کند را می‌سنجد. اگر Main Thread در حال اجرای یک Task طولانی باشد، Input Delay می‌تواند بالا باشد. طبق گزارش Google، Input Delay مسئول حدود ۳۰ درصد از INP بد است.

فاز دوم، Processing Time: این فاز، زمان اجرای Event Handler (تابع جاوااسکریپت که به رویداد پاسخ می‌دهد) را می‌سنجد. اگر Event Handler پیچیده باشد یا کوئری‌های سنگین دیتابیس داشته باشد، Processing Time بالا می‌رود. طبق گزارش Google، Processing Time مسئول حدود ۵۰ درصد از INP بد است.

فاز سوم، Presentation Delay: این فاز، زمان بین پایان پردازش و رندر تغییر بصری است. اگر مرورگر نیاز به Recalculation، Reflow یا Repaint داشته باشد، Presentation Delay بالا می‌رود. طبق گزارش Google، Presentation Delay مسئول حدود ۲۰ درصد از INP بد است.

نکته مهم این است که INP، مقدار ۷۵امین صدک از تمام تعاملات کاربران را در نظر می‌گیرد. یعنی اگر ۲۵ درصد از کاربران تعامل سریع و ۷۵ درصد تعامل کند داشته باشند، INP، مقدار ۷۵ درصدی را گزارش می‌دهد. این رویکرد، برخلاف میانگین، تصویر واقعی‌تری از تجربه کاربران ارائه می‌دهد. اگر با این حوزه آشنا نیستید، ابزارهای سنجش Core Web Vitals را مطالعه کنید.

Main Thread و Long Tasks

برای درک INP، باید Main Thread (رشته اصلی) و Long Tasks (تسک‌های طولانی) را بشناسیم. Main Thread، رشته‌ای است که مرورگر برای اجرای جاوااسکریپت، محاسبات DOM، Recalculation Style و Reflow استفاده می‌کند. اگر Main Thread مشغول باشد، تعامل کاربر باید در صف بماند و این یعنی INP بالا.

Long Tasks، تسک‌هایی هستند که بیش از ۵۰ میلی‌ثانیه طول می‌کشند. این تسک‌ها، Main Thread را برای مدت طولانی مشغول نگه می‌دارند و مانع پاسخ مرورگر به تعاملات کاربر می‌شوند. طبق گزارش Google، هر Long Task می‌تواند INP را تا ۱۰۰ میلی‌ثانیه افزایش دهد.

سه نوع Long Tasks: اول، Long Tasks مربوط به JavaScript که در نتیجه اجرای کد پیچیده ایجاد می‌شوند. دوم، Long Tasks مربوط به Rendering که در نتیجه DOM پیچیده یا CSS سنگین ایجاد می‌شوند. سوم، Long Tasks مربوط به Layout که در نتیجه اندازه‌گیری عناصر یا ترتیبات پویا ایجاد می‌شوند.

ابزارهای تشخیص Long Tasks: اول، Chrome DevTools با پنل Performance که Long Tasks را با رنگ نارنجی نمایش می‌دهد. دوم، Performance Observer API که به صورت برنامه‌نویسی Long Tasks را شناسایی می‌کند. سوم، Lighthouse با بخش "Avoid long main-thread tasks". چهارم، WebPageTest با بخش "Long Tasks" در Waterfall. پنجم، Chrome User Experience Report که INP را در داده‌های میدانی نشان می‌دهد. اگر با این حوزه آشنا نیستید، ابزارهای بهینه‌سازی عملکرد وب را مطالعه کنید.

INP، زبان تعامل است. اگر Main Thread پر باشد، هیچ تعاملی پاسخ سریع نمی‌گیرد. تفاوت بین سایت پاسخ‌گو و سایت لنگ، در همین Main Thread است.

علل اصلی INP بد

INP بد، معمولاً از چند علت ترکیبی ناشی می‌شود. پنج علت اصلی که در پروژه‌ها با آن‌ها روبرو می‌شوم:

علت اول، JavaScript سنگین: اگر سایت شما کد JavaScript زیادی لود می‌کند، Main Thread برای اجرای آن‌ها مشغول می‌شود و پاسخ به تعاملات کاربر با تأخیر انجام می‌شود. مثال‌های رایج: افزونه‌های اسلایدر، پاپ‌آپ، آنالیتیکس سنگین، A/B Testing، Chat Widgets، Heatmaps. طبق گزارش Chrome User Experience Report، حدود ۴۰ درصد از سایت‌ها، بیش از ۵۰۰ کیلوبایت JavaScript در صفحه دارند که مستقیماً بر INP اثر می‌گذارد.

علت دوم، Event Handlers سنگین: اگر Event Handler (تابع جاوااسکریپت که به رویداد پاسخ می‌دهد) پیچیده باشد یا کوئری‌های سنگین داشته باشد، Processing Time بالا می‌رود. مثال: در یک فروشگاه، وقتی کاربر روی "افزودن به سبد خرید" کلیک می‌کند، اگر Event Handler کوئری به دیتابیس، به‌روزرسانی DOM و ارسال درخواست به سرور را در یک تابع انجام دهد، Processing Time می‌تواند به ۵۰۰ میلی‌ثانیه یا بیشتر برسد.

علت سوم، CSS و DOM پیچیده: اگر DOM شما خیلی عمیق باشد (مثلاً div تودرتو)، یا CSS شما با Selectors پیچیده باشد، Recalculation Style و Reflow می‌تواند طولانی شود. این به Presentation Delay اضافه می‌کند. طبق گزارش Web Almanac، حدود ۳۰ درصد از سایت‌ها، DOM با عمق بیش از ۱۵ لایه دارند که مستقیماً بر INP اثر می‌گذارد.

علت چهارم، Third-Party Scripts: اسکریپت‌های شخص ثالث مثل Google Analytics، Facebook Pixel، Hotjar، Intercom و Chat Widgets، معمولاً بدون کنترل شما اجرا می‌شوند و Main Thread را مشغول می‌کنند. طبق گزارش WebPageTest، Third-Party Scripts مسئول حدود ۵۰ درصد از Long Tasks در سایت‌های مدرن هستند.

علت پنجم، Hydration در React و Vue: اگر از React یا Vue استفاده می‌کنید، Hydration (تبدیل HTML استاتیک به DOM پویا) می‌تواند Main Thread را برای مدت طولانی مشغول کند، به‌ویژه در صفحات پیچیده. این مشکل در Next.js با Server-Side Rendering بیشتر خود را نشان می‌دهد.

تأثیر INP بر تجربه کاربر

INP، برخلاف LCP و CLS که بر تجربه بصری اثر می‌گذارند، بر تجربه تعاملی سایت اثر می‌گذارد. سه سطح تأثیر INP بر تجربه کاربر:

سطح اول، واکنش سریع: اگر INP زیر ۲۰۰ میلی‌ثانیه باشد، کاربر احساس می‌کند که سایت سریع و پاسخ‌گو است. مطالعات نشان می‌دهد که کاربران، تعامل زیر ۱۰۰ میلی‌ثانیه را "فوری" و تعامل زیر ۳۰۰ میلی‌ثانیه را "سریع" درک می‌کنند.

سطح دوم، لگ محسوس: اگر INP بین ۲۰۰ تا ۵۰۰ میلی‌ثانیه باشد، کاربر احساس لگ می‌کند. این لگ، به‌ویژه در تعاملات متوالی (مثل اسکرول، تایپ، کلیک‌های پی‌درپی) بیشتر محسوس است. طبق گزارش Nielsen Norman Group، تعامل بیش از ۳۰۰ میلی‌ثانیه، کاربر را ناراضی می‌کند.

سطح سوم، نارضایتی شدید: اگر INP بالای ۵۰۰ میلی‌ثانیه باشد، کاربر احساس می‌کند که سایت "خراب" است. این تجربه، به ترک سایت، کاهش نرخ تبدیل و کاهش اعتماد برند منجر می‌شود. طبق گزارش Google، سایت‌هایی با INP بالای ۵۰۰ میلی‌ثانیه، تا ۲۰ درصد نرخ پرش بالاتری دارند.

نکته مهم این است که INP بد، به‌ویژه در موبایل بیشتر محسوس است، چون پردازنده موبایل ضعیف‌تر از دسکتاپ است و Main Thread راحت‌تر قفل می‌شود. طبق گزارش Web Almanac، INP متوسط در موبایل حدود ۲۵۰ میلی‌ثانیه و در دسکتاپ حدود ۱۵۰ میلی‌ثانیه است. اگر با این حوزه آشنا نیستید، بهینه‌سازی موبایل چیست را مطالعه کنید.

تأثیر INP بر کسب‌وکار

INP فراتر از تجربه کاربری، بر کسب‌وکار نیز اثر می‌گذارد. طبق گزارش Google، سایت‌هایی که INP خود را از ۵۰۰ میلی‌ثانیه به ۲۰۰ میلی‌ثانیه رسانده‌اند، تا ۲۵ درصد افزایش در نرخ تبدیل را تجربه کرده‌اند. طبق گزارش Deloitte، هر ۱۰۰ میلی‌ثانیه کاهش در زمان پاسخ تعامل، ۱.۲ درصد افزایش در نرخ تبدیل به همراه دارد.

سه سطح تأثیر INP بر کسب‌وکار: اول، نرخ تبدیل (Conversion Rate). دوم، تجربه کاربری که به تکرار مراجعه منجر می‌شود. سوم، رتبه‌بندی در گوگل که بر ترافیک ارگانیک اثر می‌گذارد.

طبق گزارش Semrush، سایت‌های فروشگاهی که INP زیر ۲۰۰ میلی‌ثانیه دارند، تا ۱۵ درصد نرخ تبدیل بالاتری دارند نسبت به سایت‌هایی که INP بالای ۵۰۰ میلی‌ثانیه دارند. طبق گزارش Chrome User Experience Report، سایت‌هایی با INP سبز، تا ۱۰ درصد ترافیک ارگانیک بیشتری دارند.

نکته مهم این است که INP، برخلاف LCP که یک بار در صفحه اندازه‌گیری می‌شود، در تمام عمر Session کاربر اندازه‌گیری می‌شود. این یعنی INP، برخلاف LCP، کیفیت تجربه کل Session را نشان می‌دهد. اگر می‌خواهید در حوزه سئو عمیق‌تر شوید، بهبود رتبه در گوگل و Core Web Vitals چیست را مطالعه کنید.

INP در React و وردپرس

INP در React و وردپرس، چالش‌های خاص خود را دارد. در React، سه علت اصلی INP بد: اول، Hydration که Main Thread را مشغول می‌کند. دوم، Re-rendering‌های مکرر که در نتیجه عدم استفاده از Memoization یا useMemo ایجاد می‌شوند. سوم، کامپوننت‌های سنگین بدون Code Splitting.

راه‌حل‌های React برای INP: اول، استفاده از React Server Components (RSC) برای کاهش JavaScript Client-Side. دوم، استفاده از Suspense و lazy loading برای Code Splitting. سوم، استفاده از useDeferredValue برای تعاملات گران. چهارم، استفاده از Concurrent Features در React 18 (useTransition). پنجم، انتقال محاسبات سنگین به Web Worker.

در وردپرس، سه علت اصلی INP بد: اول، افزونه‌های سنگین که JavaScript زیادی لود می‌کنند. دوم، قالب‌های پرمخاطب که DOM پیچیده دارند. سوم، اسکریپت‌های شخص ثالث (مثل Google Analytics، Chat Widgets) که Main Thread را مشغول می‌کنند.

راه‌حل‌های وردپرس برای INP: اول، حذف افزونه‌های غیرضروری. اگر با این حوزه آشنا نیستید، شناسایی افزونه‌های اضافی را مطالعه کنید. دوم، استفاده از افزونه‌های سبک. سوم، فعال‌سازی Lazy Loading برای اسکریپت‌های غیرحیاتی. چهارم، انتقال اسکریپت‌های شخص ثالث به Cloudflare Workers یا Service Worker. پنجم، استفاده از قالب سبک. اگر با این حوزه آشنا نیستید، قالب سبک وردپرس و علل کندی قالب‌ها را مطالعه کنید.

عیب‌یابی INP

عیب‌یابی INP، نیازمند رویکرد نظام‌مند است. پنج گام اصلی که در پروژه‌ها استفاده می‌کنم:

گام اول، اندازه‌گیری INP: از Chrome User Experience Report (CrUX) یا Search Console برای دیدن INP واقعی کاربران استفاده کنید. اگر CrUX داده ندارد (سایت کم‌ترافیک)، از Lighthouse یا WebPageTest استفاده کنید.

گام دوم، شناسایی صفحات مشکل‌دار: در Search Console، گروه‌های URL که INP قرمز دارند را شناسایی کنید. معمولاً صفحاتی با تعامل بالا (مثل سبد خرید، فرم، لندینگ) INP بدی دارند.

گام سوم، پروفایل کردن تعاملات: در Chrome DevTools، پنل Performance را باز کنید و روی "Record" کلیک کنید. سپس روی صفحه تعامل کنید (کلیک، تایپ، اسکرول). بعد از "Stop"، Long Tasks را در Timeline مشاهده کنید. نام فایل و تابع که Long Task را ایجاد می‌کند، در پروفایل قابل مشاهده است.

# الگوی نمونه در Chrome DevTools Performance
1. Chrome DevTools را باز کنید (F12)
2. به تب Performance بروید
3. روی دکمه Record (دایره سیاه) کلیک کنید
4. در صفحه کلیک یا اسکرول کنید
5. Stop را بزنید
6. در Timeline، به دنبال بلوک‌های نارنجی (Long Tasks) بگردید
7. روی هر بلوک کلیک کنید تا تابع مسئول را ببینید

گام چهارم، تحلیل Third-Party Scripts: از پنل Network در DevTools یا ابزارهایی مثل WebPageTest برای شناسایی Third-Party Scripts استفاده کنید. اگر بخش بزرگی از Long Tasks ناشی از Third-Party Scripts باشد، باید آن‌ها را به تأخیر بیندازید یا از Main Thread خارج کنید.

گام پنجم، تست در محیط واقعی: از ابزارهایی مثل Chrome DevTools Device Toolbar با CPU Throttling (4x یا 6x) برای شبیه‌سازی موبایل میان‌رده استفاده کنید. INP در دسکتاپ سریع شما، ممکن است در موبایل میان‌رده بد باشد.

استراتژی‌های بهینه‌سازی INP

بهینه‌سازی INP، نیازمند رویکرد چندلایه است. هفت استراتژی اصلی که در پروژه‌ها استفاده می‌کنم:

استراتژی اول، کاهش JavaScript: JavaScript را به حداقل برسانید. افزونه‌های غیرضروری را حذف کنید. از Tree Shaking و Code Splitting استفاده کنید. اگر با این حوزه آشنا نیستید، تأثیر افزونه‌ها بر سرعت و بهترین افزونه‌های کش را مطالعه کنید.

استراتژی دوم، انتقال بار به Web Worker: محاسبات سنگین را به Web Worker منتقل کنید تا Main Thread آزاد بماند. مثال: رمزگذاری، پردازش تصویر، محاسبات ریاضی پیچیده.

استراتژی سوم، بهینه‌سازی Event Handlers: از Debouncing و Throttling برای Event Handlers پرتکرار (مثل scroll، resize، input) استفاده کنید. محاسبات سنگین را در Event Handler انجام ندهید. از Event Delegation برای کاهش تعداد Listenerها استفاده کنید.

// بد: Event Handler سنگین
button.addEventListener('click', () => {
  const result = heavyComputation(); // ۵۰۰ms
  updateUI(result);
});

// خوب: انتقال به Web Worker
button.addEventListener('click', () => {
  worker.postMessage({ action: 'compute' });
});

worker.onmessage = (e) => {
  updateUI(e.data);
};

استراتژی چهارم، Yield to Main Thread: محاسبات طولانی را به بخش‌های کوچک‌تر تقسیم کنید و بین آن‌ها به Main Thread فرصت دهید تا به تعاملات پاسخ دهد. از APIهایی مثل scheduler.yield() یا setTimeout() با مقدار صفر استفاده کنید.

// بد: محاسبه یک‌باره بزرگ
async function processAllItems(items) {
  for (const item of items) {
    processItem(item);
  }
}

// خوب: Yield به Main Thread
async function processAllItems(items) {
  for (const item of items) {
    processItem(item);
    await scheduler.yield(); // فرصت به Main Thread
  }
}

استراتژی پنجم، کاهش DOM Depth: DOM را ساده کنید. از div تودرتوی غیرضروری پرهیز کنید. از CSS Selectors ساده استفاده کنید. از Virtual Scrolling برای لیست‌های بزرگ استفاده کنید. اگر با این حوزه آشنا نیستید، استانداردهای HTML و CSS را مطالعه کنید.

استراتژی ششم، Third-Party Scripts: از بارگذاری Third-Party Scripts در Critical Path پرهیز کنید. از async یا defer استفاده کنید. از Facade Pattern استفاده کنید (مثلاً Chat Widget با یک تصویر استاتیک شروع شود و بعد از کلیک کاربر، اسکریپت اصلی لود شود). از Cloudflare Workers برای اجرای Third-Party Scripts در Edge استفاده کنید.

استراتژی هفتم، Preconnect و Prefetch: از preconnect و dns-prefetch برای منابع Third-Party استفاده کنید. از prefetch برای منابعی که ممکن است کاربر استفاده کند، استفاده کنید. این تکنیک‌ها، Input Delay را کاهش می‌دهند.

ابزارهای اندازه‌گیری INP

ابزار	نوع	هزینه	ویژگی
Chrome DevTools Performance	Lab	رایگان	پروفایل دقیق Long Tasks
Lighthouse	Lab	رایگان	امتیاز INP و پیشنهادات
PageSpeed Insights	Lab + Field	رایگان	INP با CrUX Data
Google Search Console	Field	رایگان	INP در گروه‌های URL
CrUX Dashboard	Field	رایگان	INP با Data Studio
WebPageTest	Lab	رایگان	Long Tasks در Waterfall
SpeedCurve	Lab + Field	پولی	پایش مداوم INP
Calibre	Lab + Field	پولی	پایش INP با CI/CD

نکات مهم در اندازه‌گیری: اول، از CrUX به عنوان داده میدانی اصلی استفاده کنید. دوم، از DevTools Performance برای Debugging استفاده کنید. سوم، از Lighthouse CI در CI/CD برای جلوگیری از رگرسیون. چهارم، پایش هفتگی و ماهانه. پنجم، از CPU Throttling برای شبیه‌سازی موبایل میان‌رده استفاده کنید. اگر با ابزارهای تحلیلی آشنا نیستید، بهترین ابزارهای تست سرعت و ابزارهای بهینه‌سازی عملکرد وب را مطالعه کنید.

پرسش‌های پرتکرار درباره INP

INP چیست و چرا مهم است؟ INP (Interaction to Next Paint) یکی از سه معیار Core Web Vitals است که تأخیر بین تعامل کاربر و پاسخ بصری مرورگر را می‌سنجد. INP مهم است چون تجربه تعاملی سایت را نشان می‌دهد و مستقیماً بر نرخ تبدیل و رتبه‌بندی گوگل اثر می‌گذارد.

چه تفاوتی بین FID و INP وجود دارد؟ FID فقط اولین تعامل را می‌سنجید و فقط Input Delay را در نظر می‌گرفت. INP تمام تعاملات کاربر در طول Session را می‌سنجد و کل چرخه تعامل (Input Delay، Processing Time، Presentation Delay) را پوشش می‌دهد.

INP ایده‌آل چقدر است؟ INP زیر ۲۰۰ میلی‌ثانیه، خوب است. INP بین ۲۰۰ تا ۵۰۰ میلی‌ثانیه، نیازمند بهبود است. INP بالای ۵۰۰ میلی‌ثانیه، ضعیف است. برای سایت‌های فروشگاهی، توصیه می‌کنم INP زیر ۱۵۰ میلی‌ثانیه باشد.

چگونه INP را بهبود دهم؟ هفت استراتژی اصلی: کاهش JavaScript، انتقال بار به Web Worker، بهینه‌سازی Event Handlers، Yield to Main Thread، کاهش DOM Depth، مدیریت Third-Party Scripts، استفاده از Preconnect و Prefetch.

چگونه INP را در وردپرس بهبود دهم؟ اول، حذف افزونه‌های غیرضروری. دوم، استفاده از افزونه‌های سبک. سوم، فعال‌سازی Lazy Loading برای اسکریپت‌های غیرحیاتی. چهارم، انتقال Third-Party Scripts به Cloudflare Workers. پنجم، استفاده از قالب سبک. اگر با این حوزه آشنا نیستید، افزایش سرعت وردپرس را مطالعه کنید.

چگونه INP را در React بهبود دهم؟ اول، استفاده از React Server Components. دوم، استفاده از Suspense و lazy loading. سوم، استفاده از useDeferredValue. چهارم، استفاده از Concurrent Features (useTransition). پنجم، انتقال محاسبات به Web Worker.

چگونه INP را اندازه‌گیری کنم؟ از Chrome User Experience Report (CrUX) برای داده میدانی، از Chrome DevTools Performance برای Debugging، از Lighthouse برای امتیاز، و از Search Console برای گروه‌های URL. برای پایش مستمر، از SpeedCurve یا Calibre استفاده کنید.

آیا INP بر رتبه‌بندی گوگل اثر دارد؟ بله. INP یکی از سه معیار Core Web Vitals است که به عنوان سیگنال رتبه‌بندی استفاده می‌شود. طبق گزارش Google، سایت‌هایی که Core Web Vitals سبز دارند، تا ۱۰ درصد ترافیک ارگانیک بیشتری دارند.

دیدگاه مهندسی پیشرفته

برای مهندسان ارشد و تیم‌های فنی، INP را می‌توان به عنوان یک سیستم بهینه‌سازی چندلایه در نظر گرفت. سه الگوی مهندسی که در این حوزه بسیار مؤثر هستند:

Interaction Performance Budget: یک Performance Budget تعریف کنید که محدودیت‌های مشخص برای INP، تعداد Long Tasks و مجموع JavaScript تعیین کند. این Budget را در CI/CD قرار دهید و در هر PR آن را اعتبارسنجی کنید. اگر PR از Budget تجاوز کند، Build شکست بخورد. این رویکرد، به جلوگیری از رگرسیون کمک می‌کند. اگر با CI/CD آشنا نیستید، مقایسه ابزارهای CI/CD را مطالعه کنید.
Continuous INP Monitoring: یک Dashboard بسازید که در بازه‌های منظم، INP سایت را با ابزارهای مختلف (CrUX، Lighthouse، WebPageTest) بسنجد. این Dashboard، به شناسایی سریع رگرسیون کمک می‌کند. برای آشنایی با ابزارهای تحلیلی، نقد و بررسی Google Analytics و مقایسه سرویس‌های تحلیل رفتار کاربر را مطالعه کنید.
Interaction-Driven Architecture: INP را از ابتدا در معماری لحاظ کنید. یعنی در انتخاب فریم‌ورک، افزونه، کتابخانه و سایر اجزا، INP را به عنوان یک معیار اصلی در نظر بگیرید. از Web Worker برای محاسبات سنگین استفاده کنید. از Yield to Main Thread در Event Handlers استفاده کنید. از Third-Party Scripts با احتیاط استفاده کنید. اگر با معماری وب مدرن آشنا نیستید، اصول طراحی معماری وب مدرن و تفاوت معماری وب و نرم‌افزار را مطالعه کنید.

یک نکته مهم برای تیم‌های فنی: INP را در چرخه CI/CD وارد کنید. یعنی در هر انتشار، تست‌های خودکار برای بررسی INP اجرا شود. در پروژه‌های وردپرسی، قالب و افزونه‌های سفارشی را می‌توانید با گیت نسخه‌بندی کنید تا هر تغییر قابل بازگشت باشد. اگر با Git آشنا نیستید، گیت در وردپرس و آموزش Git از صفر را مطالعه کنید.

افق INP در آینده

INP در ۲۰۲۶، شاهد تحولات بنیادین در چند محور است: اول، افزایش سهم INP در Core Web Vitals به عنوان معیار اصلی تعامل. دوم، ادغام INP با ابزارهای AI برای شناسایی خودکار Long Tasks. سوم، ظهور استانداردهای جدید برای Yield to Main Thread. چهارم، افزایش اهمیت INP در جستجوهای صوتی و دستیارهای AI. پنجم، ظهور ابزارهای تخصصی برای پایش INP در محیط‌های توزیع‌شده.

هفت اصل کلیدی که در این مقاله بررسی شد:

INP یکی از سه معیار Core Web Vitals است که تأخیر بین تعامل و پاسخ را می‌سنجد.
INP در مارس ۲۰۲۴ جایگزین FID شد و تمام تعاملات و کل چرخه تعامل را می‌سنجد.
INP از سه فاز Input Delay، Processing Time و Presentation Delay تشکیل شده است.
علل اصلی INP بد: JavaScript سنگین، Event Handlers سنگین، DOM پیچیده، Third-Party Scripts و Hydration.
INP مستقیماً بر تجربه کاربری و کسب‌وکار اثر می‌گذارد.
هفت استراتژی اصلی برای بهبود INP: کاهش JavaScript، Web Worker، بهینه‌سازی Event Handlers، Yield to Main Thread، کاهش DOM Depth، مدیریت Third-Party Scripts، Preconnect.
INP را در چرخه CI/CD وارد کنید تا از رگرسیون جلوگیری شود.

قدم عملی امروز: به سایت خود نگاه کنید و سه سؤال بپرسید. اول، آیا INP سایت را در Search Console بررسی کرده‌اید؟ دوم، آیا از Long Tasks در Chrome DevTools پروفایل گرفته‌اید؟ سوم، آیا استراتژی Yield to Main Thread در Event Handlers پیاده‌سازی کرده‌اید؟ اگر پاسخ یکی از این سه سؤال «نه» است، امروز زمان خوبی برای شروع است. اگر می‌خواهید در حوزه‌های مرتبط عمیق‌تر شوید، Core Web Vitals چیست و ابزارهای سنجش Core Web Vitals را مطالعه کنید.

اگر تجربه‌ای در بهینه‌سازی INP داشتید — به‌خصوص اگر با چالشی مثل Long Tasks یا Hydration روبرو شده‌اید — در دیدگاه‌ها بنویسید. این تجربه‌ها برای خواننده‌های بعدی از هر مقاله تئوریک ارزشمندتر است. ⚡