راهنمای کامل Core Web Vitals برای سرعت سایت

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

چرا این سه معیار کنار هم معنا دارند

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

۱. LCP — سرعت نمایش بزرگ‌ترین عنصر

LCP می‌گوید کاربر چه زمانی بزرگ‌ترین عنصر دیداری صفحه را می‌بیند؛ معمولاً تصویر اصلی مقاله یا تیتر بزرگ صفحه. مقدار قابل قبول زیر ۲.۵ ثانیه است.

کارهایی که واقعاً اثر دارند:

• تصویر اصلی صفحه را با priority یا fetchpriority="high" بارگذاری کنید تا از بقیه تصاویر جلو بیفتد
• تصویر LCP را با srcset در اندازه‌های مختلف سرو کنید تا موبایل نسخه سنگین را دانلود نکند
• فونت‌ها را از قبل بارگذاری کنید (preconnect و font-display: swap)
• CSS بحرانی را در ابتدا و بقیه را با تأخیر بارگذاری کنید
• تا حد امکان از رندر سمت سرور یا تولید استاتیک استفاده کنید تا مرورگر منتظر جاوااسکریپت نماند

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

۲. INP — پاسخ‌دهی به تعامل

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

• محاسبات سنگین را به وب ورکر منتقل کنید
• لیست‌های بلند را مجازی‌سازی کنید تا رندر هم‌زمان هزار ردیف رخ ندهد
• از re-render های غیرضروری در کامپوننت‌ها بپرهیزید و وابستگی‌های افکت‌ها را دقیق بنویسید
• کارهای غیرحیاتی را در requestIdleCallback یا با تأخیر انجام دهید
• حجم جاوااسکریپت را کم کنید؛ هر کیلوبایت اضافه، زمان پردازش اضافه است

۳. CLS — پایداری چیدمان

CLS یعنی تکان خوردن عناصر هنگام بارگذاری. کاربر می‌خواهد روی دکمه بزند و دقیقاً همان لحظه تصویری بالای صفحه جا باز می‌کند. مقدار قابل قبول زیر ۰.۱ است.

• برای تصاویر حتماً width و height یا aspect-ratio تعیین کنید
• فضای ثابت برای بنرها، تبلیغات و پیام‌های هشدار رزرو کنید
• فونت را با preload بارگذاری کنید تا متن ناگهان جابه‌جا نشود
• عناصر شناور را در جریان عادی صفحه نگه دارید و از پوشاندن محتوا با position: fixed بپرهیزید
• انیمیشن‌ها را روی transform و opacity بنویسید، نه روی ویژگی‌هایی که چیدمان را تغییر می‌دهند

قبل از بهینه‌سازی، اندازه‌گیری کنید

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

ابزارهای پایه:

1. Lighthouse برای یک بررسی کلی سریع و فهرست فرصت‌ها
2. PageSpeed Insights برای دیدن داده واقعی کاربران (CrUX) در کنار آزمایش آزمایشگاهی
3. Chrome DevTools → Performance برای فهم اینکه کدام بخش کد زمان می‌گیرد
4. PerformanceObserver در کد خودتان برای ثبت LCP، INP و CLS واقعی کاربران و پایش تغییرات پس از هر انتشار

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

کارهایی که همیشه نتیجه می‌دهد

1. تصاویر را در فرمت مدرن (AVIF/WebP) و در ابعاد درست سرو کنید
2. کد را به بخش‌های کوچک تقسیم کنید و هر بخش را وقتی لازم شد بارگذاری کنید
3. درخواست‌های شبکه را حذف یا ادغام کنید؛ هر درخواست یک رفت‌وبرگشت کامل است
4. کتابخانه‌های غیرضروری را حذف کنید، به‌ویژه کتابخانه‌های بزرگ که برای یک تابع اضافه شده‌اند
5. از کش مرورگر و CDN برای فایل‌های ثابت با هدرهای مناسب استفاده کنید

جمع‌بندی

بهینه‌سازی سرعت یک کار یک‌باره نیست؛ یک چرخه است: اندازه‌گیری، رفع بزرگ‌ترین گلوگاه، انتشار، اندازه‌گیری مجدد. اگر می‌خواهید از پایه این اصول را در طراحی واقعی تمرین کنید، پروژه آماده فروشگاهی React + Convex یک اپلیکیشن واقعی با رابط ریسپانسیو است که می‌توانید همین اصول را روی آن اندازه‌گیری و تمرین کنید. برای بخش جاوااسکریپت، کاهش re-render ها بیشترین اثر را دارد؛ با پروفایلر مرورگر کامپوننت‌های سنگین را پیدا کنید و با تقسیم‌بندی و حافظه‌سازی سبک‌ترشان کنید.