بخش Core Web Vitals در سرچ کنسول گوگل و نحوه مدیریت آن

بذارید از همون اول رک بگم: بخش Core Web Vitals توی سرچ کنسول یکی از اون قسمت‌هاییه که خیلی‌ها یه نگاه بهش می‌ندازن، یه سری نمودار قرمز و سبز می‌بینن، می‌گن «خب حالا؟» و می‌بندنش. ولی همین بخش دقیقاً داره بهتون می‌گه گوگل تجربه‌ی کاربرای سایتتون رو چطور می‌بینه.

اگه اسم قبلی این بخش یادتون باشه، بهش می‌گفتن Speed. یعنی گوگل صاف و ساده می‌گفت «سرعت». ولی بعد اسمش رو عوض کرد به Core Web Vitals، و این تغییر اسم الکی نبود. گوگل داشت می‌گفت قضیه فقط سرعت لود نیست؛ قضیه اینه که کاربر وقتی وارد صفحه‌ی شما می‌شه چه حسی داره. صفحه سریع میاد بالا؟ وقتی می‌خواد روی دکمه کلیک کنه، سایت جواب می‌ده یا هنگه؟ محتوا وسط خوندن یهو نمی‌پره پایین؟

توی این مقاله قدم‌به‌قدم می‌ریم سراغ اینکه این بخش چی رو نشون می‌ده، هر عددش یعنی چی، و مهم‌تر از همه، وقتی گزارش قرمز شد باید دقیقاً چیکار کنید.

Core Web Vitals چیست

Core Web Vitals یه مجموعه‌ی سه‌تایی از معیارهاست که گوگل باهاش کیفیت تجربه‌ی کاربر رو اندازه می‌گیره. همین. نه بیشتر، نه کمتر.

نکته‌ی مهمش اینجاست که این سه معیار از داده‌ی واقعی کاربرا میاد، نه از یه تست شبیه‌سازی‌شده. یعنی گوگل داره رفتار واقعی آدم‌هایی که با مرورگر کروم اومدن توی سایت شما رو جمع می‌کنه و بر اساس اون بهتون نمره می‌ده. به این داده می‌گن داده‌ی میدانی یا Field Data که از دیتاست کروم به اسم CrUX میاد.

تفاوت Core Web Vitals با گزارش قدیمی Speed چیست؟

گزارش قدیمی بیشتر روی «چقدر طول می‌کشه صفحه لود بشه» تمرکز داشت. Core Web Vitals ولی سه تا سؤال متفاوت می‌پرسه:

۱. محتوای اصلی صفحه کِی به کاربر نشون داده می‌شه؟ ۲. وقتی کاربر با صفحه کار می‌کنه، صفحه چقدر سریع جواب می‌ده؟ ۳. آیا چیزی توی صفحه بی‌خبر جابه‌جا می‌شه و کاربر رو اذیت می‌کنه؟

روی رتبه تاثیر دارد؟

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

جایی که واقعاً به دردتون می‌خوره اینه: وقتی دو تا صفحه از نظر کیفیت محتوا تقریباً هم‌ترازن، اون که تجربه‌ی کاربری بهتری داره جلو می‌افته. تازه، جدا از سئو، سایت سریع‌تر یعنی نرخ خروج کمتر و فروش بیشتر. این خودش به‌تنهایی دلیل کافیه.

سه شاخص اصلی Core Web Vitals

حالا وقتشه به ۳ شاخصه اصلی ابزار Core Web Vitals:

LCP یا Largest Contentful Paint

LCP بهتون می‌گه بزرگ‌ترین عنصر توی بخش قابل‌مشاهده‌ی صفحه (معمولاً تصویر شاخص یا تیتر اصلی) چقدر طول می‌کشه تا نمایش داده بشه.

فرض کنید کاربر روی لینکتون کلیک کرده. LCP یعنی چند ثانیه بعدش می‌تونه بگه «آهان، اومدم توی صفحه‌ی درست».

INP یا Interaction to Next Paint

اینجا یه نکته‌ی مهم هست که خیلی‌ها هنوز به‌روز نکردن: قبلاً شاخص سوم FID بود، ولی از سال ۲۰۲۴ گوگل رسماً FID رو بازنشسته کرد و INP جاش نشست.

INP یعنی وقتی کاربر روی یه چیزی کلیک می‌کنه یا چیزی تایپ می‌کنه، چقدر طول می‌کشه تا صفحه واکنش نشون بده. اون حالتی که روی دکمه‌ی منو می‌زنید و یه لحظه هیچی نمی‌شه و فکر می‌کنید کلیکتون نگرفته؟ اون یعنی INP بد.

CLS یا Cumulative Layout Shift

CLS اندازه می‌گیره که عناصر صفحه هنگام لود شدن چقدر بی‌خبر جابه‌جا می‌شن.

یه مثال آشنا: دارید یه مقاله می‌خونید، یهو یه تبلیغ بالای صفحه لود می‌شه و کل متن می‌پره پایین. یا می‌خواید روی «ادامه‌ی مطلب» بزنید، دقیقاً همون لحظه دکمه جابه‌جا می‌شه و روی چیز دیگه‌ای کلیک می‌کنید. این‌ها همه CLS بالا هستن.

یه تذکر مهم: CLS واحد زمانی نداره. یعنی «۰.۱ ثانیه» غلطه. CLS یه امتیاز بدون واحده که از ضرب میزان جابه‌جایی در فاصله‌ی جابه‌جایی به دست میاد. خیلی از مقاله‌های فارسی این رو اشتباه نوشتن.

چطور به این بخش دسترسی پیدا کنیم؟

توی سرچ کنسول، از منوی سمت چپ برید به بخش Core Web Vitals. دو تا گزارش جدا می‌بینید: یکی Mobile و یکی Desktop.

چرا موبایل و دسکتاپ جدا هست؟

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

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

سه وضعیت Poor، Needs Improvement و Good

• Poor (قرمز): ضعیف. این‌ها اولویت اولتونن.
• Needs Improvement (نارنجی): بدک نیست ولی به حد استاندارد نرسیده.
• Good (سبز): مشکلی نداره.

یه نکته که خیلی‌ها گیر می‌کنن: گوگل برای اینکه یه URL رو «خوب» حساب کنه، صدک ۷۵ام بازدیدها رو نگاه می‌کنه. یعنی باید ۷۵ درصد بازدیدهای اون صفحه توی محدوده‌ی خوب باشه. پس اگه چند تا کاربر با اینترنت افتضاح اومدن، دنیا خراب نمی‌شه.

چرا بعضی وقت‌ها گزارش‌هایم خالی هست؟

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

تحلیل خطاها و گروه‌بندی URLها

وقتی توی همین صفحه اسکرول کنید، لیست خطاها رو با جزئیات می‌بینید. مثلاً می‌نویسه «CLS issue: more than 0.25 (mobile)» و کنارش تعداد صفحات درگیر.

روی هر خطا که کلیک کنید، می‌رید به صفحه‌ی جزئیات و لیست URLها رو می‌بینید.

چرا صفحات گروه‌بندی می‌شوند؟

اینجا یه چیزی هست که باید بدونید: گوگل همه‌ی URLها رو دونه‌دونه بهتون نشون نمی‌ده. صفحاتی که ساختار مشابهی دارن رو دسته‌بندی می‌کنه و یکی‌شون رو به‌عنوان نمونه نشون می‌ده.

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

پس روش کار اینه: از هر گروه یکی رو باز کنید، مشکلش رو پیدا کنید، توی قالب حلش کنید، تمام.

بررسی دقیق‌تر با PageSpeed Insights

سرچ کنسول بهتون می‌گه «مشکل دارید»، ولی نمی‌گه «دقیقاً کجا». برای اون باید برید سراغ PageSpeed Insights.

کنار هر URL توی سرچ کنسول یه آیکون هست که مستقیم می‌بردتون اونجا. یا می‌تونید به آدرس pagespeed.web.dev برید و URL رو دستی وارد کنید و Analyze رو بزنید.

نکته برای کاربرای ایران

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

داده‌ی میدانی در برابر داده‌ی آزمایشگاهی

توی صفحه‌ی نتایج دو بخش می‌بینید و فرقشون خیلی مهمه:

• بالای صفحه — Field Data: داده‌ی واقعی کاربرای ۲۸ روز گذشته. همینه که روی سئوتون اثر می‌ذاره.
• پایین‌تر — Lab Data: یه تست شبیه‌سازی‌شده که همون لحظه انجام می‌شه. این برای دیباگ کردن عالیه، ولی نمره‌ش مستقیماً روی رتبه‌تون اثر نداره.

خیلی‌ها همه‌ی انرژی‌شون رو می‌ذارن که اون عدد ۱۰۰ آزمایشگاهی رو بگیرن، در حالی که داده‌ی میدانی‌شون هنوز قرمزه. اشتباه رایجیه.

بقیه‌ی شاخص‌هایی که اینجا می‌بینید

توی بخش Lab Data چند تا معیار دیگه هم هست که جزو Core Web Vitals نیستن ولی برای عیب‌یابی خیلی به کار میان:

• FCP (First Contentful Paint): اولین متن یا تصویر کِی روی صفحه ظاهر می‌شه.
• Speed Index: چقدر سریع محتوای صفحه به‌صورت بصری کامل می‌شه.
• TBT (Total Blocking Time): چقدر زمان، مرورگر به‌خاطر جاوااسکریپت سنگین قفل می‌مونه و به کاربر جواب نمی‌ده. این یکی همبستگی زیادی با INP داره؛ TBT رو پایین بیارید، INP هم بهتر می‌شه.

PageSpeed Insights یا GTmetrix؟

جفتشون خوبن ولی کارشون فرق می‌کنه. GTmetrix ابزار خوبی برای تست از لوکیشن‌های مختلف و بررسی waterfall درخواست‌هاست. ولی معیار گوگل برای سئو، همون داده‌ی PageSpeed Insights و سرچ کنسوله. پس اگه قراره یکی رو ملاک بذارید، PageSpeed Insights.

نحوه درست کردن بخش Core Web Vitals

این بخش اون چیزیه که واقعاً دنبالشید. برای هر شاخص، کارهایی که بیشترین اثر رو دارن نوشتم.

بهبود LCP

۱. تصویر شاخص رو سبک کنید. بیشتر مشکلات LCP از یه تصویر ۲ مگابایتی میاد که کسی زحمت فشرده کردنش رو نکشیده. فرمت رو به WebP یا AVIF تغییر بدید. معمولاً همین یه کار به‌تنهایی یکی دو ثانیه بهتون برمی‌گردونه.

۲. تصویر بالای صفحه رو lazy load نکنید. این اشتباه خیلی رایجه. lazy loading برای تصاویر پایین صفحه عالیه، ولی اگه روی تصویر اصلی بذاریدش، LCP رو خراب می‌کنید. به‌جاش بهش fetchpriority="high" بدید.

۳. زمان پاسخ سرور رو کم کنید. اگه سرور خودش ۱.۵ ثانیه طول می‌کشه تا جواب بده، هر کاری بکنید LCP خوب نمی‌شه. کش سمت سرور فعال کنید، هاست رو ارتقا بدید، و اگه مخاطب بین‌المللی دارید از CDN استفاده کنید.

۴. فایل‌های مسدودکننده‌ی رندر رو کم کنید. هر فایل CSS و JS که توی <head> باشه، مرورگر رو معطل می‌کنه. CSS غیرضروری رو جدا کنید و JS رو با defer بارگذاری کنید.

۵. فونت‌ها رو درست بارگذاری کنید. از font-display: swap استفاده کنید تا متن با فونت پیش‌فرض نشون داده بشه و منتظر دانلود فونت نمونه.

کاهش CLS

۱. برای تصاویر width و height مشخص کنید. ساده‌ترین و مؤثرترین کار. وقتی ابعاد رو مشخص می‌کنید، مرورگر از قبل جا رو خالی نگه می‌داره و محتوا نمی‌پره.

۲. برای تبلیغات و ویجت‌ها جا رزرو کنید. هر چیزی که بعداً لود می‌شه (تبلیغ، ویدیوی امبد، باکس نظرات) باید از اول یه فضای ثابت داشته باشه.

۳. محتوا رو بالای محتوای موجود تزریق نکنید. اون بنر «تخفیف ویژه» که بعد از لود صفحه میاد بالای همه‌چیز و کل صفحه رو هل می‌ده پایین، دشمن شماره‌ یک CLS هست. اگه لازمه نمایشش بدید، از اول جاش رو نگه دارید یا به‌صورت شناور (fixed) نمایشش بدید.

۴. انیمیشن‌ها رو با transform بسازید، نه با تغییر ابعاد. تغییر width، height، top و margin باعث جابه‌جایی لایوت می‌شه؛ ولی transform نه.

۵. برای پاپ‌آپ‌ها. پاپ‌آپی که وسط صفحه باز می‌شه و چیزی رو هل نمی‌ده، به CLS آسیب نمی‌زنه. اونی که به‌صورت نواری بالای صفحه ظاهر می‌شه و محتوا رو می‌بره پایین، آسیب می‌زنه.

بهبود INP

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

۲. اسکریپت‌های شخص ثالث رو مدیریت کنید.ابزارهای چت آنلاین، پیکسل‌های تبلیغاتی، ابزارهای آنالیتیکس. این‌ها رو با defer یا بعد از تعامل کاربر لود کنید.

۳. کارهای طولانی رو تیکه‌تیکه کنید. اگه یه تابع جاوااسکریپت دارید که چند صد میلی‌ثانیه اجرا می‌شه، توی همون مدت مرورگر به هیچ کلیکی جواب نمی‌ده. این کارها رو به بخش‌های کوچیک‌تر بشکنید.

۴. TBT رو توی Lab Data چک کنید. چون INP داده‌ی میدانیه و برای دیدن اثر تغییراتتون باید هفته‌ها صبر کنید، از TBT به‌عنوان راهنمای سریع استفاده کنید.

دکمه‌ی Validate Fix و صبری که لازم دارید

بعد از اینکه مشکل رو حل کردید، برگردید به سرچ کنسول، وارد جزئیات اون خطا بشید و روی Validate Fix بزنید.

از اینجا به بعد باید صبر کنید. گوگل شروع می‌کنه به بررسی صفحات و این فرآیند می‌تونه تا ۲۸ روز طول بکشه. چرا؟ چون داده‌ی میدانی روی یه بازه‌ی ۲۸ روزه‌ی متحرک محاسبه می‌شه. یعنی حتی اگه امروز مشکل کاملاً حل شده باشه، گزارش هنوز داده‌ی روزهای قبل رو هم توی خودش داره.

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

اگه اعتبارسنجی Failed شد، گوگل بهتون می‌گه کدوم URL هنوز مشکل داره. اون رو جدا بررسی کنید.

تأثیر واقعی این کار

بذارید با یه حساب ساده نشونتون بدم چرا ارزشش رو داره.

فرض کنید روزی ۱۰۰۰ نفر از سایتتون بازدید می‌کنن و شما با بهینه کردن تصاویر، نیم ثانیه از زمان لود کم کردید. روزی ۵۰۰ ثانیه، ماهی حدود ۴ ساعت از وقت کاربراتون رو صرفه‌جویی کردید.

ولی عدد جالب‌تر جای دیگه‌ایه: بر اساس تحقیقات گوگل، هر چی زمان لود بیشتر بشه، احتمال خروج کاربر به‌شکل قابل‌توجهی بالا می‌ره. یعنی سایت کند فقط رتبه‌تون رو خراب نمی‌کنه، مستقیماً مشتری‌تون رو فراری می‌ده.

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

سؤالات متداول

جمع‌بندی

خلاصه‌ش می‌شه این چند خط:

• سه تا شاخص دارید: LCP (سرعت نمایش محتوای اصلی)، INP (سرعت واکنش به کاربر)، CLS (ثبات ظاهری صفحه).
• اول سراغ گزارش موبایل برید و قرمزها رو اولویت بدید.
• صفحات گروه‌بندی شدن، پس با یه بار اصلاح قالب چند صد صفحه رو با هم درست می‌کنید.
• برای بیشتر سایت‌ها، بهینه‌سازی تصاویر و کم کردن جاوااسکریپت اضافه بیشترین نتیجه رو با کمترین زحمت می‌ده. از همون‌ها شروع کنید.
• بعد از اصلاح Validate Fix رو بزنید و تا ۲۸ روز صبر کنید.

لازم نیست همه‌چیز رو یک‌شبه درست کنید. یکی از خطاها رو انتخاب کنید، همین هفته حلش کنید، بعد برید سراغ بعدی. سه ماه دیگه گزارشتون کاملاً فرق کرده. شاد و سربلند باشید. 🙂

تیم تولید محتوا

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