PERFORMANCE
Core Web Vitals و معیار جدید INP: چرا سایت سریع دیگر کافی نیست
· ۷ دقیقه · تیم یازیاپ
آخرین بازبینی محتوایی:
INP جای FID را گرفت و معیار سنجش، پاسخگویی واقعی سایت به هر کلیک کاربر است؛ راهنمای عملی رسیدن به محدودهی سبز.

Core Web Vitals در یک نگاه
پاسخ کوتاه: Core Web Vitals سه معیار تجربهی کاربر است — LCP برای سرعت نمایش محتوای اصلی (زیر ۲.۵ ثانیه)، INP برای پاسخگویی به تعامل کاربر (زیر ۲۰۰ میلیثانیه) و CLS برای پایداری چیدمان (زیر ۰.۱). از سال ۲۰۲۴ معیار INP جای FID را گرفت و برخلاف آن، کل تعاملهای کاربر در طول بازدید را میسنجد، نه فقط اولین کلیک را.
به همین دلیل سایتی که در تست سرعت نمرهی خوبی میگیرد ولی بعد از باز شدن، هر کلیک کاربر را با تأخیر جواب میدهد، دیگر «سریع» حساب نمیشود.
| معیار | چه چیزی را میسنجد | محدودهی خوب | نیازمند بهبود |
|---|---|---|---|
| LCP | زمان نمایش بزرگترین محتوای صفحه | زیر ۲.۵ ثانیه | ۲.۵ تا ۴ ثانیه |
| INP | پاسخگویی به تعاملهای کاربر | زیر ۲۰۰ میلیثانیه | ۲۰۰ تا ۵۰۰ میلیثانیه |
| CLS | پایداری چیدمان صفحه | زیر ۰.۱ | ۰.۱ تا ۰.۲۵ |
INP دقیقاً چه چیزی را میسنجد؟
INP فاصلهی میان تعامل کاربر (کلیک، لمس، فشردن کلید) تا لحظهی رسم تغییر بصری متناظر است و مقدار زیر ۲۰۰ میلیثانیه خوب محسوب میشود. برخلاف FID، کل تعاملهای یک بازدید را میسنجد، نه فقط اولین تعامل را.
INP فاصلهی میان تعامل کاربر (کلیک، لمس، فشردن کلید) تا لحظهای است که مرورگر تغییر بصری متناظر را روی صفحه رسم میکند. اگر رشتهی اصلی جاوااسکریپت مشغول باشد، این فاصله بلند میشود و کاربر حس میکند سایت «گیر کرده».
رایجترین دلایل INP بد در سایتهای فارسی: اسکریپتهای تبلیغاتی و آنالیتیکس سنگین، رندر دوبارهی بیمورد کل صفحه بعد از هر تغییر کوچک حالت، و اجرای محاسبات سنگین (فیلتر و مرتبسازی لیستهای بزرگ) روی رشتهی اصلی.
راهکارهای عملی
برای بهبود INP کارهای طولانی جاوااسکریپت را به قطعههای کوتاه بشکنید، اسکریپتهای شخص ثالث را تنبل بارگذاری یا حذف کنید، رندرهای اضافی را کم کنید و محاسبات سنگین را به Web Worker یا سرور ببرید. این اصلاحهای هدفمند معمولاً بدون بازنویسی کامل جواب میدهند.
بهبود INP معمولاً به بازنویسی کامل نیاز ندارد؛ چند اصلاح هدفمند اثر بزرگی دارد:
- شکستن کارهای طولانی جاوااسکریپت به قطعههای کوتاه و بهتعویقانداختن کارهای غیرضروری
- بارگذاری تنبل اسکریپتهای شخص ثالث و حذف اسکریپتهایی که هیچکس گزارششان را نمیخواند
- کاهش رندرهای اضافی با مدیریت درست حالت و memoization
- انتقال محاسبات سنگین به Web Worker یا به سمت سرور
- رزرو ابعاد تصاویر و بنرها برای جلوگیری از پرش چیدمان (CLS)
- رندر سمت سرور برای اینکه محتوای اصلی زودتر و بدون انتظار جاوااسکریپت دیده شود
چطور اندازه بگیریم؟
معیار قضاوت گوگل دادهی میدانی کاربران واقعی (CrUX و گزارش Core Web Vitals در Search Console) است، نه نمرهی Lighthouse. پس از هر تغییر چند هفته صبر کنید تا اثرش در دادهی میدانی دیده شود.
دادهی آزمایشگاهی (Lighthouse) برای پیدا کردن مشکل خوب است، اما قضاوت گوگل بر اساس دادهی میدانی کاربران واقعی است. گزارش Core Web Vitals در Search Console و دادهی CrUX را مبنا بگیرید و بعد از هر تغییر، چند هفته صبر کنید تا اثرش در دادهی میدانی دیده شود.
اندازهگیری روی موبایل و اینترنت متوسط را جدی بگیرید؛ بیشتر کاربران ایرانی سایت شما را روی گوشی و شبکهی ناپایدار باز میکنند، نه روی لپتاپ با اینترنت پرسرعت.
چه زمانی ارزش سرمایهگذاری دارد؟
اگر فروشگاه اینترنتی دارید یا بخش زیادی از ترافیک شما ارگانیک است، بهبود Core Web Vitals مستقیماً روی نرخ تبدیل و نرخ خروج اثر میگذارد. برای سایتهای معرفیمحور کمترافیک اولویت پایینتری دارد، اما رعایت اصول از ابتدای پروژه تقریباً بدون هزینه است.
اگر سایت فروشگاهی دارید یا بخش زیادی از ترافیک شما از جستجوی ارگانیک میآید، بهبود Core Web Vitals مستقیماً روی نرخ تبدیل و نرخ خروج اثر میگذارد. برای سایتهای معرفیمحور کمترافیک، اولویت پایینتری دارد اما رعایت اصول از ابتدای پروژه تقریباً بدون هزینه است.