INP چیست؟ راهنمای پارامتر Interaction to Next Paint

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

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

نحوه کار INP و اجزای تشکیل‌دهنده آن

وقتی شما در گوگل عبارت «inp چیست» را جستجو می‌کردید، احتمالاً قبلش به‌دنبال درک این موضوع بودید که چرا ابزارهای تست سرعت، سایت‌تان را کند تشخیص داده‌اند. برای پاسخ به این سؤال باید به پشت صحنه مرورگر برویم.

بسیاری از مدیران سایت تصور می‌کنند وقتی کاربر روی یک دکمه (مثلاً «افزودن به سبد خرید») کلیک می‌کند، دستور بلافاصله اجرا می‌شود. اما در واقعیت، مرورگر باید فرایند پیچیده‌ای را طی کند که Interaction to Next Paint یا همان INP، مجموع زمان کل این فرآیند است.

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

۱. تأخیر ورودی

این زمانی است که کاربر کلیک کرده اما مرورگر هنوز نتوانسته به آن توجه کند. چرا؟ چون ترد اصلی (Main Thread) مرورگر احتمالا مشغول انجام کار دیگری است (مثلاً بارگذاری یک اسکریپت تبلیغاتی یا آنالیتیکس). در این لحظه، درخواست کاربر در صف انتظار می‌ماند.

۲. زمان پردازش

وقتی مرورگر بالأخره آزاد می‌شود و سراغ درخواست کاربر می‌رود، باید کدهای جاوااسکریپت مربوط به آن دکمه را اجرا کند (Event Callbacks). اگر کدهای شما سنگین یا غیربهینه باشند، این مرحله طولانی خواهد شد. درواقع پارامتر INP چیست؟ پاسخی به همین کدهای سنگین که پردازش را کند می‌کنند.

۳. تأخیر ارائه

پس‌از اجرای کدها، مرورگر باید نتیجه را به کاربر نشان دهد (مثلاً باز شدن منو یا تغییر رنگ دکمه). مرورگر باید ساختار صفحه (DOM) را مجدداً محاسبه کرده و پیکسل‌های جدید را روی صفحه نقاشی (Paint) کند.

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

امتیاز استاندارد INP و وضعیت‌های رنگی

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

در واقع گوگل برای محاسبه این امتیاز، تمام تعاملات کاربر در طول بازدید را ضبط می‌کند و (با نادیده گرفتن یک مورد بسیار پرت در هر ۵۰ تعامل)، بدترین و طولانی‌ترین زمان تأخیر را به‌عنوان امتیاز نهایی صفحه ثبت می‌کند.

در جدول زیر بازه‌های زمانی استاندارد برای اندازه‌گیری INP در گوگل مشخص شده است.

وضعیت	بازه زمانی (میلی‌ثانیه)	تفسیر عملکرد
خوب (Good)	زیر ۲۰۰ ms	🟢 سایت واکنش‌گرا و سریع است. تجربه کاربری عالی است.
نیاز به بهبود	۲۰۰ تا ۵۰۰ ms	🟡 تأخیرهای جزئی حس می‌شود. باید کدهای JS بهینه شوند.
ضعیف (Poor)	بالای ۵۰۰ ms	🔴 سایت کند است و کاربر احتمالا احساس خرابی دکمه‌ها را دارد.

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

تفاوت INP و FID

شاید برایتان سؤال باشد که اگر FID (First Input Delay) معیار سنجش تعامل بود، چرا گوگل ناگهان تصمیم به تغییر آن گرفت؟ پاسخ ساده است: FID معیار ناقصی بود که تصویر کاملی از تجربه کاربر ارائه نمی‌داد.

برای درک بهتر اینکه پارامتر INP چیست و چه مزیتی نسبت به پارامتر قبلی دارد، باید بدانیم FID دو محدودیت بزرگ داشت:

1. فقط اولین تعامل: FID تنها اولین کلیک کاربر را می‌دید. اگر سایت شما در بارگذاری اولیه سریع بود اما پس‌از اسکرول کردن و کلیک روی دکمه پرداخت دچار کندی می‌شد، FID آن را نادیده می‌گرفت و نمره قبولی می‌داد!
2. فقط تأخیر ورودی: FID فقط زمانی را اندازه می‌گرفت که مرورگر مشغول بود و نمی‌توانست درخواست را دریافت کند. اما زمانی که صرفِ اجرای کد و نمایش نتیجه می‌شد را محاسبه نمی‌کرد.

در مقابل، اگر بخواهیم بگوییم Interaction to Next Paint چیست؟ معیاری است که گوگل معرفی کرد تا این خلاء را پر کند. INP برخلاف FID، تمام تعاملات (نه فقط اولی) را درنظر می‌گیرد و مهم‌تر از آن، کل چرخه عمر یک کلیک (شامل پردازش و نقاشی روی صفحه) را محاسبه می‌کند.

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

ابزارهای بررسی INP و روش‌های اندازه‌گیری

برای بهبود هر متریکی، ابتدا باید بتوانید آن را دقیق اندازه‌گیری کنید. خوشبختانه گوگل مجموعه‌ای از ابزارهای قدرتمند را برای اندازه‌گیری INP در گوگل و دیباگ کردن مشکلات آن ارائه کرده است. استفاده ترکیبی از این ابزارها به شما کمک می‌کند تا هم داده‌های واقعی کاربران (Field Data) و هم داده‌های آزمایشگاهی (Lab Data) را تحلیل کنید.

در اینجا لیست بهترین ابزارهای بررسی INP که هر توسعه‌دهنده و متخصص سئو باید بشناسد آمده است:

• ابزار PageSpeed Insights (PSI):

اولین قدم برای بررسی وضعیت فعلی است. این ابزار به شما نشان می‌دهد که آیا کاربران واقعی (براساس گزارش CrUX) با مشکل INP مواجه هستند یا خیر. همچنین پیشنهاداتی کلی برای رفع مشکلات INP ارائه می‌دهد.

• ابزار Google Search Console:

در بخش Core Web Vitals گزارش سرچ کنسول، می‌توانید ببینید کدام صفحات سایت شما دارای وضعیت ضعیف (Poor) یا نیاز به بهبود هستند. این گزارش برای دیدن وضعیت کلی سایت عالی است.

• افزونه Web Vitals (برای کروم):

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

• Chrome DevTools (پنل Performance):

تخصصی‌ترین ابزار برای توسعه‌دهندگان است. با استفاده از تب Performance می‌توانید دقیقاً ببینید کدام رشته کد جاوااسکریپت (Main Thread) را مسدود کرده و باعث افزایش زمان پردازش شده است. این ابزار برای تحلیل و مانیتورینگ INP در سطح کد حیاتی است.

روش‌های بهبود INP

اکنون که می‌دانیم inp چیست و مشکل کجاست، سؤال اصلی این است: بهترین روش برای بهبود INP چیست؟ اگر بخواهیم در یک جمله خلاصه کنیم: باید به مرورگر فرصت نفس کشیدن بدهید.

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

در ادامه ۴ استراتژی اصلی برای بهینه‌سازی این شاخص را بررسی می‌کنیم:

۱. شکستن تسک‌های طولانی

در مرورگرها هر وظیفه‌ای که اجرای آن بیش‌از ۵۰ میلی‌ثانیه طول بکشد، یک تسک طولانی (Long Task) محسوب می‌شود. وقتی مرورگر درحال اجرای یک تسک طولانی است، کاملاً قفل می‌شود و به هیچ کلیک یا اسکرولی پاسخ نمی‌دهد.

راهکار عملی: کدهای طولانی خود را تکه‌تکه کنید.

• به‌جای اینکه یک تابع بزرگ (مثلاً پردازش ۵۰۰۰ ردیف داده) را یک‌جا اجرا کنید، آن را به ۱۰ تابع کوچک‌تر تقسیم کنید.
• از متدهایی مانند setTimeout یا requestIdleCallback و یا API جدیدتر scheduler.yield() استفاده کنید تا بین اجرای تکه‌ها، کنترل را موقتاً به مرورگر برگردانید. این کار به مرورگر اجازه می‌دهد اگر کاربر کلیکی کرد، آن را پردازش کند و سپس به ادامه کار شما برگردد.

۲. کاهش حجم و پیچیدگی جاوااسکریپت

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

برای کاهش فشار پردازشی و در نتیجه کاهش INP:

• حذف کدهای بلااستفاده (Unused Code): با استفاده از ابزار Coverage در کروم، کدهایی که لود می‌شوند اما اجرا نمی‌شوند را پیدا و حذف کنید.
• Code Splitting: به‌جای ارسال یک فایل bundle.js عظیم ۵ مگابایتی، کدها را خرد کنید تا فقط کدهای مورد نیاز همان صفحه لود شود.
• Defer و Async: اسکریپت‌های غیرضروری (مثل چت آنلاین یا ترکرها) را با صفت defer لود کنید تا ترد اصلی را در لحظات حساس مسدود نکنند.

۳. بهینه‌سازی رویدادها

گاهی اوقات خودِ کدی که هنگام کلیک اجرا می‌شود سنگین است. مثلاً کاربر روی دکمه فیلتر کلیک می‌کند و شما بلافاصله یک تابع سنگین مرتب‌سازی را اجرا می‌کنید.

• Debouncing و Throttling: برای رویدادهایی مثل تایپ کردن در نوار جستجو یا تغییر سایز صفحه (Resize)، نباید با هر پیکسل تغییر یا هر کاراکتر، کد اجرا شود. با تکنیک Debounce مشخص کنید که تابع فقط زمانی اجرا شود که کاربر تایپ کردن را تمام کرد (مثلاً ۳۰۰ میلی‌ثانیه بعد از آخرین دکمه).
• اجتناب از Layout Thrashing: اگر در کدهای خود مدام استایل‌ها را می‌خوانید و بلافاصله تغییر می‌دهید (مثلاً خواندن offsetWidth و تنظیم width در یک حلقه)، مرورگر مجبور می‌شود بارها و بارها چیدمان صفحه را از نو محاسبه کند. این کار قاتلِ INP است. همیشه اول، خواندن‌ها را انجام دهید و سپس نوشتن‌ها را یکجا اعمال کنید.

۴. استفاده از رندرینگ سمت سرور (SSR)

این بخش اغلب نادیده گرفته می‌شود اما تاثیر شگرفی دارد. در سایت‌های Client-Side Rendering (مثل اپلیکیشن‌های سنگین React یا Vue)، مرورگر کاربرِ مجبور است ابتدا یک صفحه خالی را بگیرد، سپس مگابایت‌ها جاوااسکریپت را دانلود کند و تازه شروع به ساختن دکمه‌ها و محتوا کند. این فرآیند CPU موبایل کاربر را به‌شدت درگیر می‌کند و هر تعاملی در این حین با تأخیر مواجه می‌شود.

• راهکار: با استفاده از رندرینگ سمت سرور (SSR) یا تولید سایت استاتیک (SSG)، کدها را روی سرور قدرتمند خود اجرا کنید و یک فایل HTML آماده به کاربر تحویل دهید.
• در این حالت، مرورگر کاربر فقط وظیفه نمایش را دارد و درگیر پردازش‌های سنگین نمی‌شود. این یعنی ترد اصلی آزادتر است و سریع‌تر به کلیک‌ها پاسخ می‌دهد.

نکته تخصصی: کاهش INP فقط مربوط کدنویسی نیست؛ انتخاب معماری درست هم هست. انتقال بار پردازشی از موبایل ضعیف کاربر به یک سرور قدرتمند ابری، یکی از هوشمندانه‌ترین روش‌ها برای تضمین سرعت تعامل است.

تأثیر زیرساخت و هاستینگ بر INP

تا اینجای کار، انگشت اتهامِ پارامتر INP به سمت توسعه‌دهنده و کدهای جاوااسکریپت بود. اما آیا سرور و هاستینگ در این ماجرا بی‌تقصیرند؟ قطعاً خیر. شاید بپرسید وقتی INP یک متریک سمت کاربر (Client-side) است، سرور چه نقشی دارد؟ بیایید سناریوی یک فروشگاه اینترنتی را بررسی کنیم:

کاربر روی دکمه «افزودن به سبد خرید» کلیک می‌کند. برای اینکه این فرایند کامل شود و پیام موفقیت (Paint) به کاربر نمایش داده شود، مرورگر اغلب باید منتظر تأیید سرور بماند.

اگر زیرساخت میزبانی شما ضعیف باشد، دو اتفاق مخرب رخ می‌دهد که تأثیر INP بر سرعت سایت را منفی می‌کند:

1. تحویل کُند منابع (Slow Resource Delivery): اگر سرور شما نتواند فایل‌های حجیم جاوااسکریپت را به‌سرعت تحویل دهد، مرورگر مدت بیشتری درگیر دانلود و پردازش آن‌ها می‌ماند و در این حین به تعاملات کاربر پاسخ نمی‌دهد.
2. تأخیر در پاسخگویی (Latency): در تعاملات پویا (مثل فیلتر کردن محصولات یا لاگین کردن)، مرورگر منتظر پاسخ دیتابیس است. یک سرور اشتراکی که منابعش درگیر صدها سایت دیگر است، نمی‌تواند در کسری از ثانیه پاسخ دهد. نتیجه؟ کاربر روی دکمه کلیک کرده و باید هم‌چنان منتظر بماند (لگ).

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

سرعت سایت = کیفیت کد × زیرساخت

وقت آن رسیده که زیرساخت‌تان را با سرعت افکارتان هماهنگ کنید

اگر تمام مراحل بهینه‌سازی کدها را انجام داده‌اید اما هنوز در زمان‌های ترافیک بالا یا در پردازش‌های سنگین دیتابیسی شاهد کندی و افزایش INP هستید، مشکل از کد شما نیست؛ مشکل از ظرفیت است.

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

مزایای استفاده از سرورهای ابر فردوسی:

• سرورهای بروز و پرچمدار خانواده HPE
• بهره‌مندی از رم‌های DDR4 و هارد NVME بهینه برای پردازش
• بهره‌مندی از اینترنت نامحدود و پرسرعت در داخل ماشین مجازی
• پرداخت هزینه‌ها فقط به‌اندازه مدت زمان و منابع مورداستفاده از سرور
• مقیاس‌پذیری فوری منابع به‌اندازه نیاز پروژه یا سایت
• سفارش و تحویل آنی در چند دقیقه
• ۱۰۰ هزارتومان اعتبار رایگان ابر فردوسی برای شروع کار

جمع‌بندی

در این مقاله بررسی کردیم که inp چیست و چرا جایگزین FID شد. دانستیم که گوگل دیگر فقط به لحظه ورود کاربر اهمیت نمی‌دهد، بلکه تمام کلیک‌ها، اسکرول‌ها و تایپ کردن‌های کاربر در طول بازدید را زیر نظر دارد.

به‌طور خلاصه، برای داشتن نمره INP سبز (زیر ۲۰۰ میلی‌ثانیه):

1. کدهای جاوااسکریپت طولانی را بشکنید.
2. از ابزارهای بررسی INP مثل PageSpeed Insights برای رصد مداوم استفاده کنید.
3. پردازش‌های سنگین را از مرورگر کاربر به سمت سرور منتقل کنید.
4. فراموش نکنید که تأثیر INP بر سرعت سایت مستقیماً با کیفیت هاستینگ و زیرساخت شما گره خورده است.

منابع:
web.dev | hostinger | support.google | developer

سؤالات متداول