INP چیست و چرا جای FID را گرفت؟

INP چیست و چه چیزی را می‌سنجد؟

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

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

تعامل‌هایی که در INP لحاظ می‌شوند

INP تمام تعامل‌های زیر را در بر می‌گیرد:

• کلیک ماوس: تمام کلیک‌های کاربر بر روی عناصر تعاملی.
• ضربه لمسی: در دستگاه‌های لمسی مانند موبایل و تبلت.
• تایپ کیبورد: تایپ در فرم‌ها و فیلدهای متنی.
• تعامل با کیبورد: استفاده از کلیدهای Tab، Enter و Space.
• کلیک قلم: در دستگاه‌های با قلم دیجیتال.

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

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

برای درک جایگاه INP در چارچوب کلی Core Web Vitals، مقاله Core Web Vitals چیست و چرا گوگل بر آن تاکید دارد؟ نقطه شروع خوبی است.

چرا INP جای FID را گرفت؟

FID (First Input Delay) از سال ۲۰۱۸ به‌عنوان یکی از سه ستون Core Web Vitals معرفی شد. این معیار، تنها تأخیر اولین تعامل کاربر را اندازه‌می‌گرفت — یعنی زمانی که از لحظه اولین کلیک، ضربه یا تایپ کاربر تا لحظه واکنش مرورگر سپری می‌شد.

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

دلیل اول: محدودیت به اولین تعامل

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

دلیل دوم: نادیده گرفتن پردازش و رندر

FID تنها تأخیر ورودی (Input Delay) را می‌سنجید و زمان پردازش Event Handler و زمان رندر پس از پردازش را نادیده می‌گرفت. این بدان معناست که سایتی با Event Handler سنگین اما Input Delay کوتاه، در FID امتیاز خوبی می‌گرفت، در حالی که کاربر تجربه کندی در پاسخ را احساس می‌کرد.

دلیل سوم: ناتوانی در سنجش تجربه پیوسته

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

برای درک عمیق‌تر تاریخچه این جابه‌جایی، مقاله FID و تاریخچه آن در Core Web Vitals را مطالعه کنید. همچنین مقاله چرا FID جای خود را به INP داد؟ چارچوب دقیق این تحول را باز می‌کند.

سه فاز پردازش تعامل

INP از سه فاز مستقل تشکیل شده که هر یک می‌تواند به گلوگاه تبدیل شود. درک این تفکیک، پیش‌نیاز هر استراتژی بهینه‌سازی مؤثر است.

فاز اول: تأخیر ورودی (Input Delay)

زمانی که از لحظه تعامل کاربر تا لحظه شروع پردازش Event Handler سپری می‌شود. این فاز، به وضعیت Main Thread وابسته است: اگر Main Thread مشغول اجرای کار سنگین باشد، تأخیر ورودی افزایش می‌یابد.

فاز دوم: زمان پردازش (Processing Time)

زمانی که Event Handler برای اجرا صرف می‌کند. این فاز، به پیچیدگی کد اجرا‌شده در پاسخ به تعامل وابسته است. اگر Event Handler شامل محاسبات سنگین، دستکاری DOM گسترده یا اجرای زنجیره‌ای چند تابع باشد، زمان پردازش افزایش می‌یابد.

فاز سوم: تأخیر ارائه (Presentation Delay)

زمانی که مرورگر برای محاسبه استایل، چیدمان و رندر بصری تغییرات پس از پردازش صرف می‌کند. این فاز، به پیچیدگی CSS، عمق DOM و وسعت تغییرات بصری وابسته است.

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

آستانه‌های INP و طبقه‌بندی عملکرد

گوگل برای INP سه آستانه عملکردی تعریف کرده که مبنای طبقه‌بندی سایت‌ها است:

• خوب (Good): INP زیر ۲۰۰ میلی‌ثانیه.
• نیازمند بهبود (Needs Improvement): INP بین ۲۰۰ تا ۵۰۰ میلی‌ثانیه.
• ضعیف (Poor): INP بالای ۵۰۰ میلی‌ثانیه.

«آستانه ۲۰۰ میلی‌ثانیه برای INP، بازتابی از آستانه ادراک انسان از تأخیر در تعامل است؛ فراتر از این عدد، کاربر تأخیر را به‌طور محسوس احساس می‌کند.»

نکته مهم این است که آستانه ۲۰۰ میلی‌ثانیه بسیار سختگیرانه‌تر از آنچه به‌نظر می‌رسد. یک Event Handler متوسط در JavaScript، می‌تواند به‌سرعت از این آستانه عبور کند. به همین دلیل، بهینه‌سازی INP نیازمند دقت بالایی در کد است.

همچنین، آستانه‌ها بر پایه صدک ۷۵ (75th percentile) داده واقعی کاربران سنجیده می‌شوند. این بدان معناست که سایت شما باید برای ۷۵ درصد بازدیدکنندگان واقعی، INP زیر ۲۰۰ میلی‌ثانیه داشته باشد تا در دسته «خوب» قرار گیرد.

تفاوت INP با LCP و CLS

Core Web Vitals از سه معیار مستقل تشکیل شده که هر یک بعد متفاوتی از تجربه کاربری را می‌سنجد:

• LCP (Largest Contentful Paint): سرعت بارگذاری و نمایش محتوای اصلی.
• CLS (Cumulative Layout Shift): پایداری بصری و جلوگیری از جابه‌جایی.
• INP (Interaction to Next Paint): پاسخ‌گویی به تعامل کاربر.

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

برای درک دقیق LCP، مقاله LCP چیست و چرا برای تجربه کاربری مهم است؟ را مطالعه کنید. برای CLS، مقاله CLS چیست و چگونه کاهش می‌یابد؟ را ببینید. برای مرور راهکارهای کلی، مقاله چگونه Core Web Vitals را بهبود دهیم؟ نقطه شروع خوبی است.

علل رایج INP ضعیف در سایت‌ها

INP ضعیف در سایت‌های مدرن، از چند منبع اصلی ناشی می‌شود. شناخت این منابع، پیش‌نیاز هر استراتژی بهینه‌سازی است.

دسته اول: Long Tasks

Long Tasks به وظایفی گفته می‌شود که بیش از ۵۰ میلی‌ثانیه Main Thread را اشغال می‌کنند. این وظایف، مانع از پاسخ سریع مرورگر به تعامل کاربر می‌شوند و تأخیر ورودی را افزایش می‌دهند.

دسته دوم: Event Handlerهای سنگین

Event Handlerهایی که محاسبات سنگین، دستکاری DOM گسترده یا درخواست‌های شبکه‌ای همگام انجام می‌دهند، زمان پردازش را افزایش می‌دهند و INP را به‌طور مستقیم بدتر می‌کنند.

دسته سوم: دستکاری DOM گسترده

تغییرات گسترده در DOM، منجر به محاسبه مجدد استایل، چیدمان و رندر می‌شود. این فرآیند، فاز تأخیر ارائه را افزایش می‌دهد و INP را بدتر می‌کند.

دسته چهارم: بارگذاری اسکریپت‌های اضافی

افزونه‌های متعدد، SDKهای خارجی و اسکریپت‌های تحلیلی، بار پردازشی زیادی روی Main Thread تحمیل می‌کنند که به‌طور غیرمستقیم بر INP اثر می‌گذارد.

دسته پنجم: Hydration سنگین

در اپلیکیشن‌های مدرن مبتنی بر فریم‌ورک (مانند React، Vue و Angular)، فرآیند Hydration می‌تواند Main Thread را برای مدت طولانی اشغال کند و به تأخیر ورودی اولیه منجر شود.

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

نقش Main Thread در INP

Main Thread مرورگر، مسئول اجرای JavaScript، محاسبه استایل، چیدمان و رندر بصری است. این Thread، نقش محوری در INP دارد چون هر تعامل کاربر، نیازمند اجرای یک Event Handler روی همین Thread است.

محدودیت تک‌رشته‌ای بودن

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

تقسیم کار بین Threadها

یکی از مؤثرترین راهکارها برای کاهش INP، انتقال کارهای سنگین به Threadهای دیگر است. Web Workers، Service Workers و OffscreenCanvas، ابزارهای اصلی برای این انتقال هستند.

Yield کردن Main Thread

در JavaScript، تکنیک‌های Yield کردن Main Thread — مانند استفاده از scheduler.yield()، requestIdleCallback یا setTimeout — به مرورگر امکان می‌دهند که بین کارهای سنگین، فرصتی برای پاسخ به تعامل کاربر پیدا کند.

«Main Thread، قلب تپنده پاسخ‌گویی سایت است؛ هر ثانیه که این قلب درگیر کار سنگین باشد، تأخیر در تعامل کاربر انباشته می‌شود.»

در پروژه‌های واقعی، دیده‌ام که Yield کردن Main Thread به‌تنهایی می‌تواند INP را تا ۳۰ درصد کاهش دهد. این تکنیک، یکی از مؤثرترین راهکارها در بهینه‌سازی INP است.

Long Tasks و اثر آن بر پاسخ‌گویی

Long Task به وظیفه‌ای گفته می‌شود که بیش از ۵۰ میلی‌ثانیه Main Thread را اشغال می‌کند. این وظایف، منبع اصلی تأخیر ورودی در INP هستند.

منابع رایج Long Tasks

• اجرای اسکریپت‌های سنگین در لحظه بارگذاری اولیه.
• Hydration در اپلیکیشن‌های فریم‌ورک‌محور.
• پردازش داده‌های بزرگ در JavaScript.
• دستکاری DOM گسترده در یک Event Handler.
• اجرای افزونه‌های تحلیلی و تبلیغاتی.

شناسایی Long Tasks

Chrome DevTools در بخش Performance، Long Tasks را با علامت قرمز مشخص می‌کند. همچنین PerformanceObserver API امکان پایش برنامه‌نویسی‌شده Long Tasks را فراهم می‌کند.

تقسیم Long Tasks

مؤثرترین راهکار در مواجهه با Long Tasks، تقسیم آنها به قطعات کوچک‌تر است. با استفاده از Yield کردن بین قطعات، مرورگر فرصتی برای پاسخ به تعامل کاربر پیدا می‌کند.

در پروژه‌های واقعی، دیده‌ام که شناسایی و تقسیم Long Tasks، یکی از مؤثرترین راهکارها در کاهش INP است. این رویکرد، به‌ویژه در سایت‌های مبتنی بر فریم‌ورک مدرن، ضروری است.

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

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

ابزارهای داده آزمایشگاهی

• Chrome DevTools: ابزار داخلی مرورگر برای تحلیل زنده و ردیابی تعامل‌ها.
• Lighthouse: ابزار جامع گوگل — با محدودیت که Lighthouse در حال حاضر به‌طور کامل INP را شبیه‌سازی نمی‌کند.
• WebPageTest: ابزار پیشرفته برای تحلیل عمیق.
• Performance panel: برای مشاهده دقیق تعامل‌ها و Long Tasks.

ابزارهای داده واقعی

• Search Console Core Web Vitals: گزارش رسمی گوگل.
• CrUX (Chrome User Experience Report): داده واقعی کاربران Chrome.
• web-vitals JavaScript library: کتابخانه رسمی گوگل برای سنجش INP در کد.
• RUM (Real User Monitoring): ابزارهای تحلیل تجربه واقعی کاربران.

PerformanceObserver API

مؤثرترین روش سنجش INP در کد، استفاده از PerformanceObserver با نوع event است. این API، امکان ثبت تمام تعامل‌ها و محاسبه INP را فراهم می‌کند.

در پروژه‌های واقعی، ترکیب این دو لایه رویکرد توصیه‌شده است. داده آزمایشگاهی برای تحلیل دقیق و شناسایی علل؛ داده واقعی برای سنجش اثر نهایی. برای آشنایی با ابزارهای سنجش، مقاله ابزارهای سنجش Core Web Vitals کدامند؟ را مطالعه کنید.

راهکارهای عملی بهبود INP

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

لایه اول: شناسایی گلوگاه

پیش از هر اقدامی، باید فاز گلوگاه — تأخیر ورودی، زمان پردازش یا تأخیر ارائه — را در صفحه هدف شناسایی کنید. این کار با استفاده از Chrome DevTools و Performance panel امکان‌پذیر است.

لایه دوم: تقسیم Long Tasks

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

لایه سوم: بهینه‌سازی Event Handlerها

Event Handlerها را ساده‌تر کنید، محاسبات سنگین را به تعویق بیندازید و از Debounce و Throttle برای رویدادهای پرتکرار استفاده کنید.

لایه چهارم: کاهش کار DOM

دستکاری DOM را به حداقل برسانید، از DocumentFragment برای تغییرات دسته‌ای استفاده کنید و از تغییرات گسترده پرهیز نمایید.

لایه پنجم: انتقال کار به Web Worker

محاسبات سنگین را به Web Worker منتقل کنید تا Main Thread آزاد بماند.

لایه ششم: پایش مستمر

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

برای مرور راهکارهای کلی در چارچوب Core Web Vitals، مقاله چگونه Core Web Vitals را بهبود دهیم؟ را مطالعه کنید.

بهینه‌سازی Event Handlerها

Event Handlerها، بخش بزرگی از زمان پردازش تعامل را اشغال می‌کنند. بهینه‌سازی آنها، یکی از مؤثرترین راهکارها در کاهش INP است.

راهکار اول: Debounce و Throttle

برای رویدادهای پرتکرار مانند scroll، resize و input، استفاده از Debounce و Throttle از اجرای مکرر و سنگین Handler جلوگیری می‌کند.

راهکار دوم: Defer کارهای غیرحیاتی

اگر بخشی از کار Event Handler بلافاصله لازم نیست — مانند ثبت آمار یا درخواست شبکه‌ای — با استفاده از requestIdleCallback یا setTimeout به تعویق بیندازید.

راهکار سوم: استفاده از Passive Event Listeners

برای رویدادهای اسکرول و تاچ، استفاده از { passive: true } در تعریف Event Listener، از مسدود شدن تعامل جلوگیری می‌کند.

راهکار چهارم: حذف Event Listenerهای اضافی

هر Event Listener اضافی، بار پردازشی بر مرورگر تحمیل می‌کند. حذف Listenerهایی که در صفحات خاص استفاده نمی‌شوند، INP را بهبود می‌بخشد.

راهکار پنجم: کاهش عمق Event Propagation

رویدادها در DOM از طریق Event Propagation منتشر می‌شوند. کاهش عمق این انتشار با استفاده از Event Delegation، بار پردازشی را کاهش می‌دهد.

در پروژه‌های واقعی، دیده‌ام که بهینه‌سازی Event Handlerها به‌تنهایی می‌تواند INP را تا ۴۰ درصد کاهش دهد. این اقدام، به‌ویژه در سایت‌هایی که تعامل‌های زیادی دارند، بسیار مؤثر است.

تکنیک‌های Yield کردن Main Thread

Yield کردن Main Thread، به معنای دادن فرصت به مرورگر برای انجام کارهای دیگر — از جمله پاسخ به تعامل کاربر — در بین وظایف سنگین است.

تکنیک اول: scheduler.yield()

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

تکنیک دوم: setTimeout با تأخیر صفر

روش سنتی‌تر، استفاده از setTimeout(callback, 0) است که کار را به انتهای صف وظایف منتقل می‌کند و فرصت پاسخ به تعامل را فراهم می‌کند.

تکنیک سوم: requestIdleCallback

برای کارهای غیرحیاتی، requestIdleCallback به مرورگر اعلام می‌کند که کار را در زمان بیکاری اجرا کند.

تکنیک چهارم: isInputPending()

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

تکنیک پنجم: Web Workers

محاسبات سنگین را به Web Worker منتقل کنید تا Main Thread آزاد بماند و INP بهبود یابد.

«Yield کردن، یک تسلیم نیست؛ یک تصمیم مهندسی برای توزیع عادلانه زمان پردازش بین وظایف و تعامل کاربر است.»

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

INP در وردپرس: چالش‌های خاص

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

چالش اول: انباشت اسکریپت‌های افزونه‌ها

هر افزونه، مجموعه‌ای از اسکریپت‌ها را به صفحه اضافه می‌کند. در سایت‌هایی با ۳۰ تا ۵۰ افزونه فعال، مجموع این اسکریپت‌ها می‌تواند Main Thread را برای مدت طولانی مشغول کند.

چالش دوم: Hydration سنگین

در سایت‌هایی که از Page Builder مدرن استفاده می‌کنند، فرآیند Hydration می‌تواند INP را بدتر کند.

چالش سوم: Analytics و Tracking

اسکریپت‌های تحلیلی، تبلیغاتی و Tracking، به‌طور معمول Main Thread را مشغول می‌کنند و INP را بدتر می‌کنند.

چالش چهارم: Event Handlerهای ناکارآمد

بسیاری از قالب‌ها و افزونه‌های وردپرس، Event Handlerهای ناکارآمد دارند که زمان پردازش را افزایش می‌دهند.

برای راهنمای جامع بهینه‌سازی INP در وردپرس، مقاله Core Web Vitals در وردپرس چگونه بهبود می‌یابد؟ را مطالعه کنید.

INP در موبایل: چرا سخت‌تر است؟

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

• پردازش کندتر: دستگاه‌های موبایل، CPU و GPU محدودتری دارند.
• حافظه محدودتر: رم کمتر، اجرای اسکریپت‌های سنگین را کندتر می‌کند.
• شبکه ناپایدار: اتصال موبایل، ناپایدارتر از دسکتاپ است.
• مدیریت انرژی: سیستم‌عامل موبایل، برای صرفه‌جویی در باتری، عملکرد CPU را محدود می‌کند.

در پروژه‌های واقعی، دیده‌ام که سایت‌هایی که بر پایه دسکتاپ بهینه شده‌اند، در موبایل INP بالاتری دارند. این پدیده، ریشه در نادیده گرفتن تفاوت‌های سخت‌افزاری دارد. برای درک عمیق‌تر، مقاله چرا Core Web Vitals در موبایل با دسکتاپ فرق دارد؟ را مطالعه کنید. همچنین مقاله چگونه Core Web Vitals را در موبایل بهبود دهیم؟ راهکارهای عملی ارائه می‌دهد.

اثر INP بر نرخ تبدیل

INP، بر خلاف تصور رایج، یک معیار صرفاً فنی نیست؛ یک سنجه اقتصادی است که به‌طور مستقیم بر نرخ تبدیل اثر می‌گذارد.

مکانیزم‌های اثر INP بر نرخ تبدیل

1. کاهش رها کردن فرم: کاربری که در فرم با تأخیر مواجه می‌شود، اغلب آن را نیمه‌کاره رها می‌کند.
2. افزایش تعامل با CTA: دکمه‌هایی که سریع پاسخ می‌دهند، بیشتر کلیک می‌شوند.
3. بهبود تجربه خرید: در فروشگاه آنلاین، سرعت پاسخ به تعامل، بر تصمیم خرید اثر می‌گذارد.
4. کاهش نرخ پرش: سایت پاسخ‌گو، کاربر را نگه می‌دارد.

در پروژه‌های واقعی، دیده‌ام که بهبود INP به‌تنهایی می‌تواند نرخ تبدیل را تا ۵ تا ۱۰ درصد افزایش دهد. این اثر، در سایت‌هایی با فرم‌های طولانی یا تعامل‌های پیچیده، برجسته‌تر است. برای درک این رابطه، مقاله رابطه Core Web Vitals و نرخ تبدیل چیست؟ را مطالعه کنید.

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

در تجربه‌های واقعی، بیشترین اتلاف منابع از اشتباه اول و سوم ناشی می‌شود. تیم‌هایی که INP را نادیده می‌گیرند یا بدون شناسایی فاز گلوگاه وارد بهینه‌سازی می‌شوند، معمولاً به نتایج مطلوب نمی‌رسند. برای درک اشتباهات رایج در حوزه Core Web Vitals، مقاله چه اشتباهاتی در بهینه‌سازی Core Web Vitals رایج است؟ را ببینید.

پرسش‌های پرتکرار درباره INP

INP خوب چقدر است؟

آستانه INP خوب، زیر ۲۰۰ میلی‌ثانیه است. این آستانه بر پایه صدک ۷۵ داده واقعی کاربران سنجیده می‌شود. برای قرار گرفتن در دسته «خوب»، سایت باید برای ۷۵ درصد بازدیدکنندگان واقعی، INP زیر ۲۰۰ میلی‌ثانیه داشته باشد.

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

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

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

با ترکیب ابزارهای داده آزمایشگاهی و داده واقعی. Performance panel در Chrome DevTools نقطه شروع خوبی است. برای داده واقعی، از Search Console Core Web Vitals و کتابخانه web-vitals استفاده کنید. برای درک ابزارهای موجود، مقاله ابزارهای سنجش Core Web Vitals کدامند؟ را ببینید.

آیا INP بر رتبه گوگل اثر دارد؟

بله، به‌عنوان یکی از چندین سیگنال. Core Web Vitals بخشی از سیگنال‌های تجربه صفحه در الگوریتم گوگل است. اثر مستقیم آن معمولاً کمتر از اثر غیرمستقیم آن از طریق تعامل کاربر و نرخ تبدیل است.

مؤثرترین راهکار کاهش INP چیست؟

تقسیم Long Tasks و Yield کردن Main Thread. این دو تکنیک، به‌طور مستقیم تأخیر ورودی را کاهش می‌دهند و به مرورگر امکان پاسخ سریع به تعامل کاربر را می‌دهند. برای درک عمیق‌تر این حوزه، مقاله بهینه‌سازی INP برای موبایل را مطالعه کنید.

آیا INP در موبایل بالاتر از دسکتاپ است؟

بله، به‌طور معمول. این تفاوت ناشی از پردازش کندتر، حافظه محدودتر و شبکه ناپایدارتر دستگاه‌های موبایل است. برای درک این تفاوت، مقاله چرا Core Web Vitals در موبایل با دسکتاپ فرق دارد؟ را مطالعه کنید.

آیا بهینه‌سازی INP یک‌باره است؟

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

آیا افزونه‌های کش بر INP اثر دارند؟

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

پایان‌بندی مهندسی

INP، معیار اصلی پاسخ‌گویی به تعامل کاربر در Core Web Vitals، اثری مستقیم بر تجربه کاربری، نرخ تعامل و نرخ تبدیل دارد. جایگزینی FID با INP، یک تحول بنیادین در نحوه سنجش تجربه پاسخ‌گویی وب است که سایت‌هایی که بر پایه FID بهینه شده بودند را با چالش‌های جدیدی روبرو کرده است.

از منظر مهندسی سطح ارشد، سه اصل در معماری بهینه‌سازی INP تعیین‌کننده است. نخست، طراحی یک لایه سیاست Yield کردن (Yielding Policy) که تعریف کند در چه نقاطی از کد، Main Thread باید برای پاسخ به تعامل آزاد شود؛ این سیاست باید به‌عنوان یک قرارداد مهندسی در تمام تیم‌ها اجرا شود. دوم، پیاده‌سازی یک معماری توزیع کار که محاسبات سنگین را به Web Workerها و Service Workerها منتقل کند تا Main Thread برای پاسخ به تعامل آزاد بماند. سوم، استقرار یک مکانیزم پایش پیوسته که INP را به‌عنوان یک شاخص راهبردی در داشبورد سازمان رصد کند و هر تغییر در کد، افزونه یا معماری را به بازبینی عملکرد متصل نماید. رعایت این سه اصل، INP را از یک عدد فنی به یک قابلیت سازمانی تبدیل می‌کند.

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

اگر در سایت خود تجربه‌ای از بهینه‌سازی INP دارید، برایم جالب است بدانید کدام فاز بیشترین چالش را ایجاد کرد: تأخیر ورودی، زمان پردازش یا تأخیر ارائه. تجربه‌تان را در دیدگاه‌ها بنویسید؛ به‌ویژه اگر راه‌حل خلاقانه‌ای برای کاهش INP در شرایط خاص به کار برده‌اید که می‌تواند برای پروژه‌های بعدی الهام‌بخش باشد. ⚡