متریک INP (Interaction to Next Paint): راهنمای فنی نسل جدید پاسخدهی وب
برای یک مدیر بازاریابی فنی مانند «سارا»، درک تکامل متریکهای عملکرد وب، حیاتی است. تا همین اواخر، FID (First Input Delay) متریک اصلی Core Web Vitals برای سنجش «پاسخدهی» (Responsiveness) بود. اما FID یک نقص اساسی داشت: فقط «اولین» تعامل را میسنجید و فقط «تأخیر» ورودی را محاسبه میکرد، نه کل فرآیند را. اکنون، گوگل با معرفی متریک INP (Interaction to Next Paint)، این بازی را کاملاً تغییر داده است.
آنچه در این مقاله میخوانید
- متریک INP (Interaction to Next Paint): راهنمای فنی نسل جدید پاسخدهی وب
- متریک INP چیست؟ (Interaction to Next Paint)
- چرا INP جایگزین FID شد؟ (یک ارتقاء فنی ضروری)
- تشریح فنی: دلایل اصلی کندی متریک INP و Long Tasks
- ۱. مقصر اصلی: وظایف طولانی (Long Tasks)
- ۲. اجرای سنگین و ناکارآمد جاوا اسکریپت
- ۳. اندازه بزرگ DOM و پیچیدگی رندر
- INP در کنار سایر متریکهای Core Web Vitals
- فرآیند گام به گام بهینهسازی و رفع خطای INP
- گام اول: شناسایی تعاملات کند و Long Tasks
- گام دوم: شکستن Long Tasks (Yielding to the Main Thread)
- گام سوم: بهینهسازی اجرای جاوا اسکریپت (کاهش زمان پردازش)
- گام چهارم: بهینهسازی رندر و کاهش اندازه DOM
- نتیجهگیری: متریک INP، معیار جدید تعهد به UX
INP چیست؟ این فقط یک جایگزین ساده نیست؛ این یک بازنگری اساسی در نحوه سنجش تجربه کاربری است. درک عمیق متریک INP و نحوه بهینهسازی آن، ستون فقرات نسل بعدی بهینهسازی Core Web Vitals و یک عامل کلیدی در اثبات E-E-A-T فنی شماست. این راهنما به شما نشان میدهد که چگونه رفع خطای INP را به یک مزیت رقابتی تبدیل کنید.
متریک INP چیست؟ (Interaction to Next Paint)
INP چیست؟ (Interaction to Next Paint) یک متریک کاربر-محور است که «پاسخدهی کلی» (Overall Responsiveness) یک صفحه را اندازهگیری میکند. برخلاف FID، متریک INP کل تأخیر (Latency) یک تعامل کاربر را از لحظه وقوع (مانند کلیک، ضربه، یا تایپ) تا لحظهای که *بازخورد بصری بعدی* (Next Paint) روی صفحه نمایش داده میشود، محاسبه میکند.
یک «تعامل» (Interaction) کامل از سه بخش فنی تشکیل شده است و متریک INP هر سه را اندازهگیری میکند:
- تأخیر ورودی (Input Delay): مدت زمانی که مرورگر منتظر میماند تا بتواند به تعامل رسیدگی کند (معمولاً به دلیل مسدود بودن رشته اصلی یا Main Thread توسط کارهای دیگر).
- زمان پردازش (Processing Time): مدت زمان اجرای کدهای جاوا اسکریپت (Event Handlers) که منطق آن تعامل را اجرا میکنند (مثلاً کلیک روی دکمه «افزودن به سبد خرید»).
- تأخیر ارائه (Presentation Delay): مدت زمانی که مرورگر صرف محاسبه مجدد استایلها، چیدمان (Layout) و «نقاشی» (Paint) فریم بصری بعدی میکند.
متریک INP تمام تعاملات کاربر در طول بازدید از صفحه را مشاهده کرده و معمولاً بدترین یا نزدیک به بدترین تعامل (بهطور خاص، صدک ۷۵) را به عنوان امتیاز نهایی گزارش میدهد. بر اساس مستندات گوگل، آستانههای INP چیست به صورت زیر تعریف میشود:
- خوب (Good): زیر ۲۰۰ میلیثانیه
- نیاز به بهبود (Needs Improvement): بین ۲۰۰ تا ۵۰۰ میلیثانیه
- ضعیف (Poor): بالای ۵۰۰ میلیثانیه
هدف ما برای «بهینه سازی INP» رساندن این عدد به زیر ۲۰۰ میلیثانیه برای اکثر کاربران است.
چرا INP جایگزین FID شد؟ (یک ارتقاء فنی ضروری)
درک اینکه چرا متریک INP به عنوان جایگزین FID انتخاب شد، برای «سارا» بسیار مهم است، زیرا این نشاندهنده بلوغ گوگل در درک تجربه کاربری است. FID دو مشکل اساسی داشت:
- فقط «اولین» ورودی: FID فقط «اولین» تعامل کاربر را میسنجید. این یک تصویر ناقص بود. یک صفحه میتوانست FID عالی داشته باشد (چون در زمان اولین کلیک کاربر بیکار بوده)، اما منوهای ناوبری، فیلترهای محصولات، یا فرمهای آن به دلیل جاوا اسکریپت سنگین، به شدت کند و غیرپاسخگو باشند.
- فقط «تأخیر» ورودی: FID فقط بخش اول (Input Delay) را اندازهگیری میکرد و زمان پردازش و ارائه را نادیده میگرفت. کاربر اهمیتی نمیدهد که «تأخیر» کم بوده؛ اگر کلیک او ۲ ثانیه طول بکشد تا نتیجهای را نشان دهد، تجربه او «کند» بوده است.
متریک INP با سنجش *تمام* تعاملات و *کل* مدت زمان آنها (Interaction to Next Paint)، یک شاخص بسیار دقیقتر و واقعیتر از تجربه کاربری و کیفیت طراحی UI/UX ارائه میدهد.
تشریح فنی: دلایل اصلی کندی متریک INP و Long Tasks
رفع خطای INP تقریباً همیشه به یک چیز خلاصه میشود: بهینهسازی «رشته اصلی» (Main Thread) مرورگر. رشته اصلی یک منبع تکنخی (Single-threaded) است که باید جاوا اسکریپت را اجرا کند، به ورودی کاربر پاسخ دهد و صفحه را رندر کند. وقتی این رشته مسدود شود، متریک INP شما ضعیف خواهد بود.
۱. مقصر اصلی: وظایف طولانی (Long Tasks)
این مهمترین مفهومی است که در «بهینه سازی INP» باید بر آن مسلط شوید. Long Tasks (وظایف طولانی) مقصر شماره یک «تأخیر ورودی» (Input Delay) هستند.
تعریف فنی Long Task: یک Long Task هر قطعه کدی است که رشته اصلی مرورگر را برای *بیش از ۵۰ میلیثانیه* اشغال (مسدود) کند. این آستانه ۵۰ میلیثانیه از آنجا میآید که برای یک تجربه کاربری روان (۶۰ فریم بر ثانیه)، مرورگر فقط حدود ۱۶.۶ میلیثانیه برای هر فریم فرصت دارد. اگر کاری ۵۰ میلیثانیه طول بکشد، مرورگر چندین فریم را از دست داده است.
وقتی یک Long Task در حال اجراست (مثلاً پارس کردن یک فایل JS بزرگ، یا اجرای یک اسکریپت تحلیلی سنگین)، رشته اصلی *کاملاً مسدود* است. اگر کاربر در این مدت کلیک کند، مرورگر نمیتواند به آن پاسخ دهد تا زمانی که آن Long Task تمام شود. این دقیقاً همان «تأخیر ورودی» است که متریک INP اندازهگیری میکند.
۲. اجرای سنگین و ناکارآمد جاوا اسکریپت
این بخش مربوط به «زمان پردازش» (Processing Time) در متریک INP است. حتی اگر تأخیر ورودی کم باشد (رشته اصلی آزاد بوده)، کدی که در پاسخ به کلیک کاربر اجرا میشود، ممکن است خودش یک Long Task باشد.
مثالهای رایج عبارتند از:
- Event Handlerهای پیچیده: کدی که در `onclick` یا `onkeyup` اجرا میشود و کارهای زیادی انجام میدهد (مثلاً جستجو در یک آرایه بزرگ، اعتبارسنجی پیچیده فرم، یا ایجاد HTML زیاد به صورت داینامیک).
- اسکریپتهای شخص ثالث (Third-party): اسکریپتهای تبلیغات، تحلیل، یا چت که برای اجرای منطق خود، رشته اصلی را برای مدت طولانی اشغال میکنند.
- کدنویسی ناکارآمد: استفاده از حلقههای (Loop) سنگین یا الگوریتمهای ناکارآمد که پردازش را کند میکنند. اینجاست که اهمیت کدنویسی تمیز وردپرس (یا هر پلتفرم دیگری) مشخص میشود؛ تمها و پلاگینهای ضعیف، قاتل متریک INP هستند.
۳. اندازه بزرگ DOM و پیچیدگی رندر
این بخش «تأخیر ارائه» (Presentation Delay) را در متریک INP تحت تأثیر قرار میدهد. فرض کنید JS شما سریع اجرا شد و یک تغییر کوچک ایجاد کرد (مثلاً یک کلاس CSS اضافه کرد).
اگر صفحه شما یک DOM (Document Object Model) بسیار بزرگ و پیچیده داشته باشد (مثلاً بیش از ۲۰۰۰ نود یا عناصر تودرتوی عمیق)، مرورگر برای محاسبه مجدد استایلها و چیدمان (Layout) باید کار بسیار سنگینی انجام دهد. این فرآیند «رندر» میتواند به خودی خود دهها میلیثانیه طول بکشد و Interaction to Next Paint را به بالای مرز ۲۰۰ میلیثانیه برساند.
INP در کنار سایر متریکهای Core Web Vitals
متریک INP به تنهایی کار نمیکند. بهینه سازی INP باید در کنار دو متریک حیاتی دیگر انجام شود:
- متریک LCP (Largest Contentful Paint): سرعت بارگذاری درکشده را میسنجد.
- رفع خطای CLS (Cumulative Layout Shift): پایداری بصری را میسنجد.
یک سایت با INP عالی (پاسخدهی سریع) اما LCP ضعیف (بارگذاری کند)، همچنان تجربه کاربری بدی را ارائه میدهد.
فرآیند گام به گام بهینهسازی و رفع خطای INP
اکنون که میدانیم INP چیست و چه چیزی باعث کندی آن میشود (عمدتاً Long Tasks)، میتوانیم یک استراتژی عملی برای بهینه سازی INP تدوین کنیم. کاهش INP یک فرآیند سیستماتیک برای بازپسگیری رشته اصلی (Main Thread) است.
گام اول: شناسایی تعاملات کند و Long Tasks
اولین قدم در رفع خطای INP، یافتن مقصران است. شما نمیتوانید چیزی را که اندازهگیری نکردهاید، بهینه کنید.
- دادههای میدانی (Field Data): از گزارش Core Web Vitals در Google Search Console استفاده کنید تا ببینید کدام گروه از صفحات شما متریک INP ضعیفی دارند. ابزارهای RUM (Real User Monitoring) نیز میتوانند دقیقاً بگویند کدام تعاملات (مثلاً `button#add-to-cart`) کند هستند.
- ابزار آزمایشگاهی (Lab Tools – Chrome DevTools): این ابزار اصلی «سارا» برای دیباگ کردن متریک INP است.
- به تب Performance بروید.
- ضبط (Record) را شروع کنید، سپس با صفحه تعامل کنید (روی دکمهها کلیک کنید، منوها را باز کنید).
- ضبط را متوقف کنید. در نوار “Interactions”، تعاملات خود را ببینید. تعاملات طولانیتر از ۲۰۰ میلیثانیه هایلایت میشوند.
- در نوار “Main”، به دنبال بلاکهای قرمز رنگ (Long Tasks) بگردید. با کلیک بر روی آنها، در تب “Bottom-Up” میتوانید ببینید کدام فایل JS یا تابع (Function) باعث این وظیفه طولانی شده است.
گام دوم: شکستن Long Tasks (Yielding to the Main Thread)
این استراتژی اصلی برای کاهش INP است. به جای اجرای یک Long Task که ۲۰۰ میلیثانیه طول میکشد، آن را به ۴ وظیفه ۵۰ میلیثانیهای بشکنید. بین هر وظیفه، شما کنترل را به مرورگر «واگذار میکنید» (Yield). این کار به مرورگر اجازه میدهد تا نفس بکشد، به ورودیهای کاربر پاسخ دهد و فریمها را رندر کند.
تکنیک فنی: `setTimeout` و `isInputPending`
سادهترین راه برای «واگذاری» (Yield) استفاده از
setTimeout(myNextTask, 0)است. این کار به مرورگر میگوید: “این تابع را اجرا نکن، آن را در صف قرار بده تا *بعد* از اینکه کارهای مهمتری (مانند پاسخ به کلیک کاربر) را انجام دادی، اجرا کنی.”تکنیک پیشرفتهتر استفاده از
navigator.scheduling.isInputPending()است. شما میتوانید در حین اجرای یک حلقه طولانی، بررسی کنید که آیا کاربر در حال تلاش برای تعامل است یا خیر. اگر بود، میتوانید کار را متوقف کرده و به ورودی کاربر پاسخ دهید. این دقیقاً همان چیزی است که تیم Chrome برای بهینه سازی INP توصیه میکند.
گام سوم: بهینهسازی اجرای جاوا اسکریپت (کاهش زمان پردازش)
شکستن وظایف عالی است، اما سریعتر کردن خود وظایف حتی بهتر است. این بخش از بهینه سازی INP بر روی کارایی کد تمرکز دارد.
- Code-Splitting: باندل JS خود را تقسیم کنید. کاربر نباید در صفحه اصلی، کدهای مربوط به صفحه پرداخت را دانلود و پارس کند. بارگذاری JS کمتر به معنای Long Tasks کمتر در زمان بارگذاری است.
- Defer/Async: تمام اسکریپتهای غیرضروری (مانند چت، آنالیتیکس) را با
deferبارگذاری کنید تا رشته اصلی در زمان بارگذاری اولیه مسدود نشود. - بهینهسازی Event Handlers:
- Debounce/Throttle: برای رویدادهایی که مکرراً اجرا میشوند (مانKد `scroll`, `resize`, `keyup`)، از این تکنیکها برای محدود کردن تعداد دفعات اجرای تابع استفاده کنید.
- Event Delegation: به جای افزودن ۱۰۰۰ شنونده رویداد (Event Listener) به ۱۰۰۰ آیتم در یک لیست، *یک* شنونده به لیست والد (
<ul>) اضافه کنید.
گام چهارم: بهینهسازی رندر و کاهش اندازه DOM
در نهایت، برای کاهش INP، باید «تأخیر ارائه» (Presentation Delay) را کاهش دهیم.
- حفظ DOM کوچک: هدف خود را زیر ۱۵۰۰ نود (Node) در کل صفحه قرار دهید. DOMهای کوچکتر به معنای محاسبات استایل و چیدمان سریعتر هستند. از صفحهسازهای (Page Builders) سنگین که هزاران `div` تودرتو ایجاد میکنند، دوری کنید.
- اجتناب از Layout Thrashing: در جاوا اسکریپت، از خواندن و نوشتن متوالی ویژگیهای DOM در یک حلقه خودداری کنید (مثلاً خواندن `element.offsetWidth` و سپس تنظیم `element.style.width`). این کار مرورگر را مجبور به محاسبات مجدد مکرر میکند.
- استفاده از CSS Containment: از ویژگی `contain` در CSS استفاده کنید تا به مرورگر بگویید کدام بخشهای صفحه مستقل هستند و تغییر در آنها نیازی به محاسبه مجدد کل صفحه ندارد.
نتیجهگیری: متریک INP، معیار جدید تعهد به UX
برای «سارا»، متریک INP (Interaction to Next Paint) فقط یک عدد دیگر در GSC نیست؛ این یک تغییر پارادایم است. این جایگزین FID شده است تا به طور دقیقتری تعهد ما به یک طراحی UI/UX واقعاً پاسخگو را بسنجد. INP چیست؟ این صدای کاربر است که میپرسد: «وقتی کلیک میکنم، آیا به من گوش میدهی؟»
رفع خطای INP یک فرآیند پیچیده است که نیاز به تسلط بر جاوا اسکریپت، درک عمیق نحوه کار رشته اصلی مرورگر، و شناسایی دقیق Long Tasks دارد. با پیروی از چکلیست بهینه سازی INP—شناسایی، شکستن وظایف، و بهینهسازی کد—شما میتوانید اطمینان حاصل کنید که سایت شما نه تنها سریع بارگذاری میشود (LCP/CLS)، بلکه در هر تعامل، سریع و روان *احساس* میشود.