Core Web Vitals به زبان ساده: سرعتی که کاربر حس می‌کند

سرعت سایت یک عدد نیست؛ یک حس است. کاربر نمی‌داند صفحه در چند میلی‌ثانیه بار شده، ولی حس می‌کند «سریع بود» یا «کند بود». Core Web Vitals تلاش گوگل برای اندازه گرفتن همین حس با سه شاخص است.

این سه شاخص بر رتبه‌ی جستجو هم اثر دارند، ولی دلیل اصلی توجه به آن‌ها خود کاربر است.

سه شاخص

LCP: چقدر طول می‌کشد تا محتوای اصلی دیده شود

بزرگ‌ترین عنصر قابل‌دیدن صفحه، معمولاً تصویر اصلی یا تیتر بزرگ، چه زمانی نمایش داده می‌شود. این همان لحظه‌ای است که کاربر حس می‌کند صفحه «آمد».

هدف گوگل: کمتر از ۲٫۵ ثانیه.

INP: صفحه چقدر سریع به من جواب می‌دهد

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

هدف گوگل: کمتر از ۲۰۰ میلی‌ثانیه.

CLS: آیا صفحه زیر دستم تکان می‌خورد

می‌خواهید روی دکمه‌ای بزنید، ناگهان یک تصویر بار می‌شود، همه‌چیز پایین می‌رود و روی چیز دیگری می‌زنید. CLS همین جابه‌جایی‌های ناخواسته را می‌سنجد.

هدف گوگل: کمتر از ۰٫۱.

بهتر کردن LCP

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

بهتر کردن INP

مقصر اصلی تقریباً همیشه جاوااسکریپت زیاد است.

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

در این سایت، حرکت‌های تزئینی با یک کد کوچک مشترک و نشانه‌گذاری در HTML انجام می‌شوند تا اجزای صفحه لازم نباشد در مرورگر دوباره ساخته شوند.

بهتر کردن CLS

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

کجا اندازه بگیریم

دو نوع داده وجود دارد و فرقشان مهم است:

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

داده‌ی میدانی. تجربه‌ی کاربران واقعی با دستگاه و اینترنت واقعی. این همان چیزی است که گوگل برای رتبه‌بندی به کار می‌برد و در Search Console دیده می‌شود.

بودجه‌ی عملکرد

سرعت به‌مرور از دست می‌رود: یک کتابخانه اینجا، یک تصویر بزرگ آنجا. راه نگه داشتنش این است که سقف تعیین کنید و آن را خودکار بررسی کنید:

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

اگر تغییری از سقف گذشت، پیش از انتشار متوقف می‌شود. این همان منطق دروازه‌ی کیفیت است.

برای کاربر ایرانی

چند نکته برای بازار ایران اهمیت بیشتری دارد:

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

جمع‌بندی

سرعت یک پروژه‌ی یک‌باره نیست؛ یک عادت است. تصویر سبک، جاوااسکریپت کم، چیدمان ثابت و سقفی که خودکار بررسی می‌شود. نتیجه هم برای کاربر بهتر است و هم برای دیده شدن در جستجو.

مطلب مرتبط: دیده شدن در پاسخ هوش مصنوعی‌ها.