Core Web Vitals چیست و چطور سرعت سایت را برای سئو بهبود دهیم

گوگل از سال ۲۰۲۱ معیارهای Core Web Vitals را وارد سیگنال‌های رتبه‌بندی کرد و از آن زمان فقط ترکیب معیارها عوض شده، نه اهمیتشان. مشکل بیشتر راهنماهای فارسی این است که هر سه معیار را یک‌کاسه می‌کنند و وعده می‌دهند نصب یک CDN همه را درست می‌کند. این‌طور نیست؛ اینجا مشخص می‌کنیم کدام معیار با زیرساخت حل می‌شود و کدام فقط با کد.

Core Web Vitals دقیقاً چه چیزی را می‌سنجد؟

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

معیار	آستانه «خوب»	چه چیزی را می‌سنجد	CDN چقدر کمک می‌کند؟
LCP	2.5s یا کمتر	زمان تا رندر بزرگ‌ترین عنصر بصری داخل viewport	زیاد — مستقیماً روی TTFB و زمان دریافت منابع اثر می‌گذارد
INP	200ms یا کمتر	تأخیر پاسخ صفحه به تعامل کاربر (کلیک، تپ، تایپ)	کم و غیرمستقیم — گلوگاه، JavaScript روی main thread است
CLS	0.1 یا کمتر	مجموع جابه‌جایی‌های ناگهانی و غیرمنتظره چیدمان	تقریباً هیچ — مسئله در HTML و CSS خودتان است

کافی است یکی از این سه ضعیف باشد تا آن URL در گزارش سرچ کنسول از گروه «خوب» بیرون بیفتد، حتی اگر دو معیار دیگر عالی باشند.

LCP و آن چیزی که واقعاً خرابش می‌کند

LCP را می‌شود به چهار تکه شکست: زمان تا اولین بایت (TTFB)، تأخیر تا کشف منبع اصلی، مدت دانلود آن منبع، و تأخیر رندر. عادت رایج این است که همه مستقیم سراغ فشرده‌سازی تصویر می‌روند، در حالی که در خیلی از سایت‌های ایرانی سهم غالب LCP همان TTFB است.

TTFB؛ جایی که CDN بیشترین اثر را دارد

TTFB یعنی فاصله ارسال درخواست تا رسیدن اولین بایت پاسخ: رزولوشن DNS، برقراری اتصال TCP، handshake مربوط به TLS، مسیر شبکه تا مبدأ، و زمان تولید پاسخ روی سرور. وقتی پاسخ از کش لبه سرو می‌شود، سه مورد آخر عملاً حذف می‌شوند و مرورگر بدون اینکه به مبدأ شما دست بزند جواب می‌گیرد. سازوکار دقیق این کش و هدرهای مؤثر بر آن را در مقاله نحوه کار کش در CDN توضیح داده‌ایم.

سه چیز TTFB را در عمل نجات می‌دهد:

• کش لبه با سیاست درست — در nsin سیاست کش per-rule تعریف می‌شود: صفحات دسته‌بندی و فایل‌های استاتیک کش می‌شوند و مسیر سبد خرید یا پنل کاربری دست‌نخورده رد می‌شود. بعد از هر به‌روزرسانی هم purge کش کار را تمام می‌کند.
• خاتمه‌یافتن TLS روی لبه — گواهی SSL رایگان که خودکار تمدید می‌شود از همان لبه سرو می‌شود، پس رفت‌وبرگشت‌های handshake نزدیک‌تر به کاربر تمام می‌شوند. جزئیاتش در راهنمای گواهی SSL رایگان آمده است.
• پایداری مسیر — TTFB بد همیشه یعنی سرور کند نیست؛ گاهی اتصال وسط کار قطع می‌شود و مرورگر مجبور به retry است. برای سایت ایرانی با مخاطب خارج از کشور، همین بخش تعیین‌کننده است. failover بین چند مبدأ و سرو صفحه کش‌شده وقتی مبدأ در دسترس نیست، دقیقاً برای همین ساخته شده‌اند.

منابعی که دیر کشف می‌شوند

بعد از TTFB، شایع‌ترین دلیل LCP بد این است که تصویر اصلی صفحه دیر کشف می‌شود: با loading="lazy" علامت خورده، داخل یک کامپوننت کلاینتی رندر می‌شود، یا پشت یک فایل CSS سنگین render-blocking گیر کرده است. راه‌حل‌ها ساده‌اند — fetchpriority="high" روی همان تصویر، preload فونت اصلی، حذف lazy-load از هر چیزی داخل viewport اول، و کوتاه‌کردن زنجیره ریدایرکت‌ها.

INP؛ اینجا CDN کاری از دستش برنمی‌آید

INP جانشین FID شده و برخلاف آن، کل چرخه تعامل را می‌سنجد: از لحظه کلیک تا لحظه‌ای که فریم بعدی روی صفحه نقاشی می‌شود. اگر main thread مشغول اجرای یک تسک طولانی باشد، مرورگر نمی‌تواند به کاربر پاسخ بدهد و عدد INP بالا می‌رود. هیچ لایه شبکه‌ای این را حل نمی‌کند؛ مشکل بعد از رسیدن بایت‌ها رخ می‌دهد.

مقصرهای همیشگی: hydration سنگین در فریم‌ورک‌های SPA، اسکریپت‌های شخص ثالث (چت آنلاین، تگ تبلیغاتی، چند ابزار آنالیتیکس هم‌زمان)، هندلرهایی که با هر کلیک محاسبه سنگین انجام می‌دهند، و DOM بیش از حد بزرگ. کاری که جواب می‌دهد: code splitting، defer کردن اسکریپت‌های غیرضروری، شکستن تسک‌های طولانی با scheduler.yield() یا حتی setTimeout، و حذف ابزارهایی که کسی به گزارششان نگاه نمی‌کند.

تنها اثر غیرمستقیم CDN این است که وقتی منابع سریع‌تر و بدون retry می‌رسند، پنجره هم‌پوشانی JavaScript سنگین با اولین تعامل کاربر کوچک‌تر می‌شود. این کمک است، نه راه‌حل.

CLS؛ فقط در کد حل می‌شود

CLS مجموع جابه‌جایی‌های چیدمان است که کاربر انتظارشان را ندارد. چهار منبع اصلی دارد: تصاویر و iframeهای بدون width/height یا aspect-ratio، بنرها و تبلیغاتی که بعد از لود به بالای صفحه تزریق می‌شوند، فونت‌هایی که دیر می‌رسند و متن را با متریک متفاوت دوباره می‌چینند، و انیمیشن روی خصوصیت‌های چیدمانی به‌جای transform.

راه‌حل‌ها همه سمت کد هستند: ابعاد صریح برای هر مدیای بالای صفحه، رزرو فضای ثابت برای اسلات تبلیغ حتی وقتی خالی است، font-display: swap همراه با size-adjust، و پرهیز از تزریق نوار اعلان بالای محتوای رندرشده. تنها نقش لبه اینجا این است که تحویل سریع‌تر فونت پنجره جابه‌جایی را کوتاه می‌کند — همین و بس.

اگر LCP خراب است اول به زیرساخت نگاه کنید؛ اگر INP و CLS خراب‌اند، هیچ لایه‌ای بیرون از مرورگر نجاتتان نمی‌دهد.

داده میدانی یا داده آزمایشگاهی؟

این تفکیک را جدی بگیرید:

• داده میدانی (CrUX) — از کاربران واقعی کروم جمع می‌شود، پنجره‌ای متحرک به طول ۲۸ روز دارد و همان چیزی است که گوگل در رتبه‌بندی به کار می‌برد. برای سایت کم‌ترافیک ممکن است اصلاً داده کافی جمع نشود.
• داده آزمایشگاهی (Lighthouse) — یک اجرای شبیه‌سازی‌شده روی یک دستگاه و شبکه فرضی؛ برای اشکال‌زدایی عالی است، برای قضاوت درباره وضعیت واقعی نه. مهم‌تر اینکه INP اصلاً در آزمایشگاه قابل اندازه‌گیری نیست و Lighthouse به‌جایش TBT را تخمین می‌زند.

برای سایت ایرانی این شکاف بزرگ‌تر است: تست شما از تهران و روی اینترنت پرسرعت اجرا می‌شود، ولی صدک ۷۵ واقعی شامل موبایل در ساعات شلوغ و بازدیدکننده‌ای است که از خارج و روی مسیری ناپایدار وصل می‌شود. همان مسیر ناپایدار را خزنده گوگل هم تجربه می‌کند؛ این موضوع را در دسترسی Googlebot از ایران و ارتباطش با رتبه را در چرا CDN رتبه سئو را بهبود می‌دهد بررسی کرده‌ایم.

سمت سرور را با لاگ درخواست‌های زنده و تحلیل ترافیک پنل ببینید (کدام درخواست از کش خورده و کدام به مبدأ رفته)، و برای متریک‌های مرورگر کتابخانه web-vitals را روی سایت بگذارید.

چک‌لیست عملی

• ۱. اول TTFB را اندازه بگیرید؛ گوگل TTFB زیر ۸۰۰ میلی‌ثانیه را «خوب» می‌داند، پس اگر عدد شما مرتب بالاتر از این است، اول سراغ زیرساخت و کش بروید، نه تصویر.
• ۲. سیاست کش را per-rule بنویسید: استاتیک با TTL طولانی، صفحات عمومی با TTL کوتاه، مسیرهای کاربر لاگین‌کرده کاملاً bypass.
• ۳. عنصر LCP را شناسایی کنید، از حالت lazy درش بیاورید و fetchpriority="high" بدهید.
• ۴. فونت متن اصلی را preload کنید و فقط woff2 را نگه دارید.
• ۵. زنجیره ریدایرکت را به حداکثر یک مرحله برسانید.
• ۶. برای هر تصویر و iframe ابعاد صریح یا aspect-ratio بگذارید.
• ۷. اسکریپت‌های شخص ثالث را فهرست کنید و هرچه توجیه ندارد حذف کنید.
• ۸. باندل JavaScript را split کنید و تسک‌های طولانی‌تر از 50ms را بشکنید.
• ۹. بعد از هر به‌روزرسانی محتوا purge کش را بزنید تا نسخه قدیمی سرو نشود.
• ۱۰. دو هفته صبر کنید و بعد به داده میدانی نگاه کنید، نه به نمره Lighthouse بعد از دیپلوی.

پرسش‌های متداول

آیا Core Web Vitals واقعاً روی رتبه گوگل تأثیر دارد؟

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

چرا نمره PageSpeed سایتم بالاست ولی سرچ کنسول می‌گوید ضعیف؟

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

CDN چقدر LCP سایت را بهتر می‌کند؟

بستگی دارد چه سهمی از LCP شما TTFB باشد. اگر صفحه از کش لبه سرو شود آن سهم تقریباً حذف می‌شود؛ اما اگر مقصر تصویر ۳ مگابایتی یا CSS مسدودکننده باشد، CDN فقط همان فایل سنگین را سریع‌تر تحویل می‌دهد.

INP سایت وردپرسی‌ام بالاست، از کجا شروع کنم؟

از افزونه‌ها. هر افزونه‌ای که JavaScript به فرانت تزریق می‌کند یک مظنون است. یکی‌یکی غیرفعالشان کنید و در تب Performance کروم دنبال long taskها بگردید؛ معمولاً دو سه افزونه مقصرند.

قدم بعدی

ترتیب کار روشن است: اول TTFB و کش، چون بیشترین بازده را دارد و به تغییر کد نیاز ندارد؛ بعد تصویر و فونت؛ در آخر JavaScript. برای شروع دامنه را در پنل nsin اضافه کنید — هر دامنه جدید ۷ روز نسخه کامل Enterprise را رایگان دارد و همین بازه برای مقایسه TTFB قبل و بعد کافی است. جزئیات قواعد کش، TTL و purge هم در مستندات آمده است.