Core Web Vitals چیست و چرا گوگل بر آن تاکید دارد؟

هر هفته یک اسکرین‌شات از PageSpeed Insights برایم می‌فرستید، و هر هفته یک سؤال پشتش هست: «این عدد چند شود سایت من در گوگل بالا می‌آید؟» و پاسخ صادقانه‌ای که باید بدهم ممکن است ناراحت‌کننده باشد: آن عدد، یا تقریباً هیچ‌ ربطی به رتبۀ شما ندارد، یا اگر داشته باشد، روشِ خواندنش را غلط انجام داده‌اید. Core Web Vitals — همان «شاخص‌های اصلی وب» — زبانِ مشترکِ گوگل با شماست دربارهٔ کیفیتِ تجربۀ واقعیِ کاربر، ولی اکثر بحث‌های فارسیِ اینترنت درباره‌اش سه اشتباهِ فاحش دارد: اندازه‌گیری با آزمایشگاه به‌جای دادهٔ واقعی، تعقیبِ «نمرۀ ۱۰۰» به‌جای سه شاخصِ جدا، و اقدام‌کردن روی عددی که اصلاً گلوگاه سایت شما نیست. این مقاله را دقیقاً برای رفع همین سه اشتباه نوشته‌ام: هر کدام از سه شاخص را با آستانه‌های رسمی باز می‌کنم، نشانه‌های وردپرسی‌شان را می‌گویم، و در پایان ترتیبِ عملیاتیِ نجاتِ امتیاز را می‌دهم — همان ترتیبی که در پروژه‌های واقعی استفاده می‌کنم.

چرا گوگل اصلاً این‌ها را می‌سنجد؟

تاریخچۀ کوتاه و پُرمغز: گوگل سال‌ها فقط سرعتِ «بارگذاری» را می‌دید، اما تجربه‌اش با کاربر نشان داد سرعتِ دانلود، تنها بُعدِ رضایت نیست — کاربری که صفحه‌اش سریع بالا آمده ولی موقع اسکرول پرش می‌کند یا دکمه با تاخیر واکنش می‌دهد، همان تجربهٔ بد را دارد. Core Web Vitals پاسخِ این شکاف است: به‌جای «چقدر زود آمد؟»، «وقتی آمد، چقدر حسِ خوبی داد؟» را می‌سنجد و آن را در سه شاخص قابل‌دسترس (LCP برای بارگذاری، INP برای تعامل، CLS برای ثبات) خلاصه کرده. در معماریِ سئوی امروز، این‌ها بخشی از همان «سیگنال‌های تجربهٔ صفحه»اند که جایگاهشان را در «سئو چیست و چه کمکی به کسب‌وکار می‌کند؟» روی نقشۀ کلی نشان داده‌ام؛ و بستر فنیِ اندازه‌گیریِ‌شان، در دنیای «سئو تکنیکال چیست؟» تعریف می‌شود. نکتهٔ اول و مهم: تأثیر CWV بر رتبه، تأثیرِ تعدیل‌گر است نه موتور — محتوای بی‌ربط با نمرۀ ۱۰۰ هم بالا نمی‌آید؛ ولی در فاصلۀ بین دو رقیبِ محتواییِ هم‌سطح، همین اعداد داورِ بازی‌اند.

Core Web Vitals نمرۀ اخلاقِ سایت شماست، نه پروانۀ رتبه؛ بی‌اخلاق را هیچ‌کس تحمل نمی‌کند، ولی بااخلاقِ بی‌محتوا هم خریدار ندارد.

آزمایشگاه یا دادهٔ واقعی؟ اول این را بفهمید

منبعِ نصفِ گمراهی‌ها همین‌جاست: ابزارهایی مثل PageSpeed Insights دو گزارشِ کاملاً متفاوت می‌دهند و اکثر کاربران فقط یکی را می‌بینند. گزارشِ آزمایشگاهی (Lighthouse): یک اجرا از سرورِ گوگل با موبایلِ شبیه‌سازی‌شده انجام می‌شود؛ سریع، تکرارپذیر، و مناسبِ «تطبیقِ علت» — ولی هیچ‌وقت دادهٔ واقعیِ کاربرِ شما نیست. گزارشِ میدانی (CrUX): تجربۀ کاربرانِ واقعیِ اندرویدِ Chrome در ۲۸ روز گذشته؛ کند به‌روز می‌شود، برای سایت‌های کم‌ترافیک داده ندارد، ولی حکمِ داوری را دارد — همان چیزی که گوگل در رتبه‌بندی می‌بیند. اشتباهِ شایع: نمرۀ آزمایشگاه را در Search Console گزارش‌کردن و ساعت‌ها وقت خرجِ بهبود عددی که در دنیای واقعی وجود خارجی ندارد. قانونِ من: آزمایشگاه برای «یافتنِ مقصر و تستِ اصلاح»، میدانی برای «داوریِ نهایی»؛ ابزارهای هر دو دسته را در «بهترین ابزارهای تست سرعت سایت» معرفی کرده‌ام و روشِ عیب‌یابیِ مرحله‌به‌مرحله را در «چگونه مشکلات سرعت سایت را رفع کنیم؟». یک تذکرِ بازارِ ایران: دادهٔ CrUX برای اکثر سایت‌های ایرانی یا خالی است یا از Chrome اندرویدِ پراکنده؛ پس «نداشتنِ امتیاز میدانی» شکست نیست — در این حالت، آزمونِ تجربی روی دستگاهِ واقعیِ خودتان با اینترنتِ سلفون، بهترین داورِ در دسترس است.

نمرۀ ۱۰۰ در آزمایشگاه، عکسِ دست‌نوشته‌ای‌ست برای پیرزنی که با موبایلِ ۳Gِ خودِ واقعی نمی‌تواند دکمۀ تماس را لمس کند؛ گوگل دست‌نوشته را نمی‌بیند، پیرزن را می‌بیند.

LCP: سرعتِ اولین‌تصویر

LCP (Largest Contentful Paint) زمانِ ظاهرشدنِ بزرگ‌ترین عنصرِ قابل‌مشاهده در دیدِ اول را می‌سنجد — در اکثر سایت‌ها همان بنرِ خانه یا تصویرِ شاخصِ نوشته. آستانه‌ها: زیر ۲/۵ ثانیه خوب، ۲/۵ تا ۴ نیازمند بهینگی، بالای ۴ بد. چهار مظنونِ همیشگیِ LCPِ بد در وردپرس را با ترتیبِ احتمالِ گناه می‌گویم: یک: سرور کند — همان TTFB؛ اگر اولین‌بایت ۸۰۰ میلی‌ثانیه طول بکشد، LCP از همان‌جا با کوهی از عقب‌ماندگی شروع می‌کند؛ پروندۀ کاملش در «تأثیر TTFB بر سرعت بارگذاری صفحه». دو: تصویرِ بنرِ سنگین — آپلودِ ۳ مگابایتی و کوچک‌کردنش با CSS؛ درمانش (srcset/WebP/ابعاد درست) در «سئوی تصویر چیست؟» و «فشرده‌سازی تصاویر سایت» آمده. سه: lazy-load روی عنصرِ LCP — اشتباهی که مشخصاً در مقالۀ سئوی تصویر به «هرگز»اش حکم داده‌ام؛ تصویرِ دیدِ اول باید eager و fetchpriority-high باشد. چهار: فونت‌هایِ external و CSSِ بلاک‌کننده که رندر را معطل نگه می‌دارند — معمولاً میراثِ قالب‌های پُر زور؛ همان کالبدی که در «چرا برخی قالب‌های وردپرس سایت را کند می‌کنند؟» کالبدشکافی کرده‌ام. یک مثالِ واقعی از مینی‌کیسِ مقالۀ سرعت: سایت خبری با LCPِ ۶/۲ که فقط با WebP + srcset + eagerشدنِ بنر رسید به ۲/۳ — بدونِ لمسِ هاست و قالب. قبلِ هر سرمایه‌گذاریِ بزرگ، همین چهار مظنون را با DevTools چک کنید؛ در اکثر سایت‌ها مقصر یکی از این چهار است، نه چیزِ ششم.

INP: پاسخ‌گویی به لمس (جانشین FID)

از مارس ۲۰۲۴، INP (Interaction to Next Paint) جانشینِ FID شد و صورتِ مسئله عوض شد: گوگل حالا نه‌فقط «فاصلۀ تا شروعِ پاسخ»، که «فاصلۀ کلیکِ کاربر تا نقشمِ بعدیِ صفحه» را در طولِ کلِ session می‌سنجد — بدترینِ تعاملات (با تلورانسِ صدک). آستانه: زیر ۲۰۰ میلی‌ثانیه خوب، ۲۰۰ تا ۵۰۰ متوسط، بالای ۵۰۰ بد. و این همان شاخصی‌ست که در وردپرس به‌طرز فجیعی افتضاح می‌شود، چون مقصرانش از جنسِ JS‌اند: شمارۀ یک، افزونه‌هایی که رویدادهای scroll/clickِ سنگین روی صفحه می‌بندند (پاپ‌آپِ خبرنامه، اسلایدرِ خودنما، شمارندۀ بازدید)؛ شمارۀ دو، JSِ بلوک‌کنندۀ قالب که main thread را در لحظۀ لمس قفل می‌کند؛ شمارۀ سه، three.js و انیمیشن‌هایِ پس‌زمینه روی هاستِ ضعیف. تشخیص: در Chrome DevTools، پنلِ Performance را موقع کلیک‌کردن روی منو ضبط کنید — اگر بین لمس و نقاشی، درختِ زردِ «Long Task» قد کشید، مقصر با اسم و فامیل لو رفته. درمان‌ها به ترتیبِ اثر: حذفِ افزونۀ متخلف (قانونِ دارو بودن در «افزونه‌های ضروری وردپرس»)، deferِ هوشمند (با آزمونِ تک‌متغیره که در «تأثیر افزونه‌ها بر سرعت سایت» گفته‌ام)، و در موارد مزمن، جابه‌جاییِ کار از main thread به Web Worker که از حوصلۀ این مقاله بیرون است. تذکرِ صادقه: INP سخت‌ترینِ سه شاخص برای نمرۀ «سبزِ همه‌صفحه» است؛ روی صفحاتِ تعاملیِ کلیدی (محصول، فرم) تمرکز کنید نه صفحه‌به‌صفحه.

CLS: ثباتِ چیدمان

CLS (Cumulative Layout Shift) مجموعِ جابه‌جایی‌های ناگهانیِ عناصر صفحه در حینِ بارگذاری را می‌شمارد — همان لحظه‌ای که انگشت به «دکمۀ خرید» می‌رسد ولی صفحه بالا می‌رود و تبلیغ را لمس می‌کند؛ آزاردهنده‌ترینِ سه شاخص از دیدِ کاربر، و ارزان‌ترینشان از دیدِ اصلاح. آستانه: زیر ۰/۱ خوب، ۰/۱ تا ۰/۲۵ متوسط، بالای ۰/۲۵ بد. چهار متهمِ ردیفِ اولِ وردپرس: تصاویرِ بی‌width/height (وردپرس در آپلودِ درست خودکار می‌نویسدشان — اگر قالبِ شما حذفشان کرده، شکایت را از لایۀ ۲ داشته باشید، همان نقشۀ «قالب سبک»)، بلوک‌های تبلیغاتی/بنری که دیر تزریق می‌شوند و صفحه را هل می‌دهند، فونت‌های webِ بدونِ fallback/swap (جابه‌جاییِ متن هنگام بارگذاری فونت)، و حلقه‌هایِ infinite-scrollِ بی‌reserve. سه درمانِ طلایی: رزروِ min-height برای محفظۀ تبلیغ/بنر، font-display: swap به‌همراهِ سایزِ نزدیکِ fallback، و ابعادِ اجباری روی همهٔ <img>ها. CLS تقریباً همیشه از جنسِ «قالب/تعمیرات» است نه هاست — به همین دلیل در سایت‌های با LCPِ خوب هم گاهی CLSِ وحشی می‌بینم؛ هر سه را مستقل بسنجید، یک‌دیگر را پنهان می‌کنند.

نحوۀ امتیازدهی: ۷۵امین صدک یعنی چه؟

یک سوءتفاهمِ فنی که باید رفع شود: امتیازِ «قبول» در CWV به‌معنای میانگینِ سایت نیست. گوگل برای هر شاخص، ۷۵امین صدکِ بازدیدهایِ صفحات را نگاه می‌کند — یعنی باید ۷۵٪ از بازدیدهایتان آستانه را پاس کنند. ترجمۀ عملی: یک صفحۀ فرعیِ کند با ترافیکِ کم، نمره را خراب نمی‌کند؛ ولی صفحه‌ای با LCPِ بد که ۴۰٪ بازدیدِ سایت آنجاست، آنگاه. پس استراتژیِ درستِ وردپرسی: اول گزارشِ CrUX در Search Console (بخش Core Web Vitals) را باز کنید و ببینید کدام گروهِ URL قرمز است (معمولاً الگوی پنهانِ «خانه سبز، نوشته‌ها قرمز» از جنسِ تصویرِ شاخص است، یا «قالبِ محصول» از جنسِ JS). اگر دادهٔ میدانی ندارید، با Lighthouse روی سه الگویِ صفحه‌ای (خانه/نوشته/دسته) کار کنید و برای خودتان صدکِ ذهنی بسازید: هر الگو را سه بار در حالت موبایلِ ۴G بسنجید، میانه را ملاک بگیرید. و یادآوریِ یک قانونِ کلیدی که در مقالۀ «بهینۀ سرعت سایت چیست؟» گذاشته‌ام: CWV در دسکتاپِ پُر قدرتِ خودتان «سبز» است و در موبایلِ واقعیِ مشتری‌تان قرمز؛ معیارِ داوریِ گوگل، موبایل است — همان دستگاهی که باید مانیفستِ‌تان باشد.

نشانه‌های رایج CWV در وردپرس

این جدول را از صدها گزارشِ PageSpeedِ ارسالی درسهایی؛ تقریباً هر پرونده‌ای در یکی از پنج سطرش جا می‌گیرد. برای الگویِ دوم، تصمیم‌نامهٔ هاست در «تأثیر هاست بر سرعت سایت» و انتخابِ عملی در «بهترین هاست وردپرس» آمده؛ و فراموش نکنید کشِ خوب، LCP و TTFB را هم‌زمان نجات می‌دهد — نقشۀ «افزونه‌های کش» را همین‌جا بخوانید.

ترتیب عملیاتیِ بالا بردن امتیاز

با همین قطعه‌ها، دستورالعملِ اجراییِ من در یک صفحه — همان چیزی که برای خودم چک‌لیست کرده‌ام:

1. پایه‌ریزی (یک‌بار): هاستِ LiteSpeed-محور یا ارتقای پلن + کشِ صفحه + CDNِ رایگان. این سه، سقفِ حرکتِ LCP/TTFB را باز می‌کنند؛ بدونِ‌شان، بقیهٔ تلاش‌ها سقفِ کوتاه دارد. اگر همان نقشۀ شش‌لایۀ «افزایش سرعت وردپرس» را تا اینجا نخوانده‌اید، این قدم را با همان شروع کنید؛ CWV فقط عددخوانیِ همان نقشه است.
2. مصورسازی (سه‌ساعته): CrUX را بخوانید، گروه‌های قرمز را مشخص کنید، و از جدولِ بالا متهمِ اولِ هر گروه را بردارید.
3. تصاویر (یک روز): ده صفحۀ پربازدید — WebP، srcset، eager روی LCP، ابعادِ اجباری. ارزان‌ترین بردِ تاریخِ CWV.
4. تعامل (چند شب): ضبطِ INP روی صفحاتِ کلیدی، حذف/defer افزونه‌های متخلف، حذفِ پاپ‌آپ‌های غیرضروری.
5. ثبات (یک شب): جعبه‌های رزروِ ارتفاع برای تبلیغ/بنر/فونت؛ فونت با swap؛ تستِ آهستۀ ۴G تا چشمیِ پرش‌ها را ببیند.
6. پایش (ماهانه ده دقیقه): سه عددِ کلیدی در یک جدول؛ اگر بعد از هر موجِ انتشار بدتر شد، تک‌تکِ تغییرات را بگردید — رگرسیون، آرام‌آرام نمی‌آید، ناگهانی می‌آید و فرار می‌کند.

چهار باورِ غلط

• «نمرۀ ۱۰۰ = رتبۀ ۱»: مانیفستِ عددِ کامل نه؛ سه شاخص را در صدکِ ۷۵ سبز کنید و سراغِ محتوا بروید. سایت‌هایی با نمرۀ ۷۰ در صدرِ نتایج‌اند چون مناسب‌ترند؛ هیچ‌وقت برعکسش هم دیدنی نیست.
• «یک بار بهینه کردم، تمام»: CWV موجودِ زنده است — افزونۀ تازه، کمپینِ تبلیغاتیِ روی صفحه، بنرِ کریسمس، همه می‌توانند هفته‌ای که حواستان نیست امتیاز را بسوزانند؛ پایشِ ماهانه همین‌جا معنا پیدا می‌کند.
• «PageSpeed Insights ابزارِ من نیست»: ابزارِ داوری‌ست، نه عیب‌یابی؛ برای پیدا‌کردنِ مقصر، DevTools (Performance، Network) سلاحِ شماست — هر دو با هم، نه یکی به‌جای دیگری.
• «AMP/سکریپت‌های جادویی نجاتم می‌دهند»: افزونه‌های «CWV فیکس» که همه‌چیز را defer می‌کنند، در بهترین حالتِ خود، INP را خراب می‌کنند تا LCP را درست نشان بدهند — شاخص را بازی می‌دهند نه تجربت را؛ تجربه‌اش را در «دانلود افزونۀ امن و مطمئن» توضیح داده‌ام.

و برای دیدنِ عکسِ این باورها، «سئو فراتر از کلمات کلیدی» را بخوانید — سئوی مدرن، مجموعه‌ای از سیگنال‌هایِ تجربه و محتواست که CWV یکی از ستون‌های قابل‌سنجشِ آن است؛ همان‌قدر مهم که یک ستون، کل ساختمان نیست.

جمع‌بندی

خلاصۀ مقاله در چهار جمله: CWV زبانش است نه پروانۀ رتبه؛ سه شاخص (LCP زیر ۲/۵ ثانیه، INP زیر ۲۰۰ میلی‌ثانیه، CLS زیر ۰/۱ در ۷۵٪ بازدیدها)؛ داوری با دادهٔ میدانی، عیب‌یابی با آزمایشگاه و DevTools؛ و درمان با ترتیبِ پایه‌ها → تصاویر → تعامل → ثبات. قدمِ امشب‌تان یک چیز است: Search Console را باز کنید و ببینید کدام گروه URL قرمز است؛ از جدولِ پنج‌سطریِ همین مقاله، متهمِ اولِ همان گروه را بردارید و فقط همان را درست کنید. اعدادِ قبل‌وبعدِ خودتان را در دیدگاه بنویسید — نقشۀ ترتیبِ عملیاتی را با نمونه‌هایِ واقعی به‌روز نگه می‌دارم. 🎯