Core Web Vitals چیست؟ راهنمای LCP، معیار INP و CLS

Core Web Vitals مجموعه‌ای از سه معیار LCP، معیار INP و CLS است که کیفیت تجربه واقعی کاربران در یک صفحه وب را از نظر سرعت نمایش محتوای اصلی، سرعت پاسخگویی به تعامل و ثبات چیدمان ارزیابی می‌کند. LCP باید حداکثر 2.5 ثانیه، INP حداکثر 200 میلی‌ثانیه و CLS حداکثر 0.1 باشد تا وضعیت صفحه خوب محسوب شود. این اعداد فقط امتیازهای فنی نیستند؛ کندی در نمایش محتوا، تاخیر پس از کلیک یا جابجایی ناگهانی عناصر می‌تواند مستقیما تجربه کاربر را خراب کند. به همین دلیل بررسی Core Web Vitals در سرچ کنسول یکی از بخش‌های مهم تحلیل فنی سایت است.

Core Web Vitals چیست و دقیقا چه چیزی را اندازه می گیرد؟

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

• LCP یا Largest Contentful Paint: عملکرد بارگذاری و زمان نمایش محتوای اصلی صفحه
• INP یا Interaction to Next Paint: سرعت پاسخ صفحه به تعاملات کاربر
• CLS یا Cumulative Layout Shift: میزان ثبات بصری عناصر صفحه

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

محدوده استاندارد LCP، معیار INP و CLS چقدر است؟

صرف دیدن یک عدد در PageSpeed Insights یا Search Console کافی نیست. باید بدانیم هر عدد در کدام محدوده قرار می‌گیرد و گوگل برای ارزیابی تجربه واقعی کاربران چه مرزی تعیین کرده است.

معیار	خوب	نیازمند بهبود	ضعیف
LCP	حداکثر 2.5 ثانیه	بیشتر از 2.5 تا 4 ثانیه	بیشتر از 4 ثانیه
INP	حداکثر 200 میلی ثانیه	بیشتر از 200 تا 500 میلی ثانیه	بیشتر از 500 میلی ثانیه
CLS	حداکثر 0.1	بیشتر از 0.1 تا 0.25	بیشتر از 0.25

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

LCP چیست و چرا بزرگ ترین تصویر صفحه همیشه مقصر نیست؟

LCP زمان لازم برای نمایش بزرگ‌ترین تصویر یا بلوک متنی قابل مشاهده در محدوده اولیه صفحه را اندازه می‌گیرد. کاربر معمولا از همین نقطه احساس می‌کند محتوای اصلی صفحه آماده مشاهده شده است. برای مثال، LCP یک صفحه ممکن است تصویر اصلی محصول، بنر بالای صفحه، تصویر شاخص مقاله یا حتی یک تیتر بزرگ متنی باشد. هدف مناسب، LCP برابر با 2.5 ثانیه یا کمتر است.

مهم ترین دلایل LCP ضعیف

مشکل LCP همیشه با فشرده کردن تصویر حل نمی‌شود. زمان LCP از چند مرحله تشکیل شده و اختلال در هر مرحله می‌تواند نتیجه را خراب کند:

• TTFB بالا و پاسخگویی کند سرور
• تصویر Hero بسیار حجیم
• دیر شناسایی شدن منبع LCP توسط مرورگر
• Lazy Load شدن اشتباه تصویر اصلی
• CSS یا JavaScript مسدودکننده رندر
• استفاده بیش از حد از اسکریپت‌های خارجی
• تاخیر در بارگذاری فونت
• رندر محتوای اصلی بعد از اجرای JavaScript

یکی از اشتباهات رایج، فعال کردن Lazy Load روی تمام تصاویر سایت است. در راهنمای web.dev صراحتا توصیه می‌شود که تصویر LCP را Lazy Load نکنید؛ زیرا این کار شروع دانلود منبع اصلی را عقب می‌اندازد. در شرایط مناسب می‌توان برای تصویر اصلی از fetchpriority=”high” نیز استفاده کرد.

برای بهبود LCP از کجا شروع کنیم؟

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

1. کاهش TTFB با بهینه‌سازی سرور، کش و در صورت نیاز CDN
2. ارائه تصویر اصلی با ابعاد واقعی و فرمت بهینه مانند WebP یا AVIF
3. حذف Lazy Load از عنصر LCP
4. کاهش CSS بلااستفاده و منابع Render Blocking
5. Defer کردن JavaScript غیرضروری
6. قابل شناسایی کردن منبع اصلی از HTML اولیه
7. کاهش تعداد منابعی که برای پهنای باند با عنصر LCP رقابت می‌کنند

نکته مهم‌تر اینکه بهینه‌سازی باید براساس علت انجام شود. ممکن است حجم تصویر پایین باشد، اما JavaScript اجازه نمایش آن را تا چند ثانیه ندهد؛ در این حالت فشرده‌سازی بیشتر تصویر عملا تاثیر قابل توجهی ندارد.

معیار INP چیست و چرا سایت سریع هنوز ممکن است کند احساس شود؟

معیار INP بخش واکنش پذیری را اندازه‌گیری می‌کند. این شاخص بررسی می‌کند بعد از کلیک، لمس صفحه یا فشردن یک کلید، چه مدت طول می‌کشد تا کاربر نتیجه بصری تعامل خود را مشاهده کند. صفحه‌ای ممکن است ظرف یک ثانیه نمایش داده شود، اما کاربر روی منوی موبایل کلیک کند و منو نیم ثانیه بعد باز شود. چنین سایتی از نظر Load سریع است، اما از دید کاربر Responsive نیست. INP مناسب باید 200 میلی ثانیه یا کمتر باشد. مقدار بیشتر از 500 میلی ثانیه در محدوده ضعیف قرار می‌گیرد.

چه عواملی INP را خراب می کنند؟

در بسیاری از سایت‌های امروزی، JavaScript مهم‌ترین نقطه بررسی است. مرورگر برای پاسخ به تعامل کاربر باید Main Thread آزاد داشته باشد؛ اگر این بخش مشغول اجرای یک Task طولانی باشد، پاسخ به کلیک نیز منتظر می‌ماند. دلایل متداول عبارتند از:

• فایل‌های JavaScript بزرگ
• اجرای Long Task روی Main Thread
• اسکریپت‌های تبلیغات، چت آنلاین و ابزارهای شخص ثالث
• Event Handlerهای سنگین
• DOM بسیار بزرگ
• اجرای محاسبات غیرضروری بلافاصله پس از تعامل
• Layout Thrashing
• اجرای همزمان چند اسکریپت هنگام بارگذاری صفحه

چگونه INP را بهتر کنیم؟

اول باید تعامل کند پیدا شود. صرفا دانستن اینکه INP برابر با 350 میلی ثانیه است، برای توسعه‌دهنده کافی نیست. پس از پیدا کردن تعامل مشکل‌دار می‌توان:

• JavaScript غیرضروری را حذف کرد یا به تعویق انداخت.
• Long Taskها را به Taskهای کوچک‌تر تقسیم کرد.
• عملیات غیرضروری Event Handler را بعد از نمایش پاسخ اولیه اجرا کرد.
• اسکریپت‌های Third-party را محدود کرد.
• ساختار DOM را در صفحات بسیار سنگین ساده‌تر کرد.
• از اجرای چند عملیات Layout پشت سر هم جلوگیری کرد.

طبق راهنمای web.dev، معیار INP از Input Delay، زمان پردازش Event Callback و Presentation Delay تشکیل می‌شود. پیدا کردن اینکه تاخیر در کدام بخش اتفاق افتاده، مسیر اصلاح را بسیار کوتاه‌تر می‌کند.

CLS چیست و چرا جابجایی کوچک عناصر مهم است؟

فاکتور CLS میزان تغییر ناخواسته جای عناصر قابل مشاهده را اندازه‌گیری می‌کند. احتمالا صفحه‌ای را دیده‌اید که قصد دارید در آن روی یک دکمه کلیک کنید، اما ناگهان بنر یا تصویر بالای آن ظاهر می‌شود و دکمه پایین می‌رود. این دقیقا نمونه‌ای از تجربه‌ای است که CLS می‌خواهد اندازه بگیرد. امتیاز مناسب CLS حداکثر 0.1 است. برخلاف LCP و INP، این معیار واحد زمانی ندارد.

رایج ترین دلایل CLS بالا

بخش بزرگی از مشکلات CLS به این دلیل اتفاق می‌افتد که مرورگر قبل از دریافت محتوا نمی‌داند باید چه فضایی برای آن کنار بگذارد. موارد رایج شامل این موارد است:

• تصاویر بدون Width و Height
• ویدئو و iframe بدون فضای رزروشده
• بنرهای تبلیغاتی که بعدا وارد صفحه می‌شوند
• نوارهای اطلاع‌رسانی ناگهانی
• فونت‌هایی که بعد از بارگذاری ابعاد متن را تغییر می‌دهند
• محتوای Dynamic که بالای محتوای موجود اضافه می‌شود

قرار دادن Width و Height روی تصاویر یا تعریف aspect-ratio به مرورگر اجازه می‌دهد پیش از دانلود تصویر، فضای مورد نیاز آن را محاسبه کند و از جابجایی محتوا جلوگیری شود.

Core Web Vitals در سرچ کنسول چگونه تفسیر می شود؟

گزارش Core Web Vitals در سرچ کنسول برای پیدا کردن مشکلات گسترده سایت مناسب‌تر از بررسی تصادفی چند URL است. Search Console داده کاربران واقعی Chrome را دریافت می‌کند و URLهای مشابه را به صورت گروهی گزارش می‌دهد. در گزارش، اطلاعات موبایل و دسکتاپ جدا هستند و صفحات معمولا در سه وضعیت قرار می‌گیرند:

• Good
• Need improvement
• Poor

سرچ کنسول همچنین نوع مشکل را مشخص می‌کند؛ برای مثال ممکن است گروهی از صفحات مشکل LCP داشته باشند و گروه دیگری با INP ضعیف مواجه باشند. نکته مهم این است که وضعیت گروه بر اساس ضعیف‌ترین معیار تعیین می‌شود. بنابراین خوب بودن LCP و CLS نمی‌تواند یک INP ضعیف را جبران کند.

چرا بعضی صفحات در گزارش دیده نمی شوند؟

نبودن یک URL در گزارش الزاما به معنی سالم بودن آن نیست. سرچ کنسول برای نمایش گزارش به حجم کافی از داده کاربران واقعی نیاز دارد و فقط URLهایی که شرایط لازم را داشته باشند وارد گزارش می‌شوند. به همین دلیل سایت‌های کم ترافیک یا صفحات جدید ممکن است عبارت No Data را مشاهده کنند.

بعد از اصلاح مشکل چه اتفاقی می افتد؟

تغییر وضعیت معمولا فوری نیست. داده‌های Core Web Vitals در سرچ کنسول بر اساس تجربه کاربران واقعی شکل می‌گیرد و گوگل برای بررسی اصلاحات یک دوره مانیتورینگ در نظر می‌گیرد. قابلیت Start Tracking می‌تواند یک دوره 28 روزه بررسی داده‌های CrUX را آغاز کند. بنابراین انتظار اینکه چند ساعت پس از نصب افزونه کش همه URLها سبز شوند، واقع‌بینانه نیست.

چرا PageSpeed Insights سبز است اما سرچ کنسول خطا می دهد؟

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

• Field Data: تجربه کاربران واقعی را نشان می‌دهد. شرایط اینترنت، مدل موبایل، قدرت CPU، موقعیت جغرافیایی و رفتار کاربر روی آن تاثیر دارند.
• Lab Data: نتیجه آزمایشی است که در شرایط کنترل شده اجرا می‌شود و برای Debug کردن مشکل بسیار مفید است.

PageSpeed Insights می‌تواند هر دو نوع داده را نمایش دهد، درحالی‌که گزارش سرچ کنسول بر داده واقعی کاربران متکی است. به همین دلیل ممکن است Lighthouse امتیاز 95 بدهد، اما وضعیت واقعی کاربران همچنان مشکل داشته باشد. web.dev نیز توصیه می‌کند وقتی CrUX Data در دسترس است، برای تشخیص وضعیت واقعی ابتدا داده کاربران واقعی بررسی شود. پس Field Data می‌گوید آیا واقعا مشکل دارید؛ Lab Data کمک می‌کند بفهمید چرا مشکل دارید.

آموزش Core Web Vitals: مسیر درست برای بهینه سازی چیست؟

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

1. گزارش Core Web Vitals را در سرچ کنسول برای موبایل و دسکتاپ بررسی کنید.
2. معیار ضعیف و گروه URLهای درگیر را مشخص کنید.
3. صفحات مهم تجاری همان گروه را در اولویت قرار دهید.
4. URL نمونه را در PageSpeed Insights تحلیل کنید.
5. عنصر LCP، تعامل کند یا Layout Shift اصلی را پیدا کنید.
6. با Chrome DevTools علت فنی را بررسی کنید.
7. اصلاح را ابتدا روی چند صفحه یا محیط Staging تست کنید.
8. اثر تغییر روی LCP، معیار INP و CLS را دوباره بسنجید.
9. اصلاح را در سطح Template اجرا کنید تا همه URLهای مشابه بهبود پیدا کنند.
10. تغییر Field Data را در هفته‌های بعد زیر نظر بگیرید.

این روش تفاوت زیادی با سبز کردن ظاهری PageSpeed دارد. هدف واقعی آموزش Core Web Vitals باید رسیدن از عدد قرمز به علت قابل اصلاح باشد.

یک تجربه واقعی از پروژه های نجوانت: وقتی امتیاز 90 کافی نبود

یکی از همکاران ما در تیم سئو نجوانت تجربه جالبی از یکی از پروژه‌های فروشگاهی تعریف می‌کرد. در نگاه اول، وضعیت سایت کاملا مناسب به نظر می‌رسید؛ امتیاز Performance در PageSpeed Insights در برخی صفحات به محدوده 90 رسیده بود و از نظر مدیر سایت، مشکل سرعت تقریبا برطرف شده بود. با این حال، در گزارش Core Web Vitals سرچ کنسول هنوز تعداد قابل توجهی از URLهای موبایل در وضعیت «نیازمند بهبود» قرار داشتند.

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

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

بعد از اصلاح نحوه بارگذاری اسلایدر و مدیریت فضای ویجت چت، وضعیت صفحات به تدریج بهتر شد؛ بدون اینکه افزونه جدیدی نصب شود یا سایت تحت مجموعه‌ای از تنظیمات اضافی قرار بگیرد. چیزی که این تجربه برای من و تیم سئو روشن‌تر کرد این بود که امتیاز بالای PageSpeed همیشه به معنی نبودن مشکل در تجربه واقعی کاربران نیست. در بسیاری از پروژه‌ها، پیدا کردن Bottleneck واقعی بسیار مهم‌تر از اجرای پشت سر هم تکنیک های افزایش سرعت سایت است. در Technical SEO، تشخیص درست مسئله معمولا نصف مسیر حل آن است.

اشتباهات رایج در بهینه سازی Core Web Vitals

بسیاری از پروژه‌ها نه به دلیل پیچیدگی مشکل، بلکه به دلیل انتخاب نقطه شروع اشتباه زمان از دست می‌دهند. چند خطای پرتکرار عبارتند از:

• تمرکز فقط روی Performance Score
• بررسی فقط صفحه اصلی
• تست فقط نسخه Desktop
• Lazy Load کردن تصویر Hero
• حذف یا Delay کردن کورکورانه JavaScript
• نصب همزمان چند افزونه Cache و Optimization
• نادیده گرفتن Third-party Scriptها
• انتظار تغییر فوری Search Console
• بهینه سازی تک تک URLها به جای اصلاح Template مشترک

به خصوص در سایت‌های وردپرسی، اجرای همزمان چند ابزار بهینه‌سازی می‌تواند باعث تداخل Cache، دوباره‌کاری در Minify یا حتی مشکلات ظاهری و عملکردی شود.

چه زمانی Core Web Vitals به یک پروژه تخصصی تبدیل می شود؟

بعضی مشکلات با اصلاح ابعاد تصویر یا تنظیم کش حل می‌شوند؛ اما وقتی چند Template، جاوا اسکریپت اختصاصی، WooCommerce، صفحه‌ساز، Tag Manager و ابزارهای Third-party درگیر باشند، مسئله از یک تنظیم ساده خارج می‌شود. در این شرایط باید عملکرد سایت از چند زاویه همزمان بررسی شود:

• سئوی تکنیکال
• Front-end Performance
• زیرساخت و Server Response
• تجربه کاربری موبایل
• اسکریپت‌های شخص ثالث
• ساختار قالب و DOM
• اهداف Conversion صفحات

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

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

کلام آخر

Core Web Vitals زمانی ارزشمند است که آن را نه به عنوان سه عدد فنی، بلکه به عنوان تصویری از تجربه واقعی کاربر ببینیم. LCP نشان می‌دهد کاربر چه زمانی محتوای اصلی را می‌بیند، INP مشخص می‌کند صفحه چقدر سریع به او پاسخ می‌دهد و CLS ثبات محیطی را که در آن مطالعه، جستجو یا خرید می‌کند می‌سنجد. رسیدن به اعداد سبز هدف خوبی است، اما ارزش اصلی زمانی ایجاد می‌شود که بهبود این شاخص‌ها همزمان سایت را سریع‌تر، قابل اعتمادتر و استفاده از آن را برای کاربران ساده‌تر کند. گوگل نیز توصیه می‌کند Core Web Vitals در کنار سایر ابعاد تجربه صفحه دیده شود، نه به عنوان تنها عامل موفقیت در نتایج جستجو.

سوالات متداول