پاسخ کوتاه: Core Web Vitals مجموعه‌ای از سه معیار تجربه واقعی کاربر است: LCP سرعت نمایش محتوای اصلی را می‌سنجد، INP واکنش‌پذیری صفحه پس از تعامل را ارزیابی می‌کند و CLS ثبات چیدمان را نشان می‌دهد. برای قرارگرفتن در محدوده «خوب»، در صدک ۷۵ بازدیدها باید LCP حداکثر ۲.۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰.۱ باشد. این معیارها هم برای تجربه کاربر مهم‌اند و هم در سیستم‌های رتبه‌بندی گوگل استفاده می‌شوند؛ بااین‌حال امتیاز خوب به‌تنهایی رتبه بالا را تضمین نمی‌کند.

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

Core Web Vitals چیست و هر معیار چه چیزی را می‌سنجد؟

Core Web Vitals یا «شاخص‌های حیاتی وب» بخشی از مجموعه Web Vitals است که گوگل برای سنجش چند جنبه اساسی تجربه صفحه معرفی کرده است. طبق راهنمای رسمی Core Web Vitals در Google Search Central، این سه معیار بر بارگذاری، واکنش‌پذیری و ثبات بصری تمرکز دارند. عددها ابزار تشخیص‌اند؛ معنای واقعی آن‌ها این است که کاربر چه زمانی محتوای مهم را می‌بیند، پس از کلیک یا لمس چقدر منتظر پاسخ می‌ماند و آیا صفحه هنگام خواندن یا اقدام زیر دست او جابه‌جا می‌شود.

LCP؛ زمان نمایش محتوای اصلی

Largest Contentful Paint زمان رندر بزرگ‌ترین عنصر محتوایی قابل مشاهده در نمای اولیه را اندازه می‌گیرد. این عنصر ممکن است تصویر شاخص، بنر اصلی، پوستر ویدیو یا یک بلوک بزرگ متن باشد. LCP خوب حداکثر ۲.۵ ثانیه است؛ بازه بیشتر از ۲.۵ تا ۴ ثانیه «نیازمند بهبود» و بیشتر از ۴ ثانیه «ضعیف» محسوب می‌شود. LCP فقط سرعت دریافت HTML نیست: پاسخ سرور، کشف منبع، دانلود تصویر، فونت، CSS مسدودکننده و زمان رندر مرورگر می‌توانند آن را تغییر دهند.

INP؛ واکنش‌پذیری در طول بازدید

Interaction to Next Paint تأخیر تعامل‌های کاربر مانند کلیک، لمس و فشردن کلید را در طول حضور او روی صفحه بررسی می‌کند و با کنارگذاشتن موارد پرت، نماینده‌ای از کندترین تعامل ارائه می‌دهد. INP خوب حداکثر ۲۰۰ میلی‌ثانیه است؛ بین ۲۰۰ تا ۵۰۰ میلی‌ثانیه نیازمند بهبود و بیشتر از ۵۰۰ میلی‌ثانیه ضعیف است. صفحه‌ای می‌تواند سریع باز شود اما پس از کلیک روی منو، فیلتر محصول یا فرم، به‌دلیل اجرای سنگین جاوااسکریپت دیر پاسخ دهد؛ چنین صفحه‌ای LCP خوب و INP ضعیف خواهد داشت.

CLS؛ ثبات چیدمان

Cumulative Layout Shift جابه‌جایی‌های غیرمنتظره عناصر قابل مشاهده را در طول عمر صفحه جمع‌بندی می‌کند. CLS زمان نیست و واحد ندارد. مقدار خوب آن حداکثر ۰.۱، مقدار بین ۰.۱ تا ۰.۲۵ نیازمند بهبود و بیشتر از ۰.۲۵ ضعیف است. اگر کاربر قصد لمس یک دکمه را داشته باشد اما بارگذاری تبلیغ، تصویر یا فونت آن را جابه‌جا کند، تجربه آزاردهنده و گاهی پرخطر ایجاد می‌شود. جابه‌جایی ناشی از اقدام آگاهانه کاربر همیشه مشکل محسوب نمی‌شود؛ مسئله تغییر غیرمنتظره است.

ارزیابی باید در صدک ۷۵ بارگذاری‌ها و به‌صورت جداگانه برای موبایل و دسکتاپ انجام شود. یعنی حداقل سه‌چهارم تجربه‌های واقعی باید به آستانه خوب برسند. میانگین ساده می‌تواند تعداد قابل‌توجهی تجربه ضعیف را پنهان کند. همچنین وضعیت کلی یک گروه URL در Search Console از ضعیف‌ترین معیار آن اثر می‌گیرد؛ اگر LCP و CLS خوب اما INP ضعیف باشد، آن گروه هنوز «Good» نیست.

داده میدانی و آزمایشگاهی را چگونه درست بخوانیم؟

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

گزارش Core Web Vitals در Search Console URLهای دارای داده کافی را بر اساس نوع معیار، وضعیت و الگوی مشابه گروه‌بندی می‌کند. این گزارش برای فهم گستره مشکل مناسب است، اما الزاماً برای هر URL داده اختصاصی نمایش نمی‌دهد. اگر صفحه‌ای داده کافی نداشته باشد، نبودن آن در گزارش به معنی خوب یا بد بودنش نیست. URL نمونه را باز کنید، صفحات هم‌گروه را بررسی کنید و مطمئن شوید قالب مشترک آن‌ها واقعاً علت مشترکی دارد.

PageSpeed Insights معمولاً داده میدانی موجود را در کنار نتیجه آزمایشگاهی Lighthouse نشان می‌دهد. داده URL و داده مبدأ را با هم اشتباه نگیرید؛ وقتی خود URL نمونه کافی ندارد، ممکن است اطلاعات کل مبدأ نمایش داده شود. Chrome DevTools و Lighthouse برای یافتن زنجیره درخواست، عنصر LCP، وظایف طولانی، تغییرات چیدمان و کد استفاده‌نشده مفیدند. اما یک نمره آزمایشگاهی، نتیجه قطعی همه کاربران نیست.

یک روند تشخیص قابل تکرار

1. در Search Console وضعیت موبایل و دسکتاپ را جدا ببینید و گروه URL آسیب‌دیده را مشخص کنید.
2. از هر گروه دو یا سه صفحه واقعی انتخاب کنید؛ فقط صفحه اصلی را آزمایش نکنید.
3. PageSpeed Insights را برای تشخیص تفاوت داده میدانی و آزمایشگاهی بخوانید.
4. در DevTools عنصر LCP، وظایف طولانی و منابع ایجادکننده تغییر چیدمان را پیدا کنید.
5. آزمون را در حالت ورودنکرده، با کش سرد و سپس کش گرم تکرار کنید.
6. پس از تغییر، همان سناریو و همان صفحه را دوباره بسنجید و نتیجه را ثبت کنید.

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

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

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

پاسخ سرور و مسیر تحویل را کوتاه کنید

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

عنصر LCP را زود کشف و درست اولویت‌بندی کنید

تصویر اصلی را در HTML اولیه قرار دهید و آن را با جاوااسکریپت دیرهنگام تزریق نکنید. برای تصویر بالای صفحه از lazy loading استفاده نکنید؛ تنبلی بارگذاری برای رسانه‌های پایین صفحه مناسب است. ویژگی‌های responsive image مانند srcset و sizes کمک می‌کنند مرورگر فایل متناسب با نمایشگر را بگیرد. در موارد لازم می‌توان با preload یا fetchpriority به منبع اصلی اولویت داد، اما اولویت‌دادن هم‌زمان به چند منبع نتیجه معکوس دارد.

فرمت WebP یا AVIF، ابعاد متناسب و فشرده‌سازی معقول حجم انتقال را کم می‌کنند. کیفیت را آن‌قدر پایین نیاورید که تصویر شاخص مخدوش شود. راهنمای سئو تصاویر سایت مسیر انتخاب نام، اندازه، alt و بهینه‌سازی فایل را با جزئیات بیشتری پوشش می‌دهد. اگر LCP متن است، بارگذاری فونت، CSS بحرانی و تأخیر نمایش متن را بررسی کنید؛ تغییر کورکورانه همه فونت‌ها به یک راه‌حل واحد ضروری نیست.

رندر را از منابع غیرضروری آزاد کنید

CSS استفاده‌نشده، فایل‌های حجیم قالب و اسکریپت‌های همگانی می‌توانند رندر بالای صفحه را عقب بیندازند. کد ضروری نمای اولیه را در اولویت قرار دهید و منابع پایین صفحه را با روشی سازگار به تعویق بیندازید. ترتیب وابستگی‌ها را حفظ کنید؛ defer یا delayکردن بدون آزمون ممکن است منو، فرم یا ابزار سنجش را خراب کند. نتیجه را با سناریوی واقعی روی موبایل و چند قالب صفحه بررسی کنید.

INP ضعیف را چگونه تشخیص و اصلاح کنیم؟

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

تعامل کند را در زمینه واقعی پیدا کنید

گزارش میدانی می‌گوید کاربران تأخیر دیده‌اند، اما برای اصلاح باید بدانید کدام تعامل و کدام کد عامل آن بوده است. در Performance panel مرورگر یک سناریوی مشخص ضبط کنید: بازکردن منوی موبایل، انتخاب فیلتر، افزودن محصول، تغییر تب یا ارسال فرم. وظایف طولانی، handler رویداد و تغییرات سبک و چیدمان پس از تعامل را بررسی کنید. ابزارهای RUM در صورت پیاده‌سازی درست می‌توانند عنصر و نوع تعامل کند را در محیط واقعی ثبت کنند، بدون آنکه داده شخصی کاربر را جمع‌آوری کنند.

کار طولانی را تقسیم و مقدار کار را کم کنید

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

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

بازخورد فوری را فراموش نکنید

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

برای کاهش CLS چه تغییراتی بیشترین اثر را دارند؟

بر اساس راهنمای رسمی بهینه‌سازی CLS در web.dev، رسانه بدون ابعاد، محتوای تزریقی و فونت از علت‌های رایج تغییر چیدمان‌اند. تشخیص فقط با نگاه‌کردن به صفحه آسان نیست؛ بعضی جابه‌جایی‌ها پس از اسکرول، تعامل، بارگذاری تبلیغ یا بازگشت به صفحه رخ می‌دهند. بخش Layout Shifts در DevTools و داده RUM به پیدا کردن عنصر جابه‌جا‌شده کمک می‌کنند.

برای تصویر، ویدیو و embed فضا رزرو کنید

ویژگی width و height یا نسبت ابعاد CSS را برای رسانه تعریف کنید تا مرورگر پیش از دانلود فایل، فضای آن را بداند. برای iframe، نقشه، ویدیو و پست شبکه اجتماعی نیز یک ظرف با ابعاد یا حداقل ارتفاع مشخص در نظر بگیرید. طراحی واکنش‌گرا با تعریف ابعاد تناقض ندارد؛ مرورگر می‌تواند نسبت را حفظ کند و عرض را با ظرف تطبیق دهد.

محتوای جدید را بالای بخش در حال مشاهده تزریق نکنید

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

رفتار فونت و انیمیشن را کنترل کنید

جایگزینی فونت می‌تواند اندازه و شکست خطوط را تغییر دهد. فونت‌های ضروری را سبک و محدود کنید، زیرمجموعه حروف لازم را بسازید و راهبرد font-display را با نیاز برند و خوانایی آزمایش کنید. فونت جایگزین با متریک نزدیک، تغییر چیدمان را کمتر می‌کند. برای حرکت عناصر از transform و opacity استفاده کنید؛ انیمیشن ویژگی‌هایی مانند top، left، width و height اغلب باعث محاسبه دوباره چیدمان می‌شود.

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

چگونه اصلاحات را اولویت‌بندی و در وردپرس اجرا کنیم؟

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

افزونه کش را معادل بهینه‌سازی ندانید

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

تغییرات را کوچک، قابل بازگشت و مستند کنید

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

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

پس از اصلاح چگونه نتیجه را اعتبارسنجی و پایش کنیم؟

بلافاصله پس از انتشار، آزمون آزمایشگاهی و سناریوهای کارکردی را تکرار کنید. سپس داده RUM یا داده میدانی را در طول زمان ببینید. گزارش Search Console به‌دلیل ماهیت داده CrUX با تأخیر تغییر می‌کند. گزینه Validate Fix برای شروع پیگیری گروه مناسب است، اما جای تأیید فنی و پایش مستقل را نمی‌گیرد. تغییر فصل، کمپین، ابزار جدید یا محتوای سنگین می‌تواند ترکیب کاربران و نتیجه را عوض کند.

گوگل در مستندات تجربه صفحه تأکید می‌کند که یک سیگنال واحد همه جنبه‌های تجربه را پوشش نمی‌دهد و امتیاز خوب Core Web Vitals جای ارتباط، کیفیت و سودمندی محتوا را نمی‌گیرد. بنابراین پروژه را فقط با نمره Lighthouse تحویل ندهید. نرخ تکمیل فرم، خطای تعامل، رضایت کاربران، دسترس‌پذیری و شاخص‌های کسب و کار را نیز همراه با عملکرد ببینید.

چک‌لیست نهایی کنترل کیفیت

1. آیا داده موبایل و دسکتاپ و تفاوت URL با مبدأ درست خوانده شده است؟
2. آیا عنصر LCP در صفحات نمونه شناسایی و مسیر کشف و دانلود آن بررسی شده است؟
3. آیا تعامل‌های واقعی مانند منو، فیلتر و فرم برای INP آزمایش شده‌اند؟
4. آیا تصاویر، embedها، اعلان‌ها و فونت‌ها فضای پایدار دارند؟
5. آیا تغییر روی چند قالب و وضعیت کاربر، نه فقط صفحه اصلی، کنترل شده است؟
6. آیا داده‌های تحلیل، رضایت کاربر و درآمد پس از بهینه‌سازی سالم مانده‌اند؟
7. آیا پایش خودکار یا بازبینی دوره‌ای برای جلوگیری از پسرفت تعریف شده است؟

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

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

آخرین بررسی منابع: ۲۹ تیر ۱۴۰۵. آستانه‌ها و توصیه‌های متغیر این مقاله از مستندات رسمی Google Search Central، Search Console و web.dev بررسی شده‌اند.