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

سه معیار و مرز خوب بودنشان

طبق راهنمای web.dev، این سه معیار و آستانه «خوب» آن‌ها چنین است:

  • LCP، سرعت بارگذاری: بزرگ‌ترین بخش محتوای صفحه تا ۲٫۵ ثانیه نمایش داده شود.
  • INP، سرعت واکنش: صفحه به تعامل کاربر تا ۲۰۰ میلی‌ثانیه پاسخ بصری بدهد.
  • CLS، پایداری ظاهر: میزان جابه‌جایی ناگهانی اجزا تا ۰٫۱ باشد.

نکته‌ای که زیاد نادیده گرفته می‌شود این است که این اعداد در صدک ۷۵ بازدیدهای واقعی سنجیده می‌شوند و موبایل و دسکتاپ جدا حساب می‌شوند. یعنی دست‌کم سه‌چهارم بازدیدها باید به این مرز برسند. گوشی قوی خودتان روی اینترنت خوب چیزی را ثابت نمی‌کند.

داده آزمایشگاهی و داده واقعی را قاطی نکنید

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

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

چه کارهایی معمولاً بیشترین اثر را دارند

برای LCP

  • تصویر اصلی صفحه را با فرمت مدرن و ابعاد درست بفرستید و آن را تنبل‌بارگذاری نکنید.
  • زمان پاسخ سرور را اندازه بگیرید. اگر سرور دیر جواب بدهد، بقیه بهینه‌سازی‌ها جبرانش نمی‌کنند.
  • فونت را از همان دامنه خودتان بدهید و فقط وزن‌هایی را بار کنید که واقعاً استفاده می‌شوند.
  • برای مخاطب داخل ایران، جای سرور را هم در نظر بگیرید؛ فاصله شبکه را با کد نمی‌شود حذف کرد.

برای INP

  • جاوااسکریپت کمتری بفرستید. هر کتابخانه‌ای که اضافه می‌شود روی گوشی ضعیف هزینه دارد.
  • کارهای سنگین را به تکه‌های کوچک بشکنید تا مرورگر فرصت پاسخ به کلیک را داشته باشد.
  • اسکریپت‌های شخص ثالث مثل ابزارهای تحلیل و گفت‌وگوی آنلاین را جدی بررسی کنید. بسیاری از آن‌ها سهم بزرگی از کندی را دارند.

برای CLS

  • برای تصویر و ویدئو ابعاد مشخص کنید تا مرورگر جایشان را از قبل نگه دارد.
  • فضای بنر و اعلان را از قبل در چیدمان در نظر بگیرید و محتوا را بالای محتوای موجود تزریق نکنید.
  • فونت جایگزین را طوری انتخاب کنید که با آمدن فونت اصلی، متن جهش نکند. این نکته برای فونت‌های فارسی که حجم بیشتری دارند مهم‌تر است.

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

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

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

منابع