Interaction to Next Paint (INP) چیست؟ — راهنمای کامل، فنی و گام‌به‌گام برای بهبود تأخیر تعامل در وردپرس و وب

آخرین بروزرسانی در تاریخ آگوست 3, 2026 توسط PersiaWebAdmin

تا حالا پیش اومده که روی دکمه‌ای کلیک کنید، اما هیچ اتفاقی نیفته؟ یا توی یک منوی همبرگری ضربه بزنید، اما منو با یک مکث آزاردهنده باز بشه؟ این تأخیر کوچک که مستقیماً حس «کُندی» و «عدم واکنش‌پذیری» سایت رو به کاربر منتقل می‌کنه، دقیقاً همون چیزیه که گوگل با معیار جدید Interaction to Next Paint (INP) اندازه‌گیری می‌کنه. INP از مارس ۲۰۲۴ جایگزین FID (اولین تأخیر ورودی) شد و حالا یکی از سه معیار اصلی Core Web Vitals برای سنجش تجربه کاربری و رتبه‌بندی در نتایج جستجوه. این معیار دقیقاً میزان پاسخگویی بصری صفحه به تعاملات کاربر رو در کل چرخه حیات صفحه نشون میده، نه فقط اولین تعامل.

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

معیار Interaction to Next Paint (INP) چیست و چطور آن را بهبود دهیم

فهرست مطالب

  1. INP دقیقاً چیست و چرا FID را کنار گذاشتیم؟
  2. تفاوت INP با FID و TBT — درک درست معیار
  3. یک تعامل چطور اندازه‌گیری می‌شود؟ (Input Delay + Processing Time + Presentation Delay)
  4. آستانه‌های INP: چه نمره‌ای خوب است؟
  5. مهم‌ترین دلایل INP بالا (با مثال‌های واقعی)
  6. ابزارهای اندازه‌گیری INP (آزمایشگاهی و میدانی)
  7. راه‌حل‌های عملی برای بهبود INP — گام‌به‌گام
  • ۷.۱. کاهش JavaScript اجرا شده در هر تعامل
  • ۷.۲. شکستن وظایف طولانی (Long Tasks) و اصول Total Blocking Time
  • ۷.۳. استفاده از requestAnimationFrame و requestIdleCallback
  • ۷.۴. انتقال کار به Web Workers
  • ۷.۵. بهینه‌سازی رندرینگ و جلوگیری از layout thrashing
  • ۷.۶. بهینه‌سازی کتابخانه‌های شخص ثالث و اسکریپت‌های بازاریابی
  • ۷.۷. مدیریت رویدادهای ورودی (Input Events): debounce, throttle, passive listeners
  1. راهکارهای پیشرفته برای توسعه‌دهندگان
  • ۸.۱. استفاده از scheduler.yield() و Continuation Passing
  • ۸.۲. آنالیز ریشه‌ای با Long Animation Frames (LoAFs)
  • ۸.۳. تکنیک‌های ایزوله‌سازی تعامل (Isolating Interaction)
  1. INP در وردپرس — چالش‌ها، افزونه‌ها و راهکارهای عملی
  • ۹.۱. چرا وردپرس مستعد INP بالاست؟
  • ۹.۲. بهینه‌سازی افزونه‌ها و پوسته‌ها
  • ۹.۳. استفاده از کش و بارگذاری غیرهمگام
  • ۹.۴. قطعه‌کدهای مفید برای کاهش INP در وردپرس
  1. پایش و نظارت دائمی INP با ابزارهای رایگان
  2. جمع‌بندی و چک‌لیست نهایی طلایی

۱. INP دقیقاً چیست و چرا FID را کنار گذاشتیم؟

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

گوگل قبلاً از FID (First Input Delay) استفاده می‌کرد که فقط تأخیر اولین تعامل کاربر رو اندازه می‌گرفت و فقط بخش تأخیر ورودی (Input Delay) رو می‌سنجید. اما این تصویر کاملی از پاسخگویی کلی صفحه نبود. کاربران معمولاً چندین بار با صفحه تعامل دارن (کلیک روی دکمه‌ها، باز کردن آکاردئون، انتخاب از منو و غیره)، و بدترین تأخیرها اغلب مربوط به تعاملات بعدی‌ای هست که بعد از بارگذاری کامل صفحه و در حین اجرای اسکریپت‌های طولانی رخ میدن. FID به راحتی می‌تونست یک سایت با پردازش‌های سنگین پس از بارگذاری را «خوب» نشان دهد، در حالی که کاربر پس از چند ثانیه تعامل با کندی مواجه می‌شد.

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

چرا این معیار برای سئو و تجربه کاربری حیاتی است؟

  • کاربری که روی «افزودن به سبد خرید» کلیک می‌کنه و ۳۰۰ میلی‌ثانیه معطل می‌شه، احتمالاً خرید رو تکمیل نمی‌کنه. تحقیقات نشان می‌دهد حتی ۱۰۰ میلی‌ثانیه تأخیر اضافی می‌تواند نرخ تبدیل را تا ۷٪ کاهش دهد.
  • یک منوی موبایلی که با تأخیر باز بشه، نرخ پرش رو بالا می‌بره و مستقیماً روی تعامل کاربر تأثیر منفی دارد.
  • گوگل INP رو به‌عنوان یک سیگنال رتبه‌بندی در نظر می‌گیره؛ پس نمره بد INP می‌تونه رتبه سایت رو حتی با محتوای خوب کاهش بده. بر اساس اعلام گوگل، Core Web Vitals از جمله INP بخشی از “Page Experience” است که روی رتبه‌بندی اثر می‌گذارد.

پیشنهاد مطالعه : Cumulative Layout Shift (CLS) چیست؟

۲. تفاوت INP با FID و TBT — درک درست معیار

برای اینکه اشتباه نکنیم، این سه مفهوم رو دقیق مقایسه کنیم:

  • FID (First Input Delay): فقط اولین تعامل کاربر را می‌سنجید و تنها تاخیر بین دریافت رویداد (Event) و شروع اجرای callback را اندازه می‌گرفت. (اکنون منسوخ شده است.)
  • TBT (Total Blocking Time): مجموع زمان‌هایی که در حین بارگذاری صفحه، نخ اصلی (Main Thread) برای بیش از ۵۰ میلی‌ثانیه مسدود شده. یک معیار آزمایشگاهی (Lab) و غیرمستقیم برای پاسخگویی. TBT تقریباً نشان‌دهنده همان مدت زمانی است که مرورگر نمی‌تواند به ورودی‌های کاربر پاسخ دهد، ولی فقط در فاز بارگذاری اولیه.
  • INP: یک معیار میدانی (Field) که پاسخگویی کلی صفحه رو در طول جلسه می‌سنجه و شامل هر سه مرحله تأخیر (تأخیر ورودی، زمان پردازش، تأخیر ارائه) می‌شود. برخلاف FID که فقط یک تعامل را در نظر می‌گرفت، INP تمام تعاملات را رصد کرده و بدترین را گزارش می‌کند (در واقع صدک ۹۸ تعاملات).

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


۳. یک تعامل چطور اندازه‌گیری می‌شود؟ (Input Delay + Processing Time + Presentation Delay)

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

  1. Input Delay (تأخیر ورودی): فاصله زمانی بین لحظه‌ای که کاربر تعامل رو آغاز می‌کنه (مثلاً کلیک) تا زمانی که callback مربوط به رویداد شروع به اجرا می‌کنه. این تأخیر وقتی اتفاق می‌افته که نخ اصلی مشغول اجرای وظایف دیگه‌ست و نمی‌تونه بلافاصله رویداد رو پردازش کنه. به عنوان مثال، اگر یک حلقه طولانی جاوااسکریپت در حال اجرا باشد، کلیک کاربر در صف می‌ماند تا نخ اصلی آزاد شود.
  2. Processing Time (زمان پردازش): مدت زمانی که طول می‌کشه تا event handlerها اجرا بشن و کارشون رو انجام بدن (مثل اعتبارسنجی فرم، محاسبات، به‌روزرسانی state). این بخش مستقیماً تحت کنترل توسعه‌دهنده است و می‌توان با بهینه‌سازی کد آن را کاهش داد.
  3. Presentation Delay (تأخیر نمایش): زمانی که طول می‌کشه تا مرورگر تغییرات ایجادشده در DOM را به پیکسل‌های صفحه تبدیل کنه و فریم جدید رو نمایش بده. این شامل محاسبات استایل (Recalculate Style)، چیدمان (Layout)، رنگ‌آمیزی (Paint) و ترکیب (Composite) می‌شود. گاهی حتی اگر پردازش سریع باشد، یک درخت DOM پیچیده یا تغییرات layout گسترده می‌تواند Presentation Delay را بالا ببرد.

مدت زمان کل تعامل = تأخیر ورودی + زمان پردازش + تأخیر نمایش

هدف ما اینه که این مجموع، تا جای ممکن کمتر از ۲۰۰ میلی‌ثانیه باشه (و قطعاً زیر ۵۰۰ میلی‌ثانیه). نکته‌ای که خیلی از توسعه‌دهنده‌ها فراموش می‌کنن اینه که حتی اگر callback خیلی سریع باشه، اگر نخ اصلی درگیر یک task طولانی باشه، input delay می‌تونه بسیار زیاد بشه. همچنین کدی که باعث layout thrashing می‌شود، Presentation Delay را به شدت بالا می‌برد.

پیشنهاد مطالعه : FCP چیست؟

۴. آستانه‌های INP: چه نمره‌ای خوب است؟

گوگل سه سطح برای INP تعریف کرده که بر اساس داده‌های واقعی کاربران (CrUX) سنجیده می‌شود:

وضعیتINP (میلی‌ثانیه)
خوب (Good)≤ ۲۰۰ ms
نیاز به بهبود (Needs Improvement)> ۲۰۰ و ≤ ۵۰۰ ms
ضعیف (Poor)> ۵۰۰ ms

هدف هر سایتی باید INP زیر ۲۰۰ میلی‌ثانیه برای ۷۵٪ بارگذاری‌ها باشه (در CrUX). این یعنی در ۷۵ درصد از موارد، تأخیر تعاملات کاربران کمتر از ۲۰۰ میلی‌ثانیه باشد. اگر سایت شما در وضعیت Poor قرار داره، نه تنها تجربه کاربری افتضاحی ارائه می‌دهید، بلکه گوگل به عنوان سیگنال منفی رتبه‌بندی در نظر می‌گیرد. پیشنهاد می‌کنم هدف اولیه را رساندن INP زیر ۵۰۰ میلی‌ثانیه و سپس بهبود تدریجی به زیر ۲۰۰ میلی‌ثانیه قرار دهید.


۵. مهم‌ترین دلایل INP بالا (با مثال‌های واقعی)

INP بالا معمولاً یک قاتل خاموشه و اغلب ریشه در کدهای بهینه‌نشده و منابع سنگین دارد. بیایید رایج‌ترین دلایل را با سناریوهای واقعی بررسی کنیم:

  1. وظایف طولانی (Long Tasks): هر وظیفه‌ای که بیش از ۵۰ میلی‌ثانیه نخ اصلی رو اشغال کنه، مستقیماً Input Delay را افزایش می‌دهد. مثال: یک اسکریپت تحلیلی که همزمان با کلیک کاربر داده‌های حجیم را پردازش می‌کند.
  2. اسکریپت‌های شخص ثالث سنگین: ابزارهای چت آنلاین، تبلیغات، اسکریپت‌های آنالیتیکس و ویدجت‌های شبکه‌های اجتماعی که بدون در نظر گرفتن اولویت، نخ اصلی را اشغال می‌کنند. برای نمونه یک ویدجت چت که با هر کلیک کاربر فراخوانی‌های متعددی انجام می‌دهد.
  3. پردازش‌های سنگین پس از تعامل: کلیک روی دکمه‌ای که یک لیست ۱۰۰۰ تایی را فیلتر می‌کند، یا یک نقشه را مجدداً رندر می‌کند، بدون بهینه‌سازی و قطعه‌قطعه کردن کارها.
  4. واکنش‌های زنجیره‌ای در DOM (Layout Thrashing): تغییرات مکرر در style و سپس خواندن مشخصات layout (مانند offsetWidth) باعث محاسبات اجباری و پیاپی layout می‌شود که Presentation Delay را به شدت بالا می‌برد.
  5. عدم تفکیک اولویت‌ها: کدی که کارهای غیرضروری مثل ارسال داده‌های تحلیلی یا پیش‌بارگذاری محتوا را بلافاصله پس از تعامل انجام می‌دهد، به جای این‌که آن‌ها را به زمان بیکاری (Idle) موکول کند.
  6. در وردپرس: افزونه‌های زیاد که jQuery، فایل‌های CSS و JS حجیم را در همه صفحات بارگذاری می‌کنند، بدون در نظر گرفتن نیاز واقعی. همچنین استفاده از تم‌های سنگین با انیمیشن‌های پیچیده.

پیشنهاد مطالعه : CDN چیست و چه تاثیری بر سرعت و سئو سایت دارد؟

۶. ابزارهای اندازه‌گیری INP (آزمایشگاهی و میدانی)

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

ابزارهای میدانی (داده‌های واقعی کاربران):

  • Google Search Console > Core Web Vitals: مستقیم INP صفحات مشکل‌دار رو بر اساس داده‌های CrUX نشون میده و می‌توانید URLهای با وضعیت Poor را فیلتر کنید.
  • CrUX Dashboard: داشبورد رایگان گوگل با داده‌های CrUX که روند تغییرات INP را در طول زمان نمایش می‌دهد.
  • Web Vitals Extension (Chrome): هنگام مرور سایت، نمره INP و سایر معیارها را به‌صورت زنده نشان می‌دهد.

ابزارهای آزمایشگاهی (Lab):

  • Lighthouse (در Chrome DevTools): INP رو مستقیماً نشون نمیده، اما TBT و هشدارهای «Reduce JavaScript execution time» و «Avoid long main-thread tasks» رو مشخص می‌کنه که همگی در کاهش INP مؤثرند.
  • Chrome DevTools Performance Panel: می‌تونید تعاملات رو ضبط کنید و زنجیره‌های طولانی وظایف رو ببینید. همچنین بخش «Summary» زمان ورودی، پردازش و رندر رو جداگانه نمایش می‌دهد. با کلیک روی هر تعامل می‌توانید دقیقاً علت تأخیر را شناسایی کنید.
  • WebPageTest: بخش «Interaction» تست‌های سفارشی با قابلیت اندازه‌گیری INP دارد.
  • DebugBear و SpeedCurve: سرویس‌های پیشرفته با قابلیت تست و رصد مداوم INP.

نکته طلایی: از Chrome DevTools برای شبیه‌سازی CPU 4x slowdown استفاده کنید تا تعاملات در دستگاه‌های ضعیف‌تر (که کاربران زیادی دارند) بهتر دیده بشن و مشکلات پنهان آشکار شوند.


۷. راه‌حل‌های عملی برای بهبود INP — گام‌به‌گام

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

۷.۱. کاهش JavaScript اجرا شده در هر تعامل

هدف: کم کردن حجم کدی که بلافاصله پس از تعامل اجرا می‌شود. هرچه event handlerها سبک‌تر باشند، Processing Time کاهش می‌یابد.

  • حذف کدهای غیرضروری در event handlerها: هر تابعی که در کلیک اجرا می‌شود را بررسی کنید. کارهایی مثل ارسال آنالیتیکس، آپدیت UI غیربصری و پیش‌بارگذاری داده‌ها را می‌توانید به تعویق بیندازید. فقط کدی که برای بازخورد بصری فوری لازم است را بلافاصله اجرا کنید.
  • استفاده از setTimeout با تأخیر صفر یا scheduler.postTask برای اولویت‌بندی: کارهای فوری را انجام دهید و بقیه را به عنوان وظایف با اولویت پایین زمان‌بندی کنید. (در ادامه بیشتر توضیح می‌دهیم)
  • کاهش DOM manipulation غیرضروری: تغییرات DOM را دسته‌بندی کنید و از DocumentFragment برای اضافه کردن چندین گره به صورت یکجا استفاده کنید.

۷.۲. شکستن وظایف طولانی (Long Tasks) و اصول Total Blocking Time

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

مثال کلاسیک: یک حلقه ۱۰۰۰ تایی که عناصر DOM را به‌روز می‌کند. به جای اجرای کل حلقه، آن را به بخش‌های ۵۰ تایی تقسیم می‌کنیم و بین هر بخش به مرورگر فرصت می‌دهیم تا رویدادهای کاربر را پردازش کند:

function processLargeArray(array) {
  const chunkSize = 50;
  let index = 0;
  function doChunk() {
    const start = performance.now();
    while (index < array.length && (performance.now() - start) < 50) {
      // پردازش یک آیتم
      index++;
    }
    if (index < array.length) {
      // زمان رو به مرورگر می‌دهیم
      requestAnimationFrame(doChunk);
    }
  }
  requestAnimationFrame(doChunk);
}

اما روش مدرن‌تر، استفاده از scheduler.yield() (در مرورگرهای کرومیوم) یا polyfill آن است:

async function processInChunks(array) {
  for (let i = 0; i < array.length; i++) {
    // پردازش آیتم
    if (i % 50 === 0) {
      await scheduler.yield(); // به مرورگر فرصت تنفس می‌دهد
    }
  }
}

۷.۳. استفاده از requestAnimationFrame و requestIdleCallback

  • requestAnimationFrame (rAF): کدهای بصری و مرتبط با انیمیشن را درون rAF قرار دهید تا با نرخ تازه‌سازی مرورگر هماهنگ شود و از اجرای کارهای غیرضروری در هر فریم جلوگیری کند.
  • requestIdleCallback (rIC): کارهای غیرفوری (مثل ارسال آنالیتیکس، پیش‌بارگذاری داده‌های ثانویه، پاکسازی حافظه) را در زمان بیکاری مرورگر اجرا کنید.
requestIdleCallback(() => {
  sendAnalyticsData();
}, { timeout: 2000 });

توجه: rIC در همه مرورگرها پشتیبانی نمی‌شود (مانند سافاری)، اما می‌توانید از polyfill یا scheduler.postTask با اولویت background استفاده کنید.

۷.۴. انتقال کار به Web Workers

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

// main.js
const worker = new Worker('heavy-task.js');
worker.postMessage(data);
worker.onmessage = (e) => {
  // نتیجه را دریافت و DOM را به‌روز کنید
};

// heavy-task.js
onmessage = (e) => {
  const result = complexCalculation(e.data);
  postMessage(result);
};

پیشنهاد مطالعه : سوشیال سیگنال چیست و چگونه بر سئو تأثیر می‌گذارد؟

۷.۵. بهینه‌سازی رندرینگ و جلوگیری از layout thrashing

Layout thrashing یعنی خواندن و نوشتن مکرر مشخصات DOM که باعث محاسبات اجباری layout می‌شود. این کار Presentation Delay را به شدت بالا می‌برد. راهکار: خواندن‌ها را یکجا انجام دهید، سپس نوشتن‌ها را یکجا.

کد بد (thrashing):

elements.forEach(el => {
  el.style.width = el.offsetWidth + 10 + 'px'; // هر بار خواندن offsetWidth باعث layout می‌شود
});

کد خوب (جداسازی خواندن و نوشتن):

const widths = elements.map(el => el.offsetWidth); // خواندن یکجا
widths.forEach((w, i) => {
  elements[i].style.width = w + 10 + 'px'; // نوشتن یکجا
});

همچنین از CSS containment (contain: layout) برای ایزوله کردن بخش‌های صفحه استفاده کنید تا تغییرات در یک بخش، روی کل صفحه تأثیر نگذارد.

۷.۶. بهینه‌سازی کتابخانه‌های شخص ثالث و اسکریپت‌های بازاریابی

اسکریپت‌های شخص ثالث بزرگترین عامل خارج از کنترل ما برای INP بالا هستند. راهکارهای زیر را اعمال کنید:

  • اسکریپت‌های غیرضروری را حذف کنید: ابزار چت، تگ‌های بازاریابی که فقط گاهی استفاده می‌شوند را با delay یا بر اساس تعامل کاربر (مثلاً پس از اسکرول) بارگذاری کنید.
  • اسکریپت‌ها را با defer یا async بارگذاری کنید: <script src="third-party.js" defer></script> باعث می‌شود اجرای آن‌ها تا بعد از پارس HTML به تعویق بیفتد.
  • استفاده از Fetch Priority: با fetchpriority="low" برای اسکریپت‌های کم‌اهمیت، رقابت بر سر پهنای باند و نخ اصلی را کاهش دهید.
  • پایش کنید: با استفاده از Coverage tab در Chrome DevTools، ببینید چه مقدار از کدهای third-party واقعاً اجرا می‌شود. گاهی تا ۸۰٪ کد یک کتابخانه بلااستفاده است.

۷.۷. مدیریت رویدادهای ورودی (Input Events): debounce, throttle, passive listeners

برای رویدادهای پُرتکرار مانند scroll، resize، mousemove (که می‌توانند باعث صف شدن رویدادها شوند) از تکنیک‌های زیر استفاده کنید:

  • passive event listeners: با تنظیم { passive: true } به مرورگر می‌گویید که preventDefault() فراخوانی نمی‌شود، بنابراین مرورگر می‌تواند بدون صبر کردن برای اجرای JavaScript، اسکرول را ادامه دهد. این کار Input Delay را کم می‌کند.
    window.addEventListener('scroll', handleScroll, { passive: true });
  • debounce یا throttle: تعداد اجرای callback را محدود کنید. اما توجه: برای رویدادهایی که باید فوراً پاسخ دهند (مثل کلیک)، از throttle استفاده نکنید؛ فقط کارهای پس‌زمینه ناشی از رویداد را throttling کنید.

۸. راهکارهای پیشرفته برای توسعه‌دهندگان

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

۸.۱. استفاده از scheduler.yield() و Continuation Passing

API جدید scheduler.yield() به شما اجازه می‌دهد کنترل نخ اصلی را در میانه یک وظیفه به مرورگر برگردانید تا رویدادهای کاربر پردازش شوند. این بهترین روش برای شکستن کارهای طولانی در تعاملات است.

async function handleClick() {
  // مرحله ۱: آماده‌سازی سریع و بازخورد فوری (UI feedback)
  updateButtonState();

  await scheduler.yield(); // به مرورگر فرصت دهید UI را نمایش دهد

  // مرحله ۲: کار سنگین (مثلاً fetch داده‌ها)
  const data = await fetchData();

  // مرحله ۳: به‌روزرسانی DOM با داده‌های جدید
  renderResults(data);
}

با این کار کاربر بلافاصله بازخورد بصری می‌گیرد و سپس داده‌ها بارگذاری می‌شوند. Presentation Delay به حداقل می‌رسد.

۸.۲. آنالیز ریشه‌ای با Long Animation Frames (LoAFs)

Long Animation Frames یک API جدید است که دقیقاً مشخص می‌کند کدام اسکریپت‌ها در یک فریم طولانی (بیش از ۵۰ میلی‌ثانیه) اجرا شده‌اند. با PerformanceObserver می‌توانید این داده‌ها را جمع‌آوری کنید:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Long Animation Frame:', entry);
    // entry.scripts آرایه‌ای از اسکریپت‌های دخیل با زمان اجرا
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

با تحلیل این خروجی می‌توانید دقیقاً مقصر اصلی INP بالا را پیدا کنید، حتی اگر یک اسکریپت third-party باشد.

۸.۳. تکنیک‌های ایزوله‌سازی تعامل (Isolating Interaction)

برای یک تعامل خاص (مثلاً باز شدن منو)، می‌توانید با استفاده از CSS containment، مرورگر را محدود کنید تا فقط آن بخش را رندر کند و از محاسبات کل صفحه جلوگیری کنید:

.menu {
  contain: layout style;
  will-change: transform;
}

این کار باعث می‌شود Presentation Delay کاهش یابد. همچنین می‌توانید آن بخش را به یک لایه مجزا (با will-change) منتقل کنید تا در GPU کامپوزیت شود.


۹. INP در وردپرس — چالش‌ها، افزونه‌ها و راهکارهای عملی

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

۹.۱. چرا وردپرس مستعد INP بالاست؟

  • انباشته شدن افزونه‌ها و بارگذاری jQuery و اسکریپت‌های متعدد در هر صفحه (حتی صفحاتی که نیازی ندارند).
  • بسیاری از افزونه‌ها و پوسته‌ها از jQuery و کدهای همگام قدیمی استفاده می‌کنند که باعث long task می‌شود.
  • عدم بارگذاری شرطی اسکریپت‌ها؛ یک اسلایدر در صفحه اصلی ممکن است در صفحه تماس با ما هم بارگذاری شود.
  • فقدان بهینه‌سازی‌های مدرن مانند defer/async روی اسکریپت‌های ثبت‌شده در WordPress.

۹.۲. بهینه‌سازی افزونه‌ها و پوسته‌ها

  • با افزونه Query Monitor لیست اسکریپت‌ها و استایل‌های بارگذاری‌شده در هر صفحه را بررسی کنید و موارد غیرضروری را شناسایی کنید.
  • با استفاده از wp_dequeue_script و wp_dequeue_style، اسکریپت‌ها را فقط در صفحات مورد نیاز بارگذاری کنید. (مثلاً اسکریپت فرم تماس فقط در صفحه تماس).
  • پوسته‌هایی که از Vanilla JS به‌جای jQuery استفاده می‌کنند (مانند GeneratePress، Astra سبک) معمولاً INP پایین‌تری دارند.

۹.۳. استفاده از کش و بارگذاری غیرهمگام

  • WP Rocket: قابلیت «Delay JavaScript Execution» می‌تواند اسکریپت‌های غیرضروری (مثل آنالیتیکس، چت) را تا زمان تعامل کاربر (کلیک، حرکت موس) به تأخیر بیندازد و مستقیماً INP را بهبود دهد.
  • Perfmatters: امکان غیرفعال کردن اسکریپت‌ها در صفحات خاص، تعویق بارگذاری، و مدیریت اسکریپت‌های third-party.
  • Flying Scripts: اسکریپت‌ها را بر اساس رویداد کاربر (مانند اسکرول، کلیک) بارگذاری می‌کند.

۹.۴. قطعه‌کدهای مفید برای کاهش INP در وردپرس

این کدها را می‌توانید در فایل functions.php تم فرزند اضافه کنید:

  • حذف jQuery Migrate (اگر افزونه‌ها نیاز ندارند):
add_action('wp_default_scripts', function($scripts) {
    if (!empty($scripts->registered['jquery'])) {
        $scripts->registered['jquery']->deps = array_diff($scripts->registered['jquery']->deps, ['jquery-migrate']);
    }
});
  • بارگذاری اسکریپت‌ها با defer:
function add_defer_to_scripts($tag, $handle) {
    if ('my-script' === $handle) {
        return str_replace(' src', ' defer="defer" src', $tag);
    }
    return $tag;
}
add_filter('script_loader_tag', 'add_defer_to_scripts', 10, 2);
  • حذف ایموجی‌های پیش‌فرض وردپرس (در صورت عدم نیاز):
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');

پیشنهاد مطالعه : سئو سایت چیست ؟

۱۰. پایش و نظارت دائمی INP با ابزارهای رایگان

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

  • Google Search Console: مهم‌ترین جا برای دیدن INP واقعی. هر دو هفته یک‌بار گزارش Core Web Vitals را بررسی کنید و صفحات با وضعیت Poor را فوراً رفع کنید.
  • DebugBear: امکان رصد ۲۴/۷ و هشدار برای INP به همراه waterfall و filmstrip از تعاملات.
  • Web Vitals Library: می‌توانید INP را به Google Analytics 4 ارسال کنید تا داده‌های واقعی کاربران خود را داشته باشید:
import {onINP} from 'web-vitals';
onINP((metric) => {
  // ارسال به GA4 یا ابزار تحلیلی دیگر
  gtag('event', 'INP', {
    value: metric.value,
    page: location.pathname,
  });
});
  • در وردپرس: از Site Kit by Google برای دیدن داده‌های PageSpeed Insights و Search Console داخل پیشخوان استفاده کنید.

۱۱. جمع‌بندی و چک‌لیست نهایی طلایی

INP بالاترین «آزار» کاربران رو نشان می‌دهد، پس باید جدی گرفته شود. با اجرای این چک‌لیست می‌توانید INP سایت خود را به زیر ۲۰۰ میلی‌ثانیه برسانید و تجربه کاربری را متحول کنید:

✅ اسکریپت‌های شخص ثالث غیرضروری را حذف یا به تعویق بیندازید.
✅ وظایف طولانی (بیش از ۵۰ms) را با scheduler.yield() یا قطعه‌قطعه کردن بشکنید.
✅ کارهای سنگین را به Web Worker منتقل کنید.
✅ از requestAnimationFrame برای بروزرسانی‌های بصری و requestIdleCallback برای کارهای پس‌زمینه استفاده کنید.
✅ event handler ها را سبک کنید و بازخورد اولیه (UI feedback) را فوراً نشان دهید.
✅ از passive: true برای رویدادهای scroll/touch استفاده کنید.
✅ از layout thrashing پرهیز کنید و تغییرات DOM را بهینه کنید (خواندن یکجا، نوشتن یکجا).
✅ در وردپرس، افزونه‌های کش و بهینه‌سازی (WP Rocket, Perfmatters) را با تنظیمات Delay JS به‌کار ببرید.
✅ داده‌های INP را از طریق Search Console و RUM پایش مستمر کنید.
✅ هنگام طراحی، همواره از خود بپرسید: «آیا کاربر در کمتر از ۲۰۰ میلی‌ثانیه بعد از کلیک، نتیجه را می‌بیند؟»

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

پرشیا وب

اشتراک بگذارید :

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

از سال ۲۰۱۳ فعالیت حرفه‌ای خود را در حوزه طراحی وب آغاز کرد و تاکنون بیش از 300 پروژه طراحی سایت و بهینه‌سازی سئو در صنایع مختلف اجرا کرده است. تجربه عملی او در پروژه‌های واقعی، به ویژه در کسب‌وکارهای ایرانی، موجب شده است بتواند راهکارهایی کاملاً کاربردی و بومی برای رشد آنلاین ارائه دهد.

طراحی و توسعه وب‌سایت‌های شرکتی، فروشگاهی و شخصی با تمرکز بر سرعت، امنیت و تجربه کاربری (UX)
استراتژی‌های سئو فنی، on-page و off-page برای افزایش رتبه در نتایج گوگل
تحلیل رقبا، تحقیق کلمات کلیدی و اجرای کمپین‌های تولید محتوا
مشاوره و اجرای رپورتاژ آگهی و لینک‌سازی هدفمند برای بهبود اعتبار دامنه
طراحی کمپین‌های دیجیتال مارکتینگ یکپارچه برای برندهای نوپا و فعال
مطالب آموزشی و مقالات سئویی که توسط بنیامین ولادوست در وبلاگ “پرشیا وب” منتشر می‌شوند، بر پایه جدیدترین الگوریتم‌های گوگل و استانداردهای جهانی تدوین شده‌اند. او به عنوان متخصص مورد اعتماد در حوزه دیجیتال مارکتینگ، تاکنون در بیش از ۲۰ مجموعه آموزشی و ورکشاپ تخصصی سخنرانی و تدریس داشته است. بسیاری از کسب‌وکارهای آنلاین موفق، مسیر رشد خود را با آموزش‌ها و راهنمایی‌های او آغاز کرده‌اند.

تمام راهکارها و خدماتی که توسط بنیامین ولادوست و تیم “پرشیا وب” ارائه می‌شوند، بر پایه صداقت، شفافیت و تحلیل داده‌های واقعی بنا شده‌اند. هدف او ارائه مشاوره‌ای است که نه بر اساس تبلیغات، بلکه بر پایه داده و عملکرد واقعی کسب‌وکارها باشد.

دیدگاه‌ خود را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

پیمایش به بالا