INP چیست و چطور آن را در سایت وردپرسی بهبود دهیم؟

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

INP دیگر یک معیار آزمایشی نیست. گوگل از 12 مارس 2024 آن را جایگزین FID کرد و اکنون INP در کنار LCP و CLS یکی از سه معیار اصلی Core Web Vitals است. هدف این شاخص ساده است: بفهمیم صفحه در طول حضور کاربر، چقدر سریع به کلیک، لمس و فشردن کلید پاسخ می‌دهد.

در این راهنما ابتدا INP را دقیق و بدون تعریف‌های مبهم توضیح می‌دهیم، سپس روش اندازه‌گیری آن را در PageSpeed Insights، Search Console و Chrome DevTools بررسی می‌کنیم و در نهایت سراغ مهم‌ترین دلایل INP بالا در وردپرس و راهکارهای عملی برای کاهش آن می‌رویم.

خلاصه سریع: برای داشتن تجربه خوب، INP باید در صدک 75 بازدیدها حدود 200 میلی‌ثانیه یا کمتر باشد. اگر INP بالا است، قبل از نصب یک افزونه دیگر برای افزایش سرعت، باید مشخص کنید مشکل از «تأخیر ورودی»، «پردازش تعامل» یا «رندر نتیجه» است.

INP چیست؟

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

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

اسکرول، حرکت ساده ماوس روی یک عنصر، Zoom و Hover در محاسبه INP وارد نمی‌شوند. بنابراین INP «همه رفتارهای کاربر» را اندازه نمی‌گیرد؛ تمرکز آن روی تعامل‌هایی است که کاربر انتظار پاسخ نسبتاً فوری از صفحه دارد.

INP میانگین همه تعامل‌ها نیست

یکی از سوءبرداشت‌های رایج این است که INP میانگین زمان پاسخ همه کلیک‌هاست. در واقع این معیار بیشتر به سمت یکی از کندترین تعامل‌های بازدید می‌رود. برای بیشتر صفحات، بدترین تعامل همان بازدید می‌تواند مقدار INP باشد؛ اما در صفحه‌هایی با تعداد تعامل بسیار زیاد، برای جلوگیری از اثر اتفاق‌های کاملاً تصادفی، بعضی Outlierها کنار گذاشته می‌شوند. طبق تعریف فعلی web.dev، به ازای هر ۵۰ تعامل، یکی از بدترین تعامل‌ها می‌تواند نادیده گرفته شود.

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

INP دقیقاً چطور کار می‌کند؟

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

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

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

آستانه‌های فعلی گوگل برای INP به شکل زیر هستند:

این اعداد باید در داده‌های میدانی و در صدک 75 ارزیابی شوند و بهتر است موبایل و دسکتاپ جدا بررسی شوند. اگر INP لپ‌تاپ شما 90 میلی‌ثانیه است اما کاربران موبایل واقعی مقدار 380 میلی‌ثانیه تجربه می‌کنند، داده واقعی کاربران برای تصمیم سئو و تجربه کاربری مهم‌تر است.

INP چه تفاوتی با FID دارد؟

FID یا First Input Delay معیار قبلی Core Web Vitals برای پاسخ‌گویی بود. این معیار فقط اولین تعامل کاربر را بررسی می‌کرد و آن هم فقط مدت زمانی را اندازه می‌گرفت که مرورگر برای شروع پردازش Event Handler منتظر مانده بود.

INP دو محدودیت مهم FID را رفع کرد. اول اینکه فقط اولین تعامل را نمی‌بیند و تعامل‌های طول عمر صفحه را بررسی می‌کند. دوم اینکه فقط «تأخیر قبل از شروع کد» را اندازه نمی‌گیرد؛ پردازش Handler و زمانی که مرورگر برای نمایش فریم بعدی نیاز دارد نیز در آن دخیل هستند.

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

چرا INP برای سایت وردپرسی مهم است؟

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

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

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

ارزش INP فقط سئو نیست. در مطالعه موردی منتشرشده در web.dev درباره QuintoAndar، این مجموعه پس از مجموعه‌ای از بهینه‌سازی‌های INP کاهش حدود 80 درصدی این معیار و افزایش 36 درصدی Conversion را گزارش کرد. redBus نیز در مطالعه دیگری افزایش حدود 7 درصدی فروش را پس از بهبود INP گزارش کرده است. این نتایج تضمین نمی‌کنند هر سایت همان رشد را تجربه کند، اما نشان می‌دهند پاسخ‌گویی بهتر می‌تواند مستقیماً با تجربه خرید و تعامل کاربر مرتبط باشد.

چه عواملی باعث INP بالا در سایت وردپرسی می‌شوند؟

1. JavaScript زیاد و Long Task

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

افزونه‌های صفحه‌ساز، فیلتر، Popup، Analytics، تبلیغات، چت آنلاین، Heatmap و بعضی اسکریپت‌های مارکتینگ می‌توانند به این بار اضافه کنند. مسئله صرفاً حجم دانلود JS نیست؛ Parse، Compile و Execute شدن کد نیز CPU مصرف می‌کند.

2. Event Handlerهای سنگین

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

3. DOM بزرگ و Layout پیچیده

هرچه تعداد Nodeها و عمق ساختار صفحه بیشتر باشد، Style Calculation و Layout بعد از تغییرات می‌تواند پرهزینه‌تر شود. صفحات ساخته‌شده با ده‌ها Section تودرتو، Widgetهای پنهان، Mega Menu عظیم یا لیست محصول طولانی معمولاً بیشتر مستعد Presentation Delay هستند.

4. اسکریپت‌های شخص ثالث

کدهای تبلیغات، آنالیتیکس، چت، نقشه، ویدیو، Consent Manager و ابزارهای مارکتینگ می‌توانند حتی زمانی که کاربر مستقیم با آن‌ها تعامل ندارد Main Thread را مشغول کنند. در چنین حالتی کلیک روی عنصر خود سایت باید منتظر اجرای Task شخص ثالث بماند.

5. قالب و افزونه‌هایی که منابع را در همه صفحات بارگذاری می‌کنند

اگر یک فرم‌ساز فقط در صفحه تماس استفاده شده اما JavaScript آن در تمام نوشته‌ها هم اجرا می‌شود، کار غیرضروری به مرورگر اضافه شده است. بارگذاری شرطی Assetها یکی از مهم‌ترین فرصت‌های بهینه‌سازی در وردپرس است.

6. رندر سنگین بعد از تعامل

گاهی JavaScript خیلی طولانی نیست، اما بعد از آن تغییر بزرگی در DOM ایجاد می‌شود. برای مثال فیلتر فروشگاه ممکن است صدها کارت محصول را یکجا حذف و اضافه کند. در این شرایط Presentation Delay می‌تواند بخش اصلی INP باشد.

7. معماری نامناسب «Delay تا اولین تعامل»

بعضی ابزارهای بهینه‌سازی اجرای JavaScript را تا اولین کلیک یا لمس عقب می‌اندازند. این تکنیک می‌تواند بار اولیه صفحه را سبک‌تر نشان دهد، اما اگر همان اولین کلیک مجبور شود یک کتابخانه بزرگ را تازه Initialize کند، ممکن است INP همان تعامل بدتر شود. بنابراین Delay JavaScript را کورکورانه روی همه اسکریپت‌ها فعال نکنید؛ تعامل‌های اصلی سایت را بعد از هر تغییر واقعاً تست کنید.

چطور INP سایت وردپرسی را اندازه‌گیری کنیم؟

برای INP باید بین داده واقعی کاربران و تست محلی برای عیب‌یابی تفاوت بگذاریم. این تفاوت مهم است؛ چون INP به زمان واقعی تعامل کاربران وابسته است و یک تست آزمایشگاهی ساده نمی‌تواند رفتار تمام کاربران را بازسازی کند.

1. PageSpeed Insights؛ برای دیدن داده واقعی کاربران

PageSpeed Insights در بخش داده‌های میدانی از Chrome UX Report یا CrUX استفاده می‌کند. INP نمایش‌داده‌شده در این بخش حاصل تجربه کاربران واقعی Chrome در بازه 28 روز گذشته است، نه نتیجه یک کلیک مصنوعی در همان لحظه تست.

اگر URL بازدید کافی نداشته باشد، ممکن است داده صفحه در دسترس نباشد و PSI به داده سطح Origin تکیه کند یا اصلاً INP نشان ندهد. نبودن INP در این قسمت به معنی خوب یا بد بودن سایت نیست؛ فقط یعنی نمونه واقعی کافی برای آن گزارش وجود ندارد.

برای تحلیل کلی سرعت سایت می‌توانید در کنار این مقاله از راهنمای افزایش سرعت سایت وردپرسی هم استفاده کنید.

2. Search Console؛ برای پیدا کردن گروه صفحات مشکل‌دار

در گزارش Core Web Vitals سرچ کنسول، URLها بر اساس داده‌های واقعی CrUX گروه‌بندی می‌شوند. این ابزار برای پاسخ به این سؤال مناسب است: «کدام نوع صفحات سایت من INP ضعیف دارند؟» برای مثال شاید گروه صفحات محصول مشکل داشته باشند اما نوشته‌های وبلاگ سالم باشند.

Search Console برای پیدا کردن الگو عالی است، اما معمولاً به شما نمی‌گوید دقیقاً کدام دکمه یا Event Handler مشکل را ایجاد کرده است. بعد از پیدا کردن گروه URL باید به ابزار عیب‌یابی محلی بروید. اگر با این ابزار آشنایی ندارید، مقاله گوگل سرچ کنسول چیست می‌تواند نقطه شروع مناسبی باشد.

3. Chrome DevTools؛ برای پیدا کردن تعامل کند

در نسخه‌های جدید Chrome، پنل Performance صفحه Live Metrics دارد و با تعامل شما با صفحه، INP محلی و تاریخچه Interactionها را ثبت می‌کند. برای عیب‌یابی جدی‌تر می‌توانید یک Performance Trace بگیرید، روی منو، فیلتر، فرم یا دکمه موردنظر کلیک کنید و سپس در Interaction Track سه بخش Input Delay، Processing و Presentation Delay را ببینید.

این روش برای وردپرس بسیار کاربردی است، چون می‌توانید دقیقاً همان سناریویی را که کاربر انجام می‌دهد بازسازی کنید: باز کردن منوی موبایل، انتخاب Variation، فیلتر محصولات، افزودن محصول به سبد یا تایپ در جستجوی زنده.

4. TBT را با INP اشتباه نگیرید

Lighthouse در تست عادی PageSpeed، INP واقعی کاربران را تولید نمی‌کند. در محیط آزمایشگاهی، Total Blocking Time یا TBT می‌تواند برای پیدا کردن JavaScript مسدودکننده مفید باشد، اما جای INP را نمی‌گیرد.

ممکن است صفحه TBT بالایی هنگام Load داشته باشد، اما کاربران زمانی کلیک کنند که Main Thread آزاد شده و INP واقعی خوب باشد. برعکس، صفحه ممکن است بارگذاری اولیه قابل قبولی داشته باشد اما یک فیلتر یا Modal بعداً Event Handler سنگینی اجرا کند و INP ضعیفی بسازد. بنابراین TBT را «سرنخ» بدانید، نه نسخه آزمایشگاهی INP.

5. برای سایت‌های بزرگ: RUM اختصاصی

اگر سایت پرترافیک یا اپلیکیشن‌مانند دارید، می‌توانید با کتابخانه رسمی web-vitals داده INP را از کاربران واقعی جمع‌آوری و همراه اطلاعات Attribution ذخیره کنید. این روش می‌تواند مشخص کند کدام Interaction، عنصر یا Script در Field Data بیشتر مشکل ایجاد کرده است. برای بیشتر سایت‌های وردپرسی معمولی، PSI، Search Console و DevTools کافی هستند؛ RUM اختصاصی زمانی ارزش دارد که تیم فنی و حجم داده مناسب داشته باشید.

چطور بفهمیم دقیقاً کدام بخش INP مشکل دارد؟

بهترین روش این است که از عدد کلی به Interaction واقعی برسید. به‌جای اینکه یک‌باره همه JavaScriptها را Minify کنید، ابتدا چند تعامل مهم کسب‌وکار را فهرست کنید و هرکدام را جدا تست کنید.

• منوی موبایل و Mega Menu
• جستجوی زنده
• فیلتر و مرتب‌سازی محصول
• انتخاب Variation در WooCommerce
• افزودن به سبد خرید
• باز کردن سبد خرید کناری یا Modal
• ارسال فرم تماس یا ثبت‌نام
• تب‌ها، آکاردئون‌ها و FAQهای تعاملی
• دکمه‌های Load More و Infinite Scroll

اگر در DevTools مقدار Input Delay بیشترین سهم را دارد، دنبال کاری بگردید که قبل از Interaction شما Main Thread را اشغال کرده است. اگر Processing Duration بزرگ است، خود Event Handler یا کد اجراشده بعد از کلیک مقصر اصلی است. اگر Presentation Delay بالا است، DOM، Style، Layout و حجم تغییرات رابط را بررسی کنید.

چطور INP را در سایت وردپرسی بهبود دهیم؟

1. اول افزونه یا Interaction پرهزینه را پیدا کنید

حذف تصادفی افزونه‌ها روی سایت اصلی روش خوبی برای عیب‌یابی نیست. یک نسخه Staging بسازید، Baseline بگیرید و تعامل کند را چند بار تکرار کنید. سپس افزونه‌ها یا قابلیت‌های مرتبط را یکی‌یکی بررسی کنید.

اگر کندی فقط در فیلتر فروشگاه رخ می‌دهد، لازم نیست افزونه Backup را متهم کنید. اگر Input Delay در همه تعامل‌ها دیده می‌شود، احتمال وجود JavaScript سراسری، تبلیغات یا Timerهای شخص ثالث بیشتر است.

2. JavaScript غیرضروری را کمتر کنید

هدف صرفاً کوچک کردن فایل‌ها نیست؛ هدف این است که Main Thread کار کمتری انجام دهد. افزونه‌ها و قابلیت‌هایی که استفاده نمی‌شوند حذف شوند، Scriptهای مربوط به یک صفحه فقط همان‌جا Load شوند و کتابخانه تکراری یا ماژول بلااستفاده وارد همه صفحات نشود.

در WordPress، توسعه‌دهنده باید Scriptها را با API استاندارد وردپرس Enqueue کند. از WordPress 6.3 به بعد، wp_enqueue_script() از Strategyهای defer و async پشتیبانی می‌کند و Dependency Tree را هنگام انتخاب Strategy در نظر می‌گیرد.

3. Long Taskها را به کارهای کوچک‌تر تقسیم کنید

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

در کدهای جدید، scheduler.yield() یکی از روش‌های مناسب برای Yield کردن است و در محیط‌هایی که پشتیبانی کامل وجود ندارد باید Fallback در نظر گرفته شود. setTimeout(..., 0) نیز سال‌ها برای شکستن Taskها استفاده شده، اما هدف اصلی تکنیک مهم‌تر از API است: بعد از به‌روزرسانی ضروری UI، اجازه بدهید مرورگر فریم را Paint کند و سپس کار کم‌اولویت‌تر ادامه پیدا کند.

4. بازخورد فوری را قبل از کار سنگین نمایش دهید

فرض کنید ارسال یک فرم یا اعمال فیلتر نیاز به پردازش بیشتری دارد. بهتر است کاربر سریع ببیند که کلیک ثبت شده است؛ مثلاً دکمه وارد حالت Loading شود. اما فقط اضافه کردن Spinner کافی نیست. اگر همان Event Handler ابتدا 500 میلی‌ثانیه پردازش سنگین انجام دهد و بعد Spinner را نمایش دهد، کاربر همچنان 500 میلی‌ثانیه چیزی نمی‌بیند.

الگوی درست این است که تغییر بصری ضروری انجام شود، مرورگر فرصت Paint پیدا کند و کار سنگین‌تر در ادامه انجام شود. مطالعه موردی QuintoAndar در web.dev دقیقاً از Yield پس از نمایش Spinner برای سریع‌تر شدن بازخورد اولیه استفاده کرده است.

5. DOM و رندر صفحه را سبک کنید

اگر Presentation Delay بالا است، JavaScript تنها متهم نیست. صفحه‌سازها ممکن است برای یک بخش ساده چندین Wrapper ایجاد کنند، Mega Menu صدها Node داشته باشد یا فیلتر محصول تعداد زیادی کارت را هم‌زمان تغییر دهد.

راهکارهای عملی شامل حذف Sectionهای تودرتوی بی‌استفاده، Render نکردن اجزایی که هنوز دیده نمی‌شوند، محدود کردن تعداد عناصر منو و لیست‌های بزرگ، ساده‌تر کردن Selectors و جلوگیری از Layout Thrashing است.

Lazy Load برای Widgetهای پایین صفحه می‌تواند DOM اولیه و کار مرورگر را کمتر کند، اما Lazy Load تصویر را نباید به‌عنوان راهکار مستقیم و عمومی INP معرفی کرد. اثر آن زمانی مفید است که واقعاً Main Thread یا Rendering را سبک‌تر کند.

6. اسکریپت‌های شخص ثالث را محدود کنید

ابزارهای مارکتینگ را براساس نیاز واقعی ارزیابی کنید. اگر سه ابزار مختلف Session Recording، دو چت آنلاین و چند Pixel تبلیغاتی هم‌زمان دارید، هرکدام ممکن است Task یا Timer خود را اجرا کنند.

در DevTools مشخص کنید کدام Script شخص ثالث در حوالی Interaction کند روی Main Thread فعال بوده است. اگر ابزار ضروری نیست حذفش کنید؛ اگر ضروری است، تنظیمات سبک‌تر، بارگذاری شرطی یا جایگزین کم‌هزینه‌تر را بررسی کنید.

7. افزونه‌های وردپرس را براساس عملکرد واقعی انتخاب کنید

تعداد افزونه به‌تنهایی تعیین‌کننده نیست. یک افزونه بد می‌تواند بیشتر از چند افزونه استاندارد Main Thread را درگیر کند. به‌خصوص افزونه‌های Page Builder، Popup، فیلتر، Live Search، Slider، Tracking و بعضی امکانات WooCommerce را در Interactionهای واقعی تست کنید.

اگر یک افزونه فقط در یک Landing Page لازم است اما Assetهای آن همه سایت را پوشش می‌دهند، بررسی کنید آیا تنظیمی برای بارگذاری شرطی دارد یا توسعه‌دهنده می‌تواند Asset را فقط در صفحه لازم Enqueue کند.

8. قالب را فقط با ظاهر انتخاب نکنید

Theme می‌تواند DOM، منو، انیمیشن، Slider و Scriptهای فرانت‌اند را به سایت اضافه کند. اگر با تغییر قالب Interactionها به شکل محسوسی بهتر می‌شوند، باید منابع و Handlerهای Theme را بررسی کنید. قالبی که Demo زیبایی دارد اما روی موبایل برای باز کردن منو 400 میلی‌ثانیه Main Thread را مسدود می‌کند انتخاب مناسبی نیست.

9. Web Worker را فقط برای پردازش مناسب استفاده کنید

Web Worker می‌تواند بعضی محاسبات سنگین JavaScript را از Main Thread خارج کند، اما Worker به DOM دسترسی مستقیم ندارد. بنابراین برای هر مشکل INP راه‌حل جادویی نیست. محاسبات داده، پردازش لیست یا کار CPU-heavy مستقل از DOM می‌توانند کاندید باشند؛ تغییر رابط کاربری همچنان باید روی Main Thread انجام شود.

10. Interactionهای WooCommerce را جداگانه تست کنید

در فروشگاه، فقط صفحه اصلی را تست نکنید. Add to Cart، تغییر تعداد، Variation، فیلتر، Coupon، Cart Drawer و Checkout رفتارهای متفاوتی دارند. بعضی مشکل‌ها از JavaScript افزونه، بعضی از Render گسترده DOM و بعضی از درخواست شبکه ناشی می‌شوند.

نکته مهم این است که زمان شبکه به‌خودی‌خود همان INP نیست. INP تا زمانی را اندازه می‌گیرد که مرورگر بتواند فریم بعدی را Paint کند، نه کل زمان دریافت نتیجه یک API. اگر بعد از کلیک بازخورد فوری نمایش دهید و درخواست شبکه Async ادامه پیدا کند، ممکن است INP خوب باشد حتی اگر نتیجه نهایی چند لحظه بعد برسد.

نقش هاست، CDN، کش و تصاویر در INP چیست؟

در بسیاری از آموزش‌ها هر مشکل سرعتی با «هاست سریع‌تر، CDN و فشرده‌سازی تصویر» پاسخ داده می‌شود. این توصیه‌ها برای Performance کلی مفیدند، اما برای INP باید دقیق‌تر باشیم.

هاست

INP عمدتاً معیار پاسخ‌گویی سمت مرورگر است. ارتقای CPU سرور لزوماً یک Event Handler سنگین JavaScript را سریع نمی‌کند. هاست زمانی اثر ملموس‌تری دارد که Interaction شما به پاسخ سرور وابسته باشد و معماری UI طوری باشد که کاربر تا دریافت یا پردازش آن پاسخ منتظر بماند.

CDN

CDN می‌تواند تحویل Assetها را سریع‌تر کند و در مرحله Load فشار را کم کند، اما اگر مشکل اصلی 300 میلی‌ثانیه پردازش JavaScript بعد از کلیک است، CDN درمان مستقیم آن نیست.

کش

Page Cache و Object Cache می‌توانند زمان تولید و دریافت صفحات را بهتر کنند، اما INP ضعیف ناشی از Main Thread همچنان نیاز به اصلاح فرانت‌اند دارد. کش را برای حل TTFB و Load Performance استفاده کنید، نه به‌عنوان پاسخ خودکار به همه مشکلات INP.

تصاویر

بهینه‌سازی تصویر برای LCP و حجم صفحه بسیار مهم است. اثر آن بر INP بیشتر غیرمستقیم است؛ مثلاً وقتی Decode یا Rendering سنگین با Interaction هم‌زمان شود. بنابراین در اولویت‌بندی INP ابتدا Interaction Trace را ببینید و براساس علت واقعی تصمیم بگیرید.

اشتباهات رایج در بهینه‌سازی INP وردپرس

• یکی دانستن INP و سرعت لود: صفحه می‌تواند سریع Load شود ولی بعد از کلیک کند باشد.
• اعتماد به TBT به‌عنوان INP آزمایشگاهی: TBT سرنخ مفیدی است، اما رفتار واقعی Interaction را جایگزین نمی‌کند.
• بهینه‌سازی فقط صفحه اصلی: Interaction مهم ممکن است در محصول، Checkout، فرم یا پنل کاربر باشد.
• نصب چند افزونه سرعت بدون Trace: ممکن است Script بیشتری به صفحه اضافه کنید و علت اصلی را هم پیدا نکنید.
• Delay کردن همه JavaScriptها تا اولین کلیک: اگر اولین Interaction مجبور به Initialize کردن کد سنگین شود، همان Interaction می‌تواند کندتر شود.
• تمرکز صرف روی Minify: کوچک شدن فایل خوب است، اما زمان اجرای Handler و Rendering معمولاً برای INP مهم‌تر است.
• فرض اینکه هاست سریع همه‌چیز را حل می‌کند: Main Thread مرورگر با ارتقای سرور سبک نمی‌شود.
• اعتماد به تست دسکتاپ قوی: Interaction را روی موبایل و با CPU Throttling هم بررسی کنید.
• تغییر چند متغیر هم‌زمان: اگر افزونه، قالب، کش و Scriptها را با هم عوض کنید نمی‌فهمید کدام تغییر INP را بهتر کرده است.

جدول چک‌لیست بهبود INP در وردپرس

جمع‌بندی

INP قرار نیست فقط یک عدد دیگر در PageSpeed باشد. این معیار به یک سؤال مهم پاسخ می‌دهد: وقتی کاربر واقعاً با سایت شما کار می‌کند، رابط با چه سرعتی واکنش نشان می‌دهد؟ از سال ۲۰۲۴ نیز این معیار به‌صورت رسمی جایگزین FID و یکی از Core Web Vitals شده است.

برای وردپرس، مسیر درست بهینه‌سازی از تشخیص Interaction شروع می‌شود، نه از نصب افزونه جدید. ابتدا داده واقعی را در PageSpeed و Search Console ببینید، سپس Interaction مشکل‌دار را در Chrome DevTools بازسازی کنید و مشخص کنید بیشترین تأخیر در Input Delay، Processing یا Presentation رخ می‌دهد.

اگر JavaScript زیاد است، حجم کار Main Thread را کم کنید. اگر Handler سنگین است، کار را کوتاه یا بخش‌بندی کنید. اگر رندر مشکل دارد، DOM و Layout را ساده‌تر کنید. اسکریپت‌های شخص ثالث و Assetهای افزونه و قالب را نیز فقط در جایی که نیاز هستند بارگذاری کنید.

در نهایت هدف این نیست که یک Score سبز برای اسکرین‌شات داشته باشید؛ هدف این است که منو، فیلتر، فرم، سبد خرید و همه Interactionهای مهم سایت روی دستگاه کاربران واقعی سریع و قابل اعتماد باشند.