Core Web Vitals چیست ؛ راهنمای تعاملی LCP، INP و CLS
صاحب یک فروشگاه اینترنتی صفحه‌ی اصلی سایتش را در PageSpeed Insights تست می‌کند و عدد ۹۲ می‌گیرد؛ سبز و خیال‌راحت‌کن. یک هفته بعد، در Search Console می‌بیند گوگل بیشتر صفحه‌های همان سایت را در گروه «ضعیف» گذاشته است. هیچ‌کدام از این دو گزارش اشتباه نمی‌کند. اولی یک بار، روی یک سرور سریع و با شرایط آزمایشگاهی صفحه را باز کرده؛ دومی عددی است که از هزاران بازدید واقعی با گوشی‌های معمولی و اینترنت همراه جمع شده است.
Core Web Vitals یا «معیارهای حیاتی وب» همین فاصله را نشان می‌دهند: تجربه‌ای که بازدیدکننده‌ی واقعی از سرعت، پاسخ‌گویی و ثبات صفحه دارد. در این مقاله به‌جای تعریف‌های خشک، هر معیار را با چند ابزار کوچک امتحان می‌کنید: روی دکمه‌ها کلیک کنید، نمودار را جابه‌جا کنید و ببینید یک صفحه کجا و چرا کند به نظر می‌رسد.
سه عدد، سه حسی که کاربر از صفحه دارد
گوگل تجربه‌ی صفحه را با سه معیار می‌سنجد. هرکدام به یک پرسش ساده از ذهن بازدیدکننده جواب می‌دهد: «محتوای اصلی کی آمد؟»، «وقتی کلیک کردم چقدر طول کشید تا جواب بگیرم؟» و «چرا صفحه زیر دستم پرید؟». روی هر معیار کلیک کنید تا توضیحش را ببینید.
LCP یا Largest Contentful Paint
زمانی که بزرگ‌ترین بخش دیدنی بالای صفحه، معمولاً تصویر اصلی یا تیتر بزرگ، کامل نمایش داده می‌شود. کاربر این لحظه را «صفحه آمد» حس می‌کند.
خوب: تا 2.5 ثانیهنیاز به بهبود: تا 4 ثانیهضعیف: بیشتر از 4 ثانیه
مقصرهای رایج: تصویر سنگین بالای صفحه، پاسخ دیر سرور و فایل‌های CSS و جاوااسکریپتی که نمایش را معطل می‌کنند.
INP یا Interaction to Next Paint
فاصله‌ی میان کلیک، لمس یا تایپ کاربر و اولین تغییری که روی صفحه می‌بیند. از مارس ۲۰۲۴ این معیار جای FID را گرفت و برخلاف آن، همه‌ی تعامل‌های یک بازدید را در نظر می‌گیرد، نه فقط اولین کلیک را.
خوب: تا 200 میلی‌ثانیهنیاز به بهبود: تا 500 میلی‌ثانیهضعیف: بیشتر از 500 میلی‌ثانیه
مقصرهای رایج: جاوااسکریپت سنگین، اسکریپت‌های شخص ثالث و کارهایی که مرورگر را چند صد میلی‌ثانیه مشغول نگه می‌دارند.
CLS یا Cumulative Layout Shift
مجموع جابه‌جایی‌های ناگهانی اجزای صفحه که کاربر انتظارش را نداشته است؛ مثل متنی که درست هنگام خواندن پایین می‌رود یا دکمه‌ای که زیر انگشت جابه‌جا می‌شود. این عدد واحد زمان ندارد.
خوب: تا 0.1نیاز به بهبود: تا 0.25ضعیف: بیشتر از 0.25
مقصرهای رایج: تصویر و ویدیوی بدون ابعاد مشخص، بنر و تبلیغی که بعداً جا باز می‌کند و فونتی که دیر بارگذاری می‌شود.
عدد سایت شما در کدام رنگ می‌نشیند؟
آستانه‌ها را گوگل تعیین کرده و برای همه‌ی سایت‌ها یکسان است. در ابزار زیر یک معیار و یک عدد نمونه را انتخاب کنید تا ببینید روی نوار رنگی کجا قرار می‌گیرد و معمولاً چه کاری برای بهترشدنش لازم است. جدول زیرش همان آستانه‌ها را خلاصه کرده است.
| معیار | خوب | نیاز به بهبود | ضعیف |
|---|---|---|---|
| LCP | تا 2.5 ثانیه | 2.5 تا 4 ثانیه | بیشتر از 4 ثانیه |
| INP | تا 200 میلی‌ثانیه | 200 تا 500 میلی‌ثانیه | بیشتر از 500 میلی‌ثانیه |
| CLS | تا 0.1 | 0.1 تا 0.25 | بیشتر از 0.25 |
یک نکته‌ی مهم در خواندن این جدول: یک صفحه وقتی «خوب» حساب می‌شود که هر سه معیارش خوب باشند. LCP عالی، ضعف CLS را جبران نمی‌کند.
چرا یک تست سریع کافی نیست؟ داستان صدک ۷۵
گوگل برای ارزیابی صفحه به میانگین بازدیدها نگاه نمی‌کند. عددی که در گزارش‌ها می‌بینید «صدک ۷۵» است؛ یعنی مقداری که ۷۵ درصد بازدیدها از آن بهتر یا برابرش بوده‌اند. این انتخاب عمدی است: اگر یک‌چهارم بازدیدکنندگان تجربه‌ی بدی داشته باشند، صفحه نمی‌تواند خوب حساب شود.
نمودار زیر LCP بیست بازدید فرضی از یک صفحه را نشان می‌دهد. بین موبایل و دسکتاپ جابه‌جا شوید و بازدیدها را مرتب کنید تا ببینید خط صدک ۷۵ کجا می‌افتد. عددها ساختگی و فقط برای آموزش‌اند، اما الگوی آن‌ها در سایت‌های واقعی زیاد دیده می‌شود.
داده‌های نمودار (LCP بیست بازدید فرضی، به ثانیه)
| بازدید | موبایل | دسکتاپ |
|---|---|---|
| 1 | 2.4 | 1.2 |
| 2 | 1.6 | 0.9 |
| 3 | 3.9 | 1.8 |
| 4 | 2.1 | 1.0 |
| 5 | 5.2 | 2.7 |
| 6 | 1.9 | 1.1 |
| 7 | 2.7 | 1.4 |
| 8 | 3.3 | 1.6 |
| 9 | 1.4 | 0.8 |
| 10 | 2.9 | 1.5 |
| 11 | 4.4 | 2.2 |
| 12 | 2.2 | 1.3 |
| 13 | 3.0 | 1.7 |
| 14 | 1.7 | 1.0 |
| 15 | 6.1 | 3.1 |
| 16 | 2.6 | 1.4 |
| 17 | 3.6 | 1.9 |
| 18 | 2.0 | 1.2 |
| 19 | 3.1 | 2.0 |
| 20 | 2.3 | 2.4 |
در این داده‌ها، نسخه‌ی دسکتاپ با صدک ۷۵ حدود 1.9 ثانیه «خوب» است، اما همان صفحه روی موبایل به حدود 3.3 ثانیه می‌رسد و در محدوده‌ی «نیاز به بهبود» قرار می‌گیرد. گوگل موبایل و دسکتاپ را جدا ارزیابی می‌کند و برای بیشتر سایت‌های ایرانی، سهم موبایل از بازدیدها بیشتر است. پس عددی که باید جدی گرفت، معمولاً عدد موبایل است.
داده‌ی آزمایشگاهی یا داده‌ی میدانی؛ کدام را باور کنیم؟
ابزارهایی مثل Lighthouse صفحه را یک بار، در شرایطی شبیه‌سازی‌شده باز می‌کنند. این «داده‌ی آزمایشگاهی» برای پیدا کردن علت مشکل عالی است، چون هر بار تکرارپذیر است و جزئیات بارگذاری را نشان می‌دهد. اما گوگل برای ارزیابی صفحه از «داده‌ی میدانی» استفاده می‌کند: اطلاعاتی که از مرورگر کروم کاربران واقعی، در یک بازه‌ی ۲۸ روزه، جمع می‌شود و در گزارش CrUX و بخش Core Web Vitals سرچ کنسول دیده می‌شود.
این دو با هم رقابت نمی‌کنند. داده‌ی میدانی می‌گوید «مشکل هست یا نه» و داده‌ی آزمایشگاهی می‌گوید «مشکل از کجاست». یک تفاوت دیگر هم مهم است: INP به تعامل واقعی کاربر نیاز دارد و در تست آزمایشگاهی مستقیم سنجیده نمی‌شود. Lighthouse به‌جای آن معیار Total Blocking Time را گزارش می‌کند که نشانه‌ی خوبی از سنگینی جاوااسکریپت است.
اگر سایت شما بازدید کمی دارد، ممکن است گوگل داده‌ی میدانی کافی برای هر صفحه نداشته باشد. در این حالت گزارش‌ها گروهی از صفحه‌های مشابه را با هم ارزیابی می‌کنند یا اصلاً عددی نشان نمی‌دهند.
کدام بخش صفحه کدام عدد را خراب می‌کند؟
تصویر زیر اسکلت یک صفحه‌ی معمولی است. روی هر بخش کلیک کنید تا ببینید روی کدام معیار اثر می‌گذارد و راه اصلاح معمولش چیست.
یکی از بخش‌های اسکلت صفحه را انتخاب کنید.
INP منوی بالای صفحه
منوهایی که باز شدنشان به اجرای جاوااسکریپت سنگین وابسته است، وقتی کاربر روی آن‌ها می‌زند دیر واکنش نشان می‌دهند. باز و بسته شدن منو بهتر است با CSS یا کد سبک انجام شود و هیچ کار سنگینی پیش از نمایش منو اجرا نشود.
LCP تصویر بزرگ بالای صفحه
در بیشتر صفحه‌ها همین تصویر عنصر LCP است. آن را با lazy-load بارگذاری نکنید، با fetchpriority="high" یا preload در اولویت بگذارید، در قالب WebP یا AVIF و با اندازه‌ی متناسب هر صفحه‌نمایش (srcset) ارائه کنید. اسلایدرهای سنگین بالای صفحه هم معمولاً LCP را دیر می‌کنند.
LCPCLS تیتر با فونت اختصاصی
اگر فونت فارسی دیر برسد، متن یا دیر دیده می‌شود یا با جایگزین‌شدن فونت تغییر اندازه می‌دهد و صفحه را جابه‌جا می‌کند. فونت اصلی را preload کنید، font-display مناسب بگذارید و فقط وزن‌هایی را بارگذاری کنید که واقعاً استفاده می‌شوند.
CLS جای بنر یا ویدیو
هر محتوایی که بعد از نمایش اولیه اضافه می‌شود، اگر جایش از قبل رزرو نشده باشد، بقیه‌ی صفحه را هل می‌دهد. برای تصویر و ویدیو width و height یا aspect-ratio تعیین کنید و برای بنر و جاسازی‌ها از قبل ظرفی با ارتفاع ثابت بگذارید.
INP دکمه‌ی افزودن به سبد
اگر کلیک روی دکمه اول محاسبه‌ی سنگین، چند درخواست پشت‌سرهم یا به‌روزرسانی بزرگ صفحه را اجرا کند و بعد واکنش نشان دهد، کاربر احساس می‌کند دکمه کار نمی‌کند و دوباره می‌زند. بازخورد دیداری را فوراً نشان دهید و کار سنگین را بعد از آن، تکه‌تکه انجام دهید.
INPLCP ابزارک گفت‌وگوی آنلاین
ابزک‌های گفت‌وگو، پیکسل‌های تبلیغاتی و ابزارهای آمار شخص ثالث اغلب جاوااسکریپت زیادی بارگذاری می‌کنند. آن‌ها را بعد از بارگذاری محتوای اصلی یا بعد از اولین تعامل کاربر فعال کنید و هرکدام را که کاری برایتان انجام نمی‌دهد حذف کنید.
جابه‌جایی صفحه را خودتان ببینید
CLS را با خواندن تعریفش نمی‌شود حس کرد. در دو قاب زیر یک متن یکسان هست. در قاب اول جایی برای بنر رزرو نشده و در قاب دوم، ظرفی با ارتفاع ثابت از قبل منتظر بنر است. دکمه‌ی بارگذاری را بزنید و حرکت متن را مقایسه کنید.
بدون جای رزرو
راهنمای انتخاب کفش کوهنوردی
کفی، جنس رویه و وزن کفش سه چیزی هستند که پیش از خرید باید بررسی شوند.
مشاهده‌ی محصولات
هنوز بنری بارگذاری نشده است.
با جای رزرو
راهنمای انتخاب کفش کوهنوردی
کفی، جنس رویه و وزن کفش سه چیزی هستند که پیش از خرید باید بررسی شوند.
مشاهده‌ی محصولات
هنوز بنری بارگذاری نشده است.
در قاب اول، اگر کاربر درست در همان لحظه می‌خواست روی «مشاهده‌ی محصولات» بزند، انگشتش روی بنر می‌نشست. همین تجربه است که CLS اندازه می‌گیرد. جابه‌جایی‌هایی که تا نیم ثانیه بعد از کلیک یا تایپ خود کاربر رخ می‌دهند حساب نمی‌شوند؛ مثلاً باز شدن یک بخش وقتی کاربر روی آن زده است، چون انتظارش را داشته.
نیم ثانیه‌ای که کاربر را به کلیک دوباره وامی‌دارد
INP از همه‌ی معیارها کمتر شناخته شده است، چون در نگاه اول سایت کند به نظر نمی‌رسد؛ فقط کلیک‌ها «سنگین» حس می‌شوند. در ابزار زیر دو دکمه هست که هر دو کار یکسانی انجام می‌دهند. اولی قبل از هر واکنشی کار سنگین را تمام می‌کند و دومی اول بازخورد می‌دهد و بعد کار را تکه‌تکه انجام می‌دهد. زمانی که نشان داده می‌شود، روی همین دستگاه شما اندازه گرفته شده است.
این بخش برای اندازه‌گیری به جاوااسکریپت نیاز دارد. اگر آن را نمی‌بینید، مرورگر شما جاوااسکریپت را اجرا نکرده است.
روی گوشی‌های میان‌رده، فاصله‌ی این دو دکمه معمولاً بیشتر از لپ‌تاپ است؛ دقیقاً به همین دلیل گزارش موبایل سخت‌گیرانه‌تر به نظر می‌رسد. راه‌حل‌های اصلی INP این‌هاست: کاهش جاوااسکریپتی که در هر صفحه اجرا می‌شود، شکستن کارهای طولانی به تکه‌های کوچک‌تر، به تعویق انداختن اسکریپت‌های غیرضروری و نمایش بازخورد پیش از انجام کار سنگین.
در سایت‌های وردپرسی معمولاً کجا را باید گشت؟
بیشتر مشکلات سرعت وردپرس از خود وردپرس نیست؛ از چیزهایی است که رویش سوار شده‌اند. صفحه‌سازهای سنگین که برای یک بخش ساده ده‌ها لایه HTML می‌سازند، افزونه‌هایی که فایل‌هایشان را در همه‌ی صفحه‌ها بارگذاری می‌کنند و اسلایدرهای بالای صفحه سه مظنون همیشگی‌اند. یک افزونه‌ی کش خوب هم کمک می‌کند، اما جای قالب سبک و افزونه‌های کم‌تعداد را نمی‌گیرد.
اگر در حال راه‌اندازی سایت تازه هستید، در طراحی سایت وردپرس می‌شود از همان ابتدا با قالب سبک، تصاویر بهینه و افزونه‌های حساب‌شده به عددهای سبز رسید؛ کاری که بعد از راه‌اندازی، معمولاً پرهزینه‌تر است.
وقتی ساختار سایت، خودش مانع است
گاهی هر چه تصویر فشرده و افزونه حذف می‌شود، INP و LCP تکان نمی‌خورند. در این حالت مشکل در معماری است: صفحه‌ای که کل محتوایش را با جاوااسکریپت در مرورگر می‌سازد، پنلی که با هر کلیک کل صفحه را دوباره رسم می‌کند یا سروری که برای هر بازدید ده‌ها پرس‌وجوی سنگین اجرا می‌کند.
برای چنین پروژه‌هایی، طراحی سایت اختصاصی این امکان را می‌دهد که سرعت از روز اول در معماری دیده شود: نمایش سمت سرور برای محتوای اصلی، بارگذاری مرحله‌ای بخش‌های تعاملی و کش در سطح سرور. سرعت در این سایت‌ها نتیجه‌ی طراحی است، نه وصله‌ای که بعداً اضافه شود.
عدد خودتان را از کجا ببینید؟
سه منبع کنار هم تصویر کاملی می‌دهند. PageSpeed Insights برای هر نشانی هم داده‌ی میدانی (اگر موجود باشد) و هم تحلیل آزمایشگاهی را نشان می‌دهد. گزارش Core Web Vitals در Search Console صفحه‌های مشابه را گروه‌بندی می‌کند و می‌گوید کدام گروه مشکل دارد. و ابزارهای بررسی صفحه، کنار سرعت، مشکلات دیگری مثل تصاویر بدون ابعاد یا فایل‌های مسدودکننده را هم فهرست می‌کنند.
برای یک بررسی سریع، می‌توانید صفحه‌ی اصلی یا یکی از صفحه‌های مهم سایتتان را در آنالیز رایگان سئو ازکی وب بسنجید. گزارش آن کنار وضعیت عنوان‌ها و ساختار فنی، بخش عملکرد صفحه را هم دارد و نشان می‌دهد از کجا شروع کنید.
Core Web Vitals چقدر روی رتبه اثر دارد؟
گوگل این معیارها را بخشی از سیگنال‌های «تجربه‌ی صفحه» می‌داند، اما خودش هم تأکید کرده که مرتبط بودن و کیفیت محتوا مهم‌تر است. صفحه‌ای با عددهای عالی اما محتوای ضعیف، از صفحه‌ای با محتوای بهتر و سرعت متوسط جلو نمی‌زند. اثر این معیارها بیشتر وقتی دیده می‌شود که چند صفحه از نظر محتوا نزدیک به هم باشند.
اثر مهم‌تر، مستقیم روی کاربر است. صفحه‌ای که دیر می‌آید، زیر انگشت می‌پرد یا به کلیک دیر جواب می‌دهد، بازدیدکننده‌ی بیشتری را پیش از تماس یا خرید از دست می‌دهد؛ چه گوگل آن را در رتبه لحاظ کند چه نکند. در برنامه‌ی سئو سایت، بهبود این معیارها کنار محتوا و ساختار فنی دیده می‌شود، نه جدا از آن.
ترتیب کار؛ از کجا شروع کنیم؟
فهرست زیر را مثل یک برنامه‌ی کار ببینید. هر موردی را که در سایتتان انجام شده تیک بزنید تا پیشرفت را ببینید. ترتیب موارد عمداً از کارهای کم‌هزینه و پراثر شروع می‌شود.
آخرین مورد را دست‌کم نگیرید. چون داده‌ی میدانی میانگین ۲۸ روز گذشته است، اثر اصلاحات یک‌شبه در گزارش‌ها دیده نمی‌شود. اگر بعد از یک هفته عدد تغییر نکرده، لزوماً به معنی بی‌اثر بودن کار نیست.
سرعت، بخشی از طراحی است
Core Web Vitals سه عدد ساده‌اند که یک واقعیت را نشان می‌دهند: کاربر صفحه را با چشم و انگشتش قضاوت می‌کند. محتوای اصلی باید زود بیاید، کلیک باید فوراً جواب بگیرد و صفحه نباید زیر دست کاربر جابه‌جا شود. هرکدام از این سه، اگر در مرحله‌ی طراحی دیده شود، ارزان‌تر از وقتی است که بعداً اصلاح شود.
اگر می‌خواهید سایت تازه‌تان از روز اول با این معیارها ساخته شود، صفحه‌ی طراحی سایت ازکی وب روند کار و آنچه در هر مرحله بررسی می‌شود را توضیح داده است.