راهنمای عملی بهبود Core Web Vitals برای سایت‌های پرفشار

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

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

Core Web Vitals چیست و چرا باید به آن اهمیت دهید؟

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

سه شاخص اصلی عبارتند از:

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

آستانه قبولی برای هر شاخص به این صورت است:

• LCP: کمتر از ۲.۵ ثانیه (ضعیف: بیشتر از ۴ ثانیه)
• INP: کمتر از ۲۰۰ میلی‌ثانیه (ضعیف: بیشتر از ۵۰۰ میلی‌ثانیه)
• CLS: کمتر از ۰.۱ (ضعیف: بیشتر از ۰.۲۵)

نکته مهم: گوگل برای گزارش در Search Console از داده‌های میدانی (Field Data) استفاده می‌کند که از مرورگر کاربران واقعی جمع‌آوری شده است. بنابراین، بهبود صرفاً در محیط تست کافی نیست؛ باید تجربه واقعی کاربران را بهبود دهید.

شاخص LCP: بزرگ‌ترین عنصر صفحه چقدر سریع بارگذاری می‌شود؟

LCP لحظه‌ای را اندازه می‌گیرد که بزرگ‌ترین عنصر محتوایی (تصویر، ویدیو، بلوک متن) در viewport کاربر رندر می‌شود. این شاخص معمولاً تحت تأثیر سه عامل اصلی است: سرعت پاسخ سرور (TTFB)، زمان بارگذاری منابع حیاتی، و زمان رندر سمت کلاینت.

چگونه LCP را ریشه‌یابی کنیم؟

اولین قدم، شناسایی عنصر LCP است. در Chrome DevTools، تب Performance را باز کنید و یک ضبط انجام دهید. در بخش Timings، بزرگ‌ترین عنصر مشخص شده است. همچنین می‌توانید از دستور زیر در کنسول استفاده کنید:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(entry.element, entry.startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

بعد از شناسایی عنصر LCP، این مراحل را به ترتیب اولویت انجام دهید:

1. بهبود TTFB: اگر زمان پاسخ سرور بالای ۶۰۰ میلی‌ثانیه است، مشکل از سرور است. استفاده از CDN، فعال‌سازی HTTP/2 و HTTP/3، و بهینه‌سازی کوئری‌های دیتابیس را بررسی کنید.
2. بارگذاری تصویر LCP: اگر عنصر LCP یک تصویر است، آن را با فرمت WebP یا AVIF ارائه دهید و از fetchpriority="high" استفاده کنید:

<img src="hero.webp" fetchpriority="high" width="1200" height="630" alt="توضیح تصویر">

1. حذف جاوااسکریپت مسدودکننده رندر: اسکریپت‌هایی که قبل از رندر عنصر LCP اجرا می‌شوند را با defer یا async بارگذاری کنید.
2. پیش‌اتصال به منابع حیاتی: از <link rel="preconnect"> برای دامنه‌هایی که فونت یا API را سرو می‌کنند استفاده کنید.

شاخص INP: پاسخگویی صفحه به تعاملات کاربر

INP جایگزین FID شده و معیار دقیق‌تری است: به جای اندازه‌گیری فقط اولین تعامل، تمام تعاملات کاربر در طول بازدید را بررسی می‌کند و بدترین (یا نزدیک به بدترین) مقدار را گزارش می‌دهد. این شاخص مستقیماً به طول عمر ترد اصلی (Main Thread) وابسته است.

چرا INP شما ضعیف است؟

دلایل اصلی INP بالا عبارتند از:

• جاوااسکریپت سنگین که ترد اصلی را برای مدت طولانی مسدود می‌کند
• لیسنرهای رویداد پیچیده که پردازش آن‌ها زمان‌بر است
• رندرهای مکرر DOM که باعث Layout Thrashing می‌شوند
• اسکریپت‌های شخص ثالث (تبلیغات، چت‌ویجت‌ها، آنالیتیکس) که در ترد اصلی اجرا می‌شوند

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

اولین قدم، اندازه‌گیری طولانی‌ترین تاسک‌ها (Long Tasks) است. در DevTools، تب Performance را باز کنید و بخش Main را بررسی کنید. تاسک‌هایی که بیش از ۵۰ میلی‌ثانیه طول می‌کشند، مشکل‌ساز هستند.

سپس این تکنیک‌ها را اعمال کنید:

1. تقسیم کد (Code Splitting): جاوااسکریپت را به چند باندل کوچک تقسیم کنید و فقط کد لازم برای صفحه فعلی را بارگذاری کنید. با Webpack یا Vite می‌توانید از import() داینامیک استفاده کنید.
2. تعویق کارهای غیرضروری: از requestIdleCallback برای اجرای کارهای کم‌اهمیت در زمان بیکاری مرورگر استفاده کنید:

if ('requestIdleCallback' in window) {
  requestIdleCallback(() => {
    // بارگذاری ویجت‌های غیرضروری
    loadChatWidget();
  }, { timeout: 2000 });
}

1. کاهش کارهای شخص ثالث: اسکریپت‌های تبلیغاتی و آنالیتیکس را با defer بارگذاری کنید و از IntersectionObserver برای بارگذاری تنها زمانی که کاربر به آن بخش اسکرول می‌کند استفاده کنید.
2. بهینه‌سازی DOM: تعداد نودهای DOM را کاهش دهید. صفحاتی با بیش از ۱۵۰۰ نود، به‌طور قابل توجهی کندتر رندر می‌شوند.

شاخص CLS: ثبات بصری صفحه

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

منابع اصلی CLS بالا

• تصاویر و ویدیوها بدون ابعاد مشخص (width و height)
• فونت‌های وب که با FOIT/FOUT بارگذاری می‌شوند
• تبلیغات یا ویجت‌هایی که بعد از رندر اولیه درج می‌شوند
• انیمیشن‌های CSS که ویژگی‌های layout را تغییر می‌دهند

راهکارهای عملی برای CLS صفر

این چک‌لیست را به‌ترتیب اجرا کنید:

1. ابعاد صریح برای همه رسانه‌ها: برای هر تصویر و ویدیو، ویژگی‌های width و height را مشخص کنید. حتی اگر CSS آن‌ها را responsive می‌کند، ابعاد اصلی را در HTML بنویسید:

<img src="banner.jpg" width="800" height="450" style="width:100%; height:auto;" alt="بنر">

1. فضای رزرو برای تبلیغات: اگر تبلیغات را بعد از بارگذاری صفحه درج می‌کنید، یک کانتینر با ابعاد مشخص از قبل در HTML قرار دهید:

<div class="ad-slot" style="min-height: 250px; width: 100%;"></div>

1. استفاده از font-display: swap: این ویژگی باعث می‌شود متن ابتدا با فونت سیستمی نمایش داده شود و بعد از بارگذاری فونت وب، جایگزین شود. برای جلوگیری از جابه‌جایی، می‌توانید از size-adjust در @font-face استفاده کنید.
2. انیمیشن‌های امن: فقط از ویژگی‌های transform و opacity برای انیمیشن استفاده کنید، نه width، height یا top.

ابزارهای اندازه‌گیری و مانیتورینگ Core Web Vitals

برای بهبود مؤثر، باید اندازه‌گیری مداوم داشته باشید. این ابزارها را به‌صورت ترکیبی استفاده کنید:

• PageSpeed Insights: ترکیبی از داده‌های میدانی (CrUX) و آزمایشگاهی (Lighthouse) را نشان می‌دهد.
• Chrome DevTools: برای دیباگ عمیق و شناسایی عنصر LCP و تاسک‌های طولانی.
• web-vitals JavaScript library: برای مانیتورینگ Real User Monitoring (RUM) در سایت خودتان:

import {onLCP, onINP, onCLS} from 'web-vitals';

onLCP((metric) => {
  console.log('LCP:', metric.value);
  // ارسال به آنالیتیکس
});
onINP((metric) => console.log('INP:', metric.value));
onCLS((metric) => console.log('CLS:', metric.value));

• CrUX API: برای مشاهده داده‌های تاریخی و مقایسه با رقبا.

استراتژی بهبود گام‌به‌گام برای سایت‌های پرفشار

اگر سایت شما ترافیک بالایی دارد، تغییرات را یک‌باره اعمال نکنید. این ریسک را به‌همراه دارد که یک اشتباه کوچک، تجربه کاربری را برای هزاران نفر خراب کند. به‌جای آن، این استراتژی را دنبال کنید:

1. هفته اول — اندازه‌گیری و شناسایی: داده‌های CrUX را برای ۲۸ روز گذشته بررسی کنید. صفحاتی که در آستانه ضعیف قرار دارند را اولویت‌بندی کنید.
2. هفته دوم — رفع مشکلات زیرساختی: TTFB، کش سمت سرور، و CDN را بررسی کنید. اگر سایت روی سرور اشتراکی است، ارتقا به یک پلن اختصاصی یا VPS را در نظر بگیرید. (در این زمینه، سرورنت گزینه‌های متنوعی برای میزبانی پرفشار ارائه می‌دهد.)
3. هفته سوم — بهینه‌سازی دارایی‌ها: تصاویر را به WebP تبدیل کنید، فونت‌ها را زیرمجموعه‌سازی کنید، و CSS/JS را مینیفای کنید.
4. هفته چهارم — بهینه‌سازی جاوااسکریپت: کدهای شخص ثالث را حذف یا تعویق بیندازید و تقسیم کد را پیاده‌سازی کنید.
5. مانیتورینگ مداوم: بعد از هر تغییر، داده‌های CrUX را برای ۷ روز بررسی کنید. بهبودها معمولاً بعد از ۲۸ روز در گزارش گوگل منعکس می‌شوند.

جمع‌بندی

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