چرا Core Web Vitals برای رتبه شما تصمیم میگیرد
سایت شما در صفحه اول گوگل است، ترافیک هم میگیرید، اما نرخ تبدیل پایین است. کاربران وارد میشوند و بعد از چند ثانیه صفحه را میبندند. گزارش PageSpeed Insights را باز میکنید و سه شاخص قرمز میبینید: LCP روی ۴.۸ ثانیه، INP روی ۶۰۰ میلیثانیه و CLS روی ۰.۳۵. این اعداد فقط یک هشدار نیستند؛ گوگل از مارس ۲۰۲۴ این شاخصها را مستقیماً در الگوریتم رتبهبندی موبایل اعمال میکند. یعنی همین حالا، رقیب شما با صفحهای کندتر از نظر محتوا اما سریعتر از نظر فنی، بالاتر از شما ایستاده است.
Core Web Vitals سه شاخصی هستند که تجربه واقعی کاربر را اندازه میگیرند، نه سرعت خام سرور را. این تفاوت مهم است. یک سرور NVMe با اتصال ۱۰ گیگابیت میتواند پاسخ را در ۵۰ میلیثانیه بدهد، اما اگر جاوااسکریپت مرورگر را قفل کند، کاربر همچنان صفحه خالی میبیند.
LCP: بزرگترین محتوای مرئی چه زمانی بارگذاری میشود
LCP یا Largest Contentful Paint، لحظهای را اندازه میگیرد که بزرگترین عنصر قابل مشاهده در صفحه (معمولاً تصویر هیرو، تیتر اصلی یا ویدیو) رندر میشود. آستانه قبولی گوگل ۲.۵ ثانیه است. بین ۲.۵ تا ۴ ثانیه نیاز به بهبود دارد و بالای ۴ ثانیه یعنی شکست خوردهاید.
برای اندازهگیری دقیق، از دستور زیر در Chrome DevTools استفاده کنید:
npx lighthouse https://example.com --only-categories=performance --output=json --output-path=report.jsonاین دستور یک گزارش JSON کامل تولید میکند که بخش LCP آن به تفکیک زمانهای TTFB، زمان بارگذاری منبع و تأخیر رندر را نشان میدهد. اگر میخواهید داده واقعی کاربران را ببینید، به گزارش Core Web Vitals در Google Search Console بروید و فیلتر «موبایل» را فعال کنید.
چرا TTFB بالا میرود
بیشترین دلیلی که در سایتهای فارسی میبینم، DNS کند یا سرور اشتراکی شلوغ است. اگر TTFB شما بالای ۸۰۰ میلیثانیه است، اول DNS را بررسی کنید. با دستور زیر میتوانید زمان پاسخ DNS را اندازه بگیرید:
dig +stats example.com | grep "Query time"اگر Query time بالای ۱۰۰ میلیثانیه است، مشکل از DNS است. اگر DNS سالم بود، سرور را بررسی کنید. یک راهحل عملی برای سایتهای وردپرسی، استفاده از کش صفحه در سطح سرور است. افزونههایی مثل WP Rocket یا LiteSpeed Cache میتوانند TTFB را از ۱.۲ ثانیه به ۲۰۰ میلیثانیه برسانند.
تصاویر؛ قاتل خاموش LCP
تصویر هیرو را با فرمت WebP یا AVIF سرو کنید. یک تصویر JPEG سه مگابایتی میتواند LCP را ۲ ثانیه بالا ببرد. دستور تبدیل با ImageMagick:
convert hero.jpg -quality 80 -resize 1920x1080 hero.webpهمچنین ویژگی fetchpriority="high" را به تصویر LCP اضافه کنید تا مرورگر آن را زودتر از بقیه منابع بارگذاری کند. این یک تغییر یک خطی است که تأثیرش را بلافاصله در گزارش میبینید.
اینجا اشتباه میکنند: خیلیها فقط تصویر را فشرده میکنند اما loading="lazy" را روی همان تصویر هیرو میگذارند. نتیجه؟ مرورگر منتظر میماند تا تصویر وارد viewport شود و بعد شروع به بارگذاری میکند. LCP شما ۱.۵ ثانیه بدتر میشود و هیچکس نمیفهمد چرا. قانون ساده: تصویر LCP هرگز lazy نباشد.
INP: واکنشپذیری صفحه با تعامل کاربر
INP یا Interaction to Next Paint، از مارس ۲۰۲۴ جایگزین FID شده است. تفاوت اساسی این است که FID فقط اولین تعامل را اندازه میگرفت، اما INP بدترین تعامل در کل طول عمر صفحه را ثبت میکند. یعنی اگر کاربر در دقیقه سوم با یک دکمه تعامل کند و مرورگر ۸۰۰ میلیثانیه قفل بماند، همان عدد در گزارش شما مینشیند.
آستانه قبولی INP زیر ۲۰۰ میلیثانیه است. بین ۲۰۰ تا ۵۰۰ میلیثانیه نیاز به بهبود دارد و بالای ۵۰۰ یعنی شکست. برای اندازهگیری، از دستور زیر استفاده کنید:
npx @puppeteer/browsers install chrome@stableسپس یک اسکریپت Node.js بنویسید که با Puppeteer صفحه را باز کند، روی چند عنصر کلیک کند و INP را ثبت کند. روش سادهتر: افزونه Web Vitals را در Chrome نصب کنید و با صفحه واقعی کار کنید.
مقصر اصلی INP: جاوااسکریپت سنگین
هر اسکریپتی که در ترد اصلی مرورگر اجرا میشود، INP را بالا میبرد. اسکریپتهای تحلیلگر، چت آنلاین، اسلایدرها و انیمیشنهای CSS پیچیده، همگی سهم دارند. برای تشخیص، در DevTools تب Performance را باز کنید و یک تعامل را ضبط کنید. اگر میبینید که یک تابع ۳۰۰ میلیثانیه طول میکشد، آن را با Web Worker به ترد دیگری منتقل کنید.
یک راهحل فوری: اسکریپتهای غیرضروری را با defer بارگذاری کنید. این ویژگی به مرورگر میگوید که اسکریپت را بعد از پارس کامل HTML اجرا کند، نه هنگام رسیدن به آن. تغییر از حالت پیشفرض به defer معمولاً INP را ۳۰ تا ۴۰ درصد بهبود میدهد.
یک معاوضه واقعی اینجا وجود دارد: حذف کامل جاوااسکریپت INP را عالی میکند، اما اگر سایت شما فروشگاه اینترنتی است، سبد خرید و فیلترها بدون JS کار نمیکنند. انتخاب من: اسکریپتهای حیاتی را inline کنید، بقیه را با defer بارگذاری کنید و اسکریپتهایی که هیچ نقشی در تعامل کاربر ندارند (مثل رباتهای چت) را بهکلی حذف کنید. اگر چت آنلاین برای شما حیاتی است، آن را فقط در صفحه تماس فعال کنید، نه در همه صفحات.
CLS: جابهجایی ناگهانی عناصر صفحه
CLS یا Cumulative Layout Shift، میزان جابهجایی غیرمنتظره عناصر را در طول عمر صفحه اندازه میگیرد. آستانه قبولی زیر ۰.۱ است. بالای ۰.۲۵ یعنی شکست. این شاخص مستقیماً با اعتماد کاربر ارتباط دارد؛ وقتی کاربر روی یک دکمه کلیک میکند و ناگهان بنر تبلیغاتی جایش عوض میشود، کلیک اشتباهی رخ میدهد.
بزرگترین عامل CLS در سایتهای فارسی، تصاویر بدون ابعاد مشخص و فونتهای وب هستند. برای تصاویر، همیشه عرض و ارتفاع را در HTML مشخص کنید:
<img src="product.jpg" width="800" height="600" alt="محصول">این کار به مرورگر میگوید که فضای لازم را قبل از بارگذاری تصویر رزرو کند. برای فونتها، از font-display: swap استفاده کنید تا متن با فونت پیشفرض نمایش داده شود و بعد از بارگذاری فونت وب، جایگزین شود. این تغییر ساده میتواند CLS را از ۰.۳ به ۰.۰۵ برساند.
اینجا اشتباه میکنند: بنرهای تبلیغاتی یا اسلایدرهایی که بعد از بارگذاری صفحه ظاهر میشوند. اگر یک بنر ۳۰۰ پیکسلی بعد از ۲ ثانیه بالای محتوا ظاهر شود، CLS شما ۰.۲۵ بالا میرود. راهحل: فضای بنر را از قبل با یک div خالی رزرو کنید یا بنر را به پایین صفحه منتقل کنید.
ترتیب بهینهسازی؛ از کجا شروع کنید
اگر بودجه شما محدود است، اول CLS را درست کنید. چرا؟ چون سادهترین و سریعترین بهبود است. اضافه کردن ابعاد به تصاویر و تنظیم font-display معمولاً در یک روز انجام میشود و تأثیر فوری دارد. بعد از آن LCP را هدف بگیرید؛ چون معمولاً یک مشکل اصلی (تصویر سنگین یا TTFB بالا) دارد. INP را آخر بگذارید؛ چون نیاز به تحلیل عمیقتر جاوااسکریپت دارد.
برای پایش مداوم، از ابزارهای رایگان استفاده کنید. ابزارهای سئو و وبمستر سرورنت شامل PageSpeed Insights و گزارشهای Core Web Vitals است. اگر سایت شما روی هاست اشتراکی است و TTFB زیر ۵۰۰ میلیثانیه نمیآید، وقت آن رسیده که به سرور اختصاصی یا ابری مهاجرت کنید. این یک هزینه است، اما اگر درآمد شما به رتبه گوگل وابسته است، سرمایهگذاری منطقیای است.
یک نکته مهم: Core Web Vitals را با ابزارهای تست سرعت عمومی اشتباه نگیرید. ابزارهایی مثل GTmetrix و Pingdom سرعت خام را نشان میدهند، اما شاخصهای گوگل تجربه کاربر را میسنجند. یک سایت میتواند TTFB عالی داشته باشد اما LCP ضعیف، چون تصویر هیرو سنگین است. همیشه به دادههای Google Search Console و PageSpeed Insights اعتماد کنید، نه به ابزارهای عمومی.
پرسشهای پرتکرار
آیا Core Web Vitals مستقیماً روی رتبه گوگل تأثیر میگذارد؟
بله، از مارس 2024 این شاخصها بخشی از سیگنالهای رتبهبندی موبایل هستند. اما یک نکته مهم: این فقط یکی از صدها سیگنال است. سایتی با محتوای عالی و لینکهای قوی میتواند با Core Web Vitals ضعیف هم رتبه خوبی بگیرد، اما اگر دو سایت از نظر محتوا برابر باشند، سایتی که این شاخصها را پاس کرده باشد بالاتر میایستد.
چرا INP جایگزین FID شد؟
FID فقط اولین تعامل کاربر را اندازه میگرفت و اگر کاربر اول صفحه را اسکرول میکرد و بعد کلیک میکرد، عدد خوبی نشان میداد. INP بدترین تعامل در کل طول عمر صفحه را ثبت میکند، پس تصویر دقیقتری از تجربه واقعی کاربر ارائه میدهد. این تغییر از مارس 2024 اعمال شده است.
آیا Core Web Vitals روی دسکتاپ هم اعمال میشود؟
بله، گوگل این شاخصها را جداگانه برای موبایل و دسکتاپ گزارش میدهد. اما اولویت با موبایل است چون بیشتر ترافیک گوگل از دستگاههای همراه میآید. اگر بودجه محدود دارید، اول موبایل را بهینه کنید و بعد دسکتاپ.
چقدر طول میکشد تا بهبود Core Web Vitals در رتبه دیده شود؟
گوگل معمولاً بین ۲ تا ۴ هفته بعد از اعمال تغییرات، دادههای جدید را جمعآوری و ایندکس میکند. اگر تغییرات را امروز اعمال کنید، در گزارش Search Console حدود ۲۸ روز بعد نتیجه را میبینید. صبور باشید و هر هفته گزارش را چک کنید.
اگر میخواهید مسیر بهینهسازی را حرفهای ادامه دهید، خدمات سئو سرورنت شامل تحلیل فنی کامل Core Web Vitals و اجرای اصلاحات است. اما قبل از هر اقدامی، یک کار را همین امروز انجام دهید: گزارش PageSpeed Insights سایت خود را باز کنید و سه عدد LCP، INP و CLS را یادداشت کنید. یک ماه بعد، همان اعداد را مقایسه کنید. این تنها راهی است که میفهمید آیا واقعاً پیشرفت کردهاید یا نه.
دیدگاهها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!