اگر تازه سئو را شروع کرده باشی، احتمالاً اسم Core Web Vitals را زیاد شنیدی و شاید هم کمی گیج شده باشی که اینها دقیقاً چی هستند و چرا همه دربارهش حرف میزنند.
سادهاش این است: گوگل یک سری معیار معرفی کرده تا کیفیت تجربه کاربر روی سایت را قابل اندازهگیری کند. یعنی بهجای اینکه فقط حدس بزنیم سایت «حس خوبی» دارد یا نه، با عدد و رقم میفهمیم واقعاً کاربران چه تجربهای دارند.
این ۳ چیز یادت بماند:
- LCP یعنی کاربر چقدر زود «محتوای اصلی» را میبیند (هدف: ≤ 2.5s).
- INP یعنی سایت بعد از تعامل کاربر چقدر سریع واکنش نشان میدهد (هدف: ≤ 200ms).
- CLS یعنی صفحه چقدر ثابت و بدون پرش است (هدف: ≤ 0.1).
اگر همین سه مورد را درست بفهمی و قدمبهقدم بهترشان کنی، هم تجربه کاربر بهتر میشود، هم معمولاً نرخ تبدیل و رضایت بالا میرود، و هم از نظر سئو یک پایه محکمتر میسازی. مهمترین نکته هم این است: بهبود را با داده واقعی بسنج و هر بار فقط چند تغییر مشخص انجام بده تا بفهمی دقیقاً چه چیزی اثر گذاشته است.
این معیارها برای همه مهماند: صاحب کسبوکار، مارکتر، سئوکار و توسعهدهنده. چون اگر سایت کند باشد، موقع کلیک لگ بزند یا صفحه هی بپرد و کاربر اشتباهی روی چیز دیگری بزند، نتیجهاش کاملاً مشخص است: نرخ خروج بالا، کم شدن تبدیل و در بلندمدت افت رشد ارگانیک.
Web Vitals و Core Web Vitals: فرقشان چیست؟
Web Vitals یک ابتکار از طرف گوگل است برای اینکه یک راهنمای یکپارچه بدهد: چه سیگنالهایی برای تجربه کاربر مهماند و چطور باید اندازهگیری شوند. از بین Web Vitals، یک زیرمجموعه مهم وجود دارد به اسم Core Web Vitals که:
- برای همه صفحات وب مهم است (عمومی و همگانی است).
- باید توسط همه صاحبان سایتها اندازهگیری شود.
- در ابزارهای گوگل (مثل Search Console و PageSpeed Insights) پررنگ نمایش داده میشود.
- از دادههای واقعی کاربران (Field Data) هم قابل اندازهگیری است.
Core Web Vitals فعلاً روی ۳ بخش اصلی از تجربه کاربر تمرکز دارد: سرعت بارگذاری، تعاملپذیری و ثبات بصری. معیارهایش هم اینها هستند: LCP، INP و CLS.
سه معیار اصلی Core Web Vitals (به زبان خیلی ساده)
1) LCP: بزرگترین محتوای قابل مشاهده کی لود میشود؟
LCP (Largest Contentful Paint) میگوید: از لحظهای که صفحه شروع به لود شدن میکند، چقدر طول میکشد تا بزرگترین بخش مهم محتوا (مثلاً عکس اصلی، بنر بالای صفحه، یا تیتر بزرگ) روی صفحه دیده شود.
هدف خوب: LCP باید زیر ۲.۵ ثانیه باشد.
مثال عملی: فرض کن یک صفحه محصول داری. کاربر وارد میشود و تا چند ثانیه فقط هدر و یک فضای سفید میبیند و عکس محصول دیر ظاهر میشود. حتی اگر بقیه چیزها بعداً سریع بیاید، کاربر حس میکند سایت کند است. LCP دقیقاً همین حس را عددی میکند.
دلایل رایج LCP بد:
- سرور کند (TTFB بالا) یا هاست ضعیف
- تصاویر بزرگ و بهینهنشده (بهخصوص تصویر هیرو/بنر)
- فایلهای CSS/JS سنگین که رندر را بلوکه میکنند
- فونتهای وب که دیر لود میشوند و نمایش محتوا را عقب میاندازند
راهکارهای کاربردی برای بهتر کردن LCP:
- تصویر اصلی صفحه را سبک کن: فرمتهای جدید مثل WebP/AVIF، فشردهسازی درست، و سایز دقیق (نه اینکه تصویر 3000px را برای نمایش 800px بفرستی).
- Lazy-load را درست استفاده کن: برای تصاویر پایین صفحه عالی است، اما تصویر اصلی بالای صفحه (Hero) را معمولاً lazy نکن چون LCP را خراب میکند.
- کش و CDN: اگر مخاطب از شهرها/کشورهای مختلف دارد، CDN میتواند LCP را خیلی بهتر کند.
- CSS و JS اضافی را کم کن: فایلهای غیرضروری را حذف کن، minify کن، و تا جای ممکن JSهای غیرضروری را defer/async کن.
- سرور را جدی بگیر: گاهی بهترین کار ارتقای هاست یا بهینهسازی بکاند است. اگر TTFB بد باشد، هرچقدر هم فرانت را بزک کنی، LCP کامل درست نمیشود.
2) INP: وقتی کاربر کاری میکند، سایت چقدر سریع واکنش نشان میدهد؟
INP (Interaction to Next Paint) معیار تعاملپذیری است. یعنی وقتی کاربر کلیک میکند، روی دکمه میزند، چیزی تایپ میکند یا با صفحه تعامل دارد، چقدر طول میکشد تا صفحه واقعاً واکنش نشان دهد و نتیجه آن تعامل را نشان بدهد.
هدف خوب: INP باید ۲۰۰ میلیثانیه یا کمتر باشد.
مثال عملی: کاربر روی دکمه «افزودن به سبد خرید» کلیک میکند. اگر دکمه ۱ ثانیه بعد تغییر حالت بدهد یا سبد خرید دیر آپدیت شود، کاربر دوباره کلیک میکند، شک میکند انجام شد یا نه، و تجربهاش خراب میشود. INP این تأخیر را میسنجد.
دلایل رایج INP بد:
- کدهای JavaScript سنگین که Thread اصلی مرورگر را قفل میکنند
- اسکریپتهای شخص ثالث زیاد (چت آنلاین، پاپآپها، آنالیتیکسهای متعدد، تبلیغات و…)
- رندرهای سنگین در فریمورکها (React/Vue/Angular) به خاطر state updateهای زیاد
- کارهای سنگین همزمان با تعامل کاربر (مثل محاسبات یا پردازشهای بزرگ روی کلاینت)
راهکارهای کاربردی برای بهتر کردن INP:
- JS اضافی را کم کن: هر پلاگین/اسکریپتی که واقعاً لازم نیست را حذف کن. خیلی وقتها ۳ تا ابزار مشابه نصب شده!
- کد را تکهتکه (Code Splitting) کن: فقط چیزی که برای همان صفحه لازم است لود شود، نه کل سایت.
- کارهای سنگین را بشکن: اگر یک تابع سنگین داری، آن را به کارهای کوچکتر تقسیم کن تا مرورگر بینشان فرصت رندر داشته باشد.
- اسکریپتهای شخص ثالث را کنترل کن: خیلی از مشکلات INP از بیرون میآید. هر چیزی که اضافه میکنی، هزینه دارد.
- در آزمایشگاه به TBT نگاه کن: در Lighthouse، INP مستقیم اندازهگیری نمیشود (چون کاربر واقعی ندارد)، اما TBT یک نشانه خوب است. اگر TBT را بهتر کنی، معمولاً INP هم بهتر میشود.
3) CLS: چرا صفحه میپرد و جای عناصر عوض میشود؟
CLS (Cumulative Layout Shift) ثبات بصری را میسنجد. یعنی آیا عناصر صفحه هنگام لود شدن جابجا میشوند یا نه. همان اتفاق اعصابخردکنی که میخواهی روی یک لینک بزنی، یک تبلیغ یا تصویر لود میشود و همه چیز میپرد و اشتباهی روی چیز دیگری کلیک میکنی.
هدف خوب: CLS باید ۰.۱ یا کمتر باشد.
مثال عملی: کاربر وارد مقاله میشود و شروع میکند به خواندن. یک دفعه فونت لود میشود و اندازه متن تغییر میکند، یا بنر تبلیغاتی بالا میآید و پاراگرافها پایین میروند. این یعنی CLS بالا.
دلایل رایج CLS بد:
- تصاویر/ویدیوها بدون تعیین width/height (مرورگر نمیداند چقدر فضا رزرو کند)
- تبلیغات یا باکسهایی که دیر اضافه میشوند و فضا از قبل برایشان رزرو نشده
- لود شدن فونت و تغییر شکل متن (FOIT/FOUT)
- درج عناصر جدید در بالای صفحه بدون برنامه (مثل نوار اطلاعیه که ناگهانی ظاهر میشود)
راهکارهای کاربردی برای بهتر کردن CLS:
- برای تصویر و ویدیو فضا رزرو کن: حتماً width/height یا aspect-ratio بده تا قبل از لود شدن، جای عنصر مشخص باشد.
- برای تبلیغات/بنرها جای ثابت تعریف کن: حتی اگر تبلیغ لود نشد، همان فضا حفظ شود تا صفحه نپرد.
- فونتها را بهینه کن: از font-display: swap استفاده کن و در صورت امکان فونتها را preload کن تا دیر نرسند.
- پاپآپ و نوار اعلان را درست طراحی کن: بهجای اینکه محتوا را هل بدهد، میتواند به شکل overlay نمایش داده شود (در صورت مناسب بودن برای UX).
عددهای هدف Core Web Vitals (جمعبندی سریع)
- LCP: کمتر یا مساوی ۲.۵ ثانیه
- INP: کمتر یا مساوی ۲۰۰ میلیثانیه
- CLS: کمتر یا مساوی ۰.۱
نکته مهم: گوگل معمولاً میگوید برای اینکه وضعیت یک صفحه «خوب» حساب شود، بهتر است این اهداف را برای بیشتر کاربران بگیری. معیار رایج برای قضاوت، صدک ۷۵ (75th percentile) است؛ یعنی حداقل ۷۵٪ از بازدیدها باید داخل محدوده خوب باشند. همچنین بهتر است موبایل و دسکتاپ را جدا بررسی کنی چون رفتارشان متفاوت است.
از کجا بفهمیم وضعیت کور وب وایتال سایت ما چطور است؟
خوشبختانه لازم نیست نابغه پرفورمنس باشی. گوگل و کروم ابزارهای خوبی دارند که همین معیارها را نشان میدهند:
- Google Search Console (گزارش Core Web Vitals): برای دید کلی و دستهبندی URLها به خوب/نیازمند بهبود/ضعیف
- PageSpeed Insights: ترکیب داده واقعی کاربران (اگر موجود باشد) + تست آزمایشگاهی
- Chrome DevTools: برای بررسی و دیباگ فنیتر
- Chrome User Experience Report (CrUX): دیتای واقعی کاربران (بهصورت تجمیعی)
یک نکته مهم: ابزارهای «آزمایشگاهی» مثل Lighthouse خیلی مفیدند برای توسعه و جلوگیری از خرابکاریهای جدید، اما جای داده واقعی کاربران را نمیگیرند. چون تجربه واقعی به دستگاه کاربر، اینترنت، و تعامل واقعی بستگی دارد.
بهبود Core Web Vitals
اگر تازهکاری، بهجای اینکه از همان اول وارد هزار تا تنظیم فنی شوی، این مسیر را برو:
- اول از Search Console شروع کن: ببین کدام گروه از صفحات مشکل دارند (مثلاً صفحات محصول یا مقالات).
- بعد یک URL نمونه را با PageSpeed Insights تست کن: ببین مشکل اصلی LCP است یا INP یا CLS.
- اگر LCP بد است: اول تصویر اصلی و سرعت سرور را بررسی کن (معمولاً بیشترین اثر را دارند).
- اگر CLS بد است: معمولاً با چند اصلاح ساده در تصاویر/تبلیغات/فونت خیلی بهتر میشود.
- اگر INP بد است: پلاگینها و اسکریپتهای اضافی را کم کن؛ بعد برو سراغ بهینهسازی JS.
- دوباره اندازهگیری کن: هر تغییر باید با عدد تأیید شود، نه با حس.
برای تیم فنی: اندازهگیری Core Web Vitals با جاوااسکریپت (RUM)
اگر توسعهدهنده یا همکار فنی داری، بهترین کار این است که علاوه بر ابزارهای گوگل، خودت هم داده واقعی کاربران را جمع کنی (Real User Monitoring). کتابخانه رسمی و سبک web-vitals این کار را ساده میکند: میتوانی LCP/INP/CLS را در سایت اندازه بگیری و به یک endpoint آنالیتیکس بفرستی تا بعداً تحلیل کنی.
بعد از جمعآوری داده، باید گزارش بگیری که آیا صفحات در صدک ۷۵ برای هر سه معیار به حد خوب میرسند یا نه.
چند معیار کمکی که بد نیست بشناسی (ولی Core نیستند)
Core Web Vitals فقط این سهتاست، اما چند معیار دیگر هم هستند که برای تحلیل مشکلها کمک میکنند:
- TTFB (زمان پاسخ اولیه سرور): اگر بالا باشد، LCP هم معمولاً ضربه میخورد.
- FCP (اولین نمایش محتوا): برای فهم اینکه صفحه از چه زمانی «شروع به نشان دادن چیزی» میکند مفید است.
- TBT (Total Blocking Time): در Lighthouse میآید و برای مشکلات شبیه INP راهنمای خوبی است.
اینها ممکن است در ابزارها زیاد دیده شوند، اما چون بعضیهایشان «میدانی» (Field) نیستند یا مستقیم نتیجه کاربرمحور را نشان نمیدهند، جزو Core Web Vitals حساب نمیشوند.
آیا این معیارها ثابت میمانند؟ (چرخه عمر معیارها)
گوگل برای معیارها یک چرخه عمر در نظر گرفته: Experimental (آزمایشی)، Pending (در آستانه)، و Stable (پایدار). الان LCP، CLS و INP همگی Stable هستند؛ یعنی معیارهای اصلی و پایدار تجربه کاربر محسوب میشوند.
با این حال، «پایدار» یعنی تغییرات خیلی کم و با اطلاعرسانی است، نه اینکه تا ابد همین میمانند. نمونهاش اینکه FID بازنشسته شد و INP جایگزینش شد تا تعاملپذیری را دقیقتر و جامعتر بسنجد.