INP چیست و چگونه Interaction to Next Paint را بهتر کنیم؟

فرض کنید کاربر روی دکمه «افزودن به سبد خرید» کلیک می‌کند، اما برای چند لحظه هیچ اتفاقی روی صفحه نمی‌افتد. کاربر نمی‌داند کلیک ثبت شده یا نه، دوباره روی دکمه می‌زند و چند لحظه بعد چند تغییر به‌صورت هم‌زمان اتفاق می‌افتد. حتی اگر صفحه در ابتدا سریع باز شده باشد، چنین تجربه‌ای باعث می‌شود سایت کند و غیرقابل‌اعتماد به نظر برسد.

INP یا Interaction to Next Paint معیاری برای سنجش همین بخش از تجربه کاربر است: صفحه پس از تعامل کاربر با چه سرعتی می‌تواند بازخورد بصری بعدی را نمایش دهد.

INP یکی از سه معیار فعلی Core Web Vitals است و Responsiveness یا پاسخ‌گویی صفحه را اندازه‌گیری می‌کند. این معیار از ۱۲ مارس ۲۰۲۴ جایگزین FID شد و در کنار LCP و CLS برای ارزیابی جنبه‌های مهمی از تجربه واقعی کاربران استفاده می‌شود. (Google Search Central)

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

در این مقاله ابتدا می‌بینیم INP دقیقاً چه چیزی را اندازه می‌گیرد، سپس سراغ روش اندازه‌گیری، پیدا کردن تعامل‌های کند و راه‌های عملی بهبود INP می‌رویم.

INP چیست؟

Interaction to Next Paint یا به اختصار INP معیاری است که پاسخ‌گویی کلی یک صفحه به تعاملات کاربر را بررسی می‌کند.

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

برای مثال، اگر کاربر روی منوی موبایل بزند، INP فقط به این نگاه نمی‌کند که Event Handler چه زمانی شروع شده است. مدت زمانی که پردازش JavaScript و کارهای لازم برای Render شدن وضعیت جدید منو طول می‌کشد نیز در Responsiveness تعامل اهمیت دارد.

به همین دلیل INP صرفاً معیار «سرعت کلیک» یا «سرعت JavaScript» نیست. این معیار تلاش می‌کند به سؤال ملموس‌تری پاسخ دهد:

کاربر عملی انجام داده است؛ چه مدت طول می‌کشد تا صفحه بتواند نتیجه بصری مناسبی در پاسخ به آن نشان دهد؟

INP تقریباً تمام تعاملات واجد شرایط در طول بازدید از صفحه را در نظر می‌گیرد. در بیشتر صفحات، کندترین تعامل نقش اصلی را در مقدار نهایی INP دارد؛ هرچند در صفحاتی با تعداد بسیار زیاد تعامل، سازوکار INP بعضی Outlierها را کنار می‌گذارد تا یک کندی تصادفی نماینده کل تجربه صفحه نشود. (web.dev)

عدد مناسب برای INP چقدر است؟

براساس راهنمای فعلی web.dev، برای ارائه تجربه مناسب بهتر است INP صفحه ۲۰۰ میلی‌ثانیه یا کمتر باشد.

برای ارزیابی تجربه اکثر کاربران، معیارها در سطح صدک ۷۵ Page Viewها بررسی می‌شوند و داده موبایل و دسکتاپ نیز باید جداگانه در نظر گرفته شود. بنابراین سریع بودن صفحه روی لپ‌تاپ توسعه‌دهنده به‌تنهایی نشان نمی‌دهد کاربران واقعی هم INP خوبی دارند. (web.dev)

نکته مهم این است که ۲۰۰ میلی‌ثانیه یک هدف برای ارزیابی Responsiveness است، نه عددی که با رسیدن به آن تمام مشکلات تجربه کاربری یا SEO صفحه حل شوند.

INP دقیقاً از چه بخش‌هایی تشکیل می‌شود؟

برای بهبود INP باید بدانیم زمان یک تعامل کجا مصرف می‌شود. Google تعامل را از نظر زمانی به سه بخش اصلی تقسیم می‌کند:

1. Input Delay: فاصله بین زمانی که کاربر تعامل را انجام می‌دهد تا زمانی که Event Handler مربوط به آن شروع به اجرا می‌کند.
2. Processing Duration: زمانی که Event Handlerها و منطق مرتبط با تعامل در حال اجرا هستند.
3. Presentation Delay: فاصله پایان پردازش Eventها تا زمانی که مرورگر فریم بعدی را Render و نمایش می‌دهد.

مجموع این سه بخش Latency تعامل را می‌سازد. (web.dev)

فرض کنید کاربر روی دکمه باز شدن یک پنل کلیک کرده است. اگر Main Thread مشغول اجرای یک اسکریپت سنگین باشد، قبل از اینکه کد مربوط به کلیک اجرا شود Input Delay ایجاد می‌شود. اگر خود Handler محاسبات زیادی انجام دهد، Processing Duration بالا می‌رود. اگر تغییر بزرگی در DOM ایجاد شود و مرورگر برای Layout و Paint زمان زیادی مصرف کند، Presentation Delay افزایش پیدا می‌کند.

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

تفاوت INP و FID چیست؟

FID یا First Input Delay معیار قبلی Responsiveness در Core Web Vitals بود. مشکل اصلی این بود که FID فقط روی اولین تعامل کاربر و تأخیری که قبل از شروع پردازش آن وجود داشت تمرکز می‌کرد.

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

INP نگاه گسترده‌تری دارد. این معیار تعاملات کاربر را در طول حضور او در صفحه مشاهده می‌کند و علاوه بر Input Delay، پردازش تعامل و زمان لازم برای نمایش فریم بعدی را هم در Responsiveness در نظر می‌گیرد.

به همین دلیل INP از ۱۲ مارس ۲۰۲۴ به‌طور رسمی جایگزین FID در Core Web Vitals شد. (Google Search Central)

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

چگونه INP یک صفحه را اندازه بگیریم؟

بهترین نقطه شروع برای بررسی INP، داده کاربران واقعی یا Field Data است. یک تست آزمایشگاهی می‌تواند مشکل را برای ما قابل بازتولید کند، اما لزوماً تمام شرایطی را که کاربران واقعی با آن روبه‌رو می‌شوند نشان نمی‌دهد.

Search Console

گزارش Core Web Vitals در Google Search Console برای پیدا کردن صفحاتی که کاربران واقعی در آن‌ها تجربه ضعیف یا نیازمند بهبود دارند مفید است.

این گزارش برای تشخیص اینکه «کدام گروه از صفحات مشکل دارد» مناسب است، اما معمولاً به تنهایی به شما نمی‌گوید دقیقاً کدام دکمه، Event Handler یا Script باعث INP ضعیف شده است.

بنابراین Search Console بیشتر نقطه شروع بررسی است، نه آخر فرایند عیب‌یابی.

PageSpeed Insights

PageSpeed Insights داده Field را از Chrome User Experience Report یا CrUX نمایش می‌دهد. اگر برای URL موردنظر داده کافی وجود داشته باشد، می‌توانید مقدار INP کاربران واقعی را برای موبایل یا دسکتاپ بررسی کنید.

داده Real User Experience در PageSpeed Insights بر تجربه کاربران Chrome در دوره جمع‌آوری ۲۸ روز گذشته متکی است. (Google Developers)

این نکته مهم است، چون عدد INP موجود در بخش Field Data با نتیجه یک بار اجرای تست روی کامپیوتر شما یکسان نیست.

Chrome DevTools

بعد از اینکه با Field Data متوجه شدید مشکلی وجود دارد، باید تعامل کند را بازتولید کنید.

برای مثال:

• منوی موبایل را باز کنید.
• فیلتر محصولات را تغییر دهید.
• محصولی به سبد خرید اضافه کنید.
• Accordion را باز کنید.
• داخل Search Box تایپ کنید.
• فرم را Submit کنید.

Performance Panel در Chrome DevTools می‌تواند به تشخیص Long Taskها، Event Handlerهای سنگین، فعالیت زیاد Main Thread و Rendering پرهزینه کمک کند.

هدف این مرحله صرفاً دیدن یک Score نیست؛ باید بفهمید کدام تعامل کند است و زمان آن کجا مصرف می‌شود.

Real User Monitoring

برای سایت‌های بزرگ‌تر یا اپلیکیشن‌هایی که تعامل زیادی دارند، RUM یا Real User Monitoring اطلاعات بسیار ارزشمندتری فراهم می‌کند.

با استفاده از کتابخانه web-vitals می‌توان اطلاعاتی مانند عنصر ایجادکننده تعامل، نوع Interaction و سهم Input Delay، Processing Duration و Presentation Delay را جمع‌آوری کرد. این داده‌ها کمک می‌کنند بفهمید کاربران واقعی دقیقاً در کدام قسمت رابط کاربری با کندی مواجه شده‌اند. (web.dev)

چرا INP سایت ضعیف می‌شود؟

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

Main Thread برای مدت طولانی درگیر است

بخش قابل توجهی از JavaScript، پردازش Eventها، Style Calculation، Layout و بعضی مراحل Rendering روی Main Thread انجام می‌شوند.

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

این وضعیت Input Delay را افزایش می‌دهد.

JavaScript بیش از حد یا اجرای سنگین اسکریپت‌ها

حجم JavaScript به‌تنهایی معیار INP نیست، اما اجرای اسکریپت‌های زیاد می‌تواند Main Thread را درگیر کند.

برای مثال در یک سایت ممکن است هم‌زمان موارد زیر فعال باشند:

• اسکریپت‌های قالب یا Framework
• سیستم Analytics
• Tag Manager
• ابزار Chat
• تبلیغات
• Personalization
• A/B Testing
• افزونه‌های مختلف
• اسکریپت‌های Third-party

وجود هر Script الزاماً مشکل نیست. مسئله زمانی ایجاد می‌شود که اجرای آن‌ها Taskهای طولانی ایجاد کند یا با تعاملات مهم کاربر رقابت کند.

Event Handler کار زیادی انجام می‌دهد

گاهی مشکل مستقیماً در منطق یک Interaction است.

فرض کنید با کلیک روی یک فیلتر، کد صفحه هم‌زمان هزاران آیتم را پردازش می‌کند، DOM بزرگی را تغییر می‌دهد، چند محاسبه انجام می‌دهد و سپس رابط کاربری را Update می‌کند.

حتی اگر Input Delay پایین باشد، Processing Duration این Interaction می‌تواند INP را خراب کند.

تغییرات سنگین DOM و Rendering

INP با پایان Event Handler تمام نمی‌شود. مرورگر باید بتواند نتیجه بصری تعامل را نیز Paint کند.

DOM بزرگ، تغییر هم‌زمان تعداد زیادی Element، Layoutهای پیچیده یا Rendering سنگین می‌توانند Presentation Delay را افزایش دهند.

به همین دلیل اصلاح JavaScript بدون بررسی Rendering همیشه برای حل مشکل INP کافی نیست.

چگونه INP را بهتر کنیم؟

بهینه‌سازی INP بهتر است از یک Interaction واقعی شروع شود، نه از فهرستی عمومی از تکنیک‌های Performance.

ابتدا بفهمید کدام تعامل کند است؛ سپس مشخص کنید تأخیر بیشتر در Input Delay، Processing Duration یا Presentation Delay رخ می‌دهد.

۱. Long Taskها را کوتاه‌تر کنید

اگر Main Thread برای مدت زیادی در اختیار یک Task باشد، مرورگر فرصت رسیدگی سریع به Interaction جدید را پیدا نمی‌کند.

در این شرایط یکی از راهکارهای مهم، تقسیم کارهای طولانی به Taskهای کوچک‌تر و Yield کردن کنترل به Main Thread است. این کار فرصت می‌دهد مرورگر Interactionهای کاربر و Rendering را زودتر پردازش کند.

البته هدف نباید صرفاً تبدیل یک Task بزرگ به ده‌ها Task بی‌هدف باشد. ابتدا کارهای غیرضروری را حذف کنید و سپس بخش‌هایی را که واقعاً باید اجرا شوند به شکلی زمان‌بندی کنید که Main Thread برای مدت طولانی Block نشود. (web.dev)

۲. داخل Event Handler فقط کار ضروری را انجام دهید

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

برای مثال اگر کاربر روی «ذخیره» کلیک کرده است، ممکن است لازم باشد فوراً وضعیت دکمه تغییر کند و بازخورد بصری نمایش داده شود؛ اما بخشی از پردازش‌های ثانویه می‌توانند بعداً انجام شوند.

قاعده عملی این است:

هر کاری که برای نمایش پاسخ اولیه Interaction ضروری نیست، لزوماً نباید داخل مسیر بحرانی همان Interaction اجرا شود.

هرچه Event Callback سبک‌تر باشد، احتمال پایین ماندن Processing Duration بیشتر می‌شود.

۳. JavaScript غیرضروری را کاهش دهید

صرفاً Minify کردن فایل‌ها کافی نیست. باید ببینید کدام JavaScript واقعاً برای تجربه کاربر ضروری است.

در پروژه‌های واقعی معمولاً بررسی این موارد مفید است:

• Scriptهایی که در همه صفحات Load می‌شوند ولی فقط در چند صفحه کاربرد دارند.
• Libraryهایی که برای یک قابلیت کوچک وارد پروژه شده‌اند.
• کدهایی که می‌توانند Lazy Load شوند.
• Third-party Scriptهایی که ارزش آن‌ها نسبت به هزینه Performance پایین است.
• قابلیت‌هایی که بدون JavaScript سنگین هم قابل اجرا هستند.

کاهش کار JavaScript روی Main Thread می‌تواند فضای بیشتری برای پاسخ به Interaction کاربر ایجاد کند.

۴. Third-party Scriptها را Audit کنید

گاهی کد اصلی سایت مناسب است، اما ابزارهای خارجی Main Thread را اشغال می‌کنند.

Chat Widget، تبلیغات، Tracking Scriptها، ابزارهای Heatmap و برخی ابزارهای Marketing ممکن است در زمان نامناسب کار پردازشی انجام دهند.

این به معنی حذف همه Third-partyها نیست. باید ارزش هر ابزار را در مقابل هزینه Performance آن بررسی کرد و در صورت امکان Loading یا Execution آن را بهینه کرد.

۵. Rendering بعد از Interaction را سبک کنید

اگر Processing Duration مناسب است ولی فریم بعدی دیر نمایش داده می‌شود، Presentation Delay را بررسی کنید.

از جمله مواردی که می‌توان بررسی کرد:

• DOM بسیار بزرگ
• Update کردن تعداد زیادی Element در یک Interaction
• Style Calculation پرهزینه
• Layoutهای پیچیده
• Render کردن حجم زیادی HTML با JavaScript

راهنمای رسمی web.dev نیز کاهش هزینه Rendering و کنترل اندازه DOM را از مسیرهای بهبود INP می‌داند. (web.dev)

۶. برای پردازش‌های سنگین از Main Thread فاصله بگیرید

بعضی محاسبات CPU-heavy الزاماً نباید روی Main Thread انجام شوند.

در شرایط مناسب می‌توان بخشی از محاسبات را به Web Worker منتقل کرد تا رابط کاربری فرصت بیشتری برای پاسخ به کاربر داشته باشد.

این راهکار برای همه سایت‌ها ضروری نیست و نباید بدون تشخیص مشکل اجرا شود. اما در اپلیکیشن‌هایی که محاسبات سنگین سمت Client دارند، می‌تواند گزینه مهمی باشد.

۷. بازخورد بصری را زود نمایش دهید

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

لازم نیست تا پایان کل فرایند هیچ چیزی روی صفحه اتفاق نیفتد. می‌توان سریعاً وضعیت رابط کاربری را تغییر داد؛ برای مثال:

• دکمه وارد وضعیت Loading شود.
• پیام «در حال پردازش» نمایش داده شود.
• حالت انتخاب‌شده فوراً مشخص شود.
• Skeleton یا Indicator مناسب نمایش داده شود.

اما یک نکته فنی مهم وجود دارد: فقط تغییر دادن State کافی نیست. اگر بلافاصله بعد از آن یک کار Synchronous سنگین Main Thread را Block کند، مرورگر ممکن است فرصت Paint کردن همان State جدید را هم پیدا نکند.

بنابراین بازخورد سریع باید با مدیریت صحیح کار Main Thread همراه باشد.

یک سناریوی عملی برای پیدا کردن مشکل INP

فرض کنیم در یک فروشگاه اینترنتی، کلیک روی دکمه «افزودن به سبد خرید» تجربه کندی دارد.

در این مثال فرضی، DevTools نشان می‌دهد Interaction حدود ۷۰۰ میلی‌ثانیه طول کشیده است:

• ۲۵۰ میلی‌ثانیه Input Delay
• ۳۰۰ میلی‌ثانیه Processing Duration
• ۱۵۰ میلی‌ثانیه Presentation Delay

این اعداد آمار واقعی یک سایت نیستند؛ فقط برای نشان دادن روند عیب‌یابی استفاده شده‌اند.

در مرحله اول متوجه می‌شویم هنگام کلیک کاربر، یک Third-party Script در حال اجرای Task سنگین بوده و بخشی از Input Delay از آن می‌آید.

بعد Event Handler دکمه را بررسی می‌کنیم و می‌بینیم چند پردازش غیرضروری پیش از Update رابط کاربری انجام می‌شود. آن کارها از مسیر بحرانی Interaction خارج می‌شوند.

در نهایت مشخص می‌شود بعد از افزودن محصول، بخش بزرگی از DOM سبد خرید دوباره Render می‌شود. Update محدودتر DOM باعث کاهش Presentation Delay می‌شود.

نکته مهم این سناریو آن است که راه‌حل «INP را کم کن» نیست. باید زنجیره مشکل را پیدا کنیم:

Interaction کند → بخش ایجادکننده تأخیر → علت فنی → اصلاح هدفمند

همین رویکرد معمولاً از انجام مجموعه‌ای از Optimizationهای تصادفی مؤثرتر است.

آیا Lighthouse برای اندازه‌گیری INP کافی است؟

نه.

INP ذاتاً به Interactionهای واقعی در طول حضور کاربر در صفحه وابسته است. تست‌های Lab که فقط Loading صفحه را بررسی می‌کنند ممکن است نتوانند INP واقعی را اندازه بگیرند.

در چنین شرایطی Total Blocking Time یا TBT می‌تواند در محیط Lab به‌عنوان یک Proxy برای Responsiveness مفید باشد، اما TBT معادل INP نیست و نباید این دو را یکی دانست. web.dev نیز توصیه می‌کند برای هدف نهایی، INP بهینه شود و TBT صرفاً به‌عنوان معیار کمکی در Lab استفاده شود. (web.dev)

پس اگر Lighthouse نشان می‌دهد TBT خوب است، هنوز نمی‌توان نتیجه گرفت کاربران واقعی حتماً INP مناسبی دارند.

INP چه تأثیری روی SEO دارد؟

INP یکی از معیارهای Core Web Vitals است و Google اعلام کرده Core Web Vitals در Ranking Systems مورد استفاده قرار می‌گیرند. با این حال نباید از این جمله نتیجه گرفت که کاهش INP به‌صورت مستقیم یا تضمینی باعث افزایش رتبه یک صفحه خواهد شد. (Google Search Central)

در واقع رتبه‌بندی گوگل حاصل بررسی مجموعه‌ای از سیگنال‌ها و سیستم‌های مختلف است؛ بنابراین نمی‌توان یک مقدار خوب INP را به‌تنهایی معادل رتبه بهتر دانست.

Google نیز تأکید می‌کند که «Page Experience» یک Signal واحد و مستقل نیست و رسیدن به امتیاز خوب در گزارش Core Web Vitals تضمین نمی‌کند صفحه در رتبه‌های بالای نتایج قرار بگیرد.

ارتباط محتوا با Query، کیفیت پاسخ، اعتبار صفحه و سایر سیگنال‌ها همچنان اهمیت دارند.

بنابراین بهتر است INP را فقط به چشم یک «عدد برای SEO» نبینیم. اگر یک کاربر روی دکمه، منو یا فیلتر کلیک می‌کند و سایت دیر پاسخ می‌دهد، یک مشکل واقعی تجربه کاربری وجود دارد؛ حتی اگر Ranking را کاملاً از بحث کنار بگذاریم.

اشتباهات رایج هنگام بهبود INP

یکی از اشتباهات رایج این است که تمام تمرکز روی سرعت Load اولیه قرار بگیرد. سایتی ممکن است عملکرد مناسبی هنگام نمایش اولیه محتوا داشته باشد، اما بعد از Load شدن به دلیل اجرای JavaScript یا Interactionهای سنگین، پاسخ‌گویی ضعیفی داشته باشد.

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

همچنین نباید TBT را با INP یکی گرفت، یا فقط براساس یک تست روی کامپیوتر سریع نتیجه گرفت که سایت Responsiveness خوبی دارد.

از طرف دیگر، راه‌حل INP همیشه «حذف JavaScript» نیست. گاهی مشکل از Event Handler خاص، Rendering پرهزینه، DOM بزرگ یا نحوه زمان‌بندی کارها ایجاد می‌شود. تشخیص باید قبل از Optimization انجام شود.

جمع‌بندی

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

برای تجربه مناسب، هدف فعلی این است که INP در صدک ۷۵ کاربران به ۲۰۰ میلی‌ثانیه یا کمتر برسد. اما بهبود آن نباید با Optimizationهای تصادفی شروع شود.

ابتدا با Field Data مشخص کنید کدام صفحات مشکل دارند. سپس Interaction کند را پیدا کنید و بررسی کنید زمان بیشتر در Input Delay، Processing Duration یا Presentation Delay مصرف می‌شود. بعد سراغ علت فنی همان بخش بروید؛ از Long Task و JavaScript سنگین گرفته تا Event Handler پرهزینه یا Rendering پیچیده.

قاعده تصمیم ساده است:

برای بهبود INP، ابتدا کندترین Interaction واقعی را پیدا کنید؛ بعد کاری را بهینه کنید که واقعاً مانع نمایش سریع فریم بعدی می‌شود.