ممکن است یک صفحه در نگاه اول سریع به نظر برسد، اما وقتی کاربر می خواهد با آن تعامل کند چند ثانیه پاسخ ندهد. ممکن است محتوا خیلی زود روی صفحه ظاهر شود، اما درست زمانی که کاربر قصد دارد روی یک دکمه کلیک کند، یک تصویر یا تبلیغ بارگذاری شود و دکمه جابه جا شود. حتی ممکن است سایت روی لپ تاپ و اینترنت پرسرعت شما کاملا روان باشد، اما بخش قابل توجهی از کاربران موبایل تجربه متفاوتی داشته باشند.
اینجاست که صرفا گفتن «سایت من سریع است» اطلاعات کافی به ما نمی دهد.
Google برای اندازه گیری بخش هایی از تجربه واقعی کاربران، مجموعه ای از معیارها با عنوان Core Web Vitals معرفی کرده است. این معیارها قرار نیست تمام کیفیت یک سایت را در سه عدد خلاصه کنند، اما سه جنبه بسیار مهم از تجربه استفاده از صفحه را قابل اندازه گیری می کنند: سرعت نمایش محتوای اصلی، سرعت پاسخ صفحه به تعامل کاربر و ثبات بصری صفحه.
مجموعه فعلی Core Web Vitals از سه معیار تشکیل شده است:
- LCP برای سنجش سرعت نمایش محتوای اصلی صفحه
- INP برای سنجش پاسخگویی صفحه به تعاملات کاربر
- CLS برای سنجش ثبات بصری و جلوگیری از جابه جایی ناگهانی عناصر
برای اینکه یک صفحه از نظر Core Web Vitals وضعیت خوبی داشته باشد، هدف اصلی این است که LCP حداکثر 2.5 ثانیه، INP حداکثر 200 میلی ثانیه و CLS حداکثر 0.1 باشد؛ آن هم نه فقط در یک تست آزمایشگاهی، بلکه برای بخش بزرگی از کاربران واقعی. Google برای ارزیابی این وضعیت از صدک 75 استفاده می کند و موبایل و دسکتاپ را جداگانه در نظر می گیرد.
در این راهنما ابتدا مفهوم Core Web Vitals را دقیق بررسی می کنیم، سپس سراغ LCP، INP و CLS می رویم، تفاوت داده واقعی و آزمایشگاهی را توضیح می دهیم و در نهایت می بینیم این معیارها چه ارتباطی با SEO دارند و هنگام مشاهده یک وضعیت ضعیف، از کجا باید بررسی را شروع کرد.
Core Web Vitals چیست؟
Core Web Vitals را می توان مجموعه ای از معیارهای استاندارد برای ارزیابی بخش های مهم تجربه کاربر در صفحات وب دانست.
Google این معیارها را طوری انتخاب کرده است که هرکدام یکی از جنبه های اساسی تجربه واقعی استفاده از یک صفحه را نشان دهند. در حال حاضر این سه جنبه عبارتند از:
| جنبه تجربه کاربر | معیار | سوال اصلی |
|---|---|---|
| سرعت بارگذاری محتوای اصلی | LCP | کاربر چه زمانی محتوای اصلی صفحه را می بیند؟ |
| پاسخگویی به تعامل | INP | بعد از کلیک، لمس یا ورودی کاربر، صفحه چقدر سریع واکنش نشان می دهد؟ |
| ثبات بصری | CLS | آیا عناصر صفحه هنگام استفاده ناگهان جابه جا می شوند؟ |
نکته مهم این است که Core Web Vitals را نباید فقط با «سرعت سایت» مترادف بدانیم.
سرعت نمایش محتوا فقط یکی از ابعاد ماجرا است. یک سایت ممکن است محتوای اصلی را در کمتر از دو ثانیه نمایش دهد، اما به دلیل اجرای سنگین JavaScript هنگام کلیک روی منو برای مدتی واکنشی نشان ندهد. در این حالت LCP ممکن است خوب باشد ولی INP ضعیف باشد.
همین طور ممکن است صفحه سریع و پاسخگو باشد، اما تصاویر، تبلیغات یا فونت ها هنگام بارگذاری باعث جابه جایی شدید محتوا شوند. در این حالت مشکل اصلی CLS است.
بنابراین Core Web Vitals تلاش می کند تجربه کاربر را از چند زاویه مکمل بسنجد، نه اینکه تمام تجربه را در یک مفهوم مبهم به نام «سرعت» خلاصه کند.
برای درک جایگاه این موضوع در ساختار کلی سایت، Core Web Vitals را می توان یکی از مباحث مهم سئو تکنیکال دانست؛ با این تفاوت که هدف آن فقط کمک به موتور جستجو نیست و مستقیما با کیفیت تجربه کاربران واقعی ارتباط دارد.
سه معیار اصلی Core Web Vitals کدام اند؟
سه Core Web Vital فعلی عبارتند از Largest Contentful Paint، Interaction to Next Paint و Cumulative Layout Shift.
هر سه باید جداگانه بررسی شوند؛ زیرا هرکدام مشکل متفاوتی را نشان می دهند و راه حل متفاوتی نیز دارند.
LCP چیست؟
LCP مخفف Largest Contentful Paint است.
این معیار زمان نمایش بزرگ ترین عنصر محتوایی قابل مشاهده در Viewport را نسبت به شروع بارگذاری صفحه اندازه گیری می کند. این عنصر می تواند یک تصویر بزرگ، Hero Image، تصویر محصول یا یک بلوک بزرگ متن باشد.
به زبان ساده، LCP تلاش می کند به این سوال پاسخ دهد:
کاربر چه زمانی احساس می کند بخش اصلی محتوای صفحه بالا آمده است؟
فرض کنید وارد صفحه یک محصول می شوید.
هدر و لوگو در لحظه اول نمایش داده می شوند، اما تصویر اصلی محصول که بخش بزرگی از صفحه را اشغال کرده بعد از پنج ثانیه ظاهر می شود. در چنین شرایطی کاربر احتمالا احساس نمی کند صفحه واقعا آماده استفاده شده است، حتی اگر چند عنصر کوچک خیلی زود نمایش داده شده باشند.
LCP برای اندازه گیری همین تجربه طراحی شده است.
LCP خوب چند است؟
| وضعیت | LCP |
|---|---|
| خوب | 2.5 ثانیه یا کمتر |
| نیازمند بهبود | بیشتر از 2.5 تا 4 ثانیه |
| ضعیف | بیشتر از 4 ثانیه |
Google توصیه می کند برای ارائه تجربه مناسب، LCP در صدک 75 بازدیدها حداکثر 2.5 ثانیه باشد.
چه عواملی معمولا LCP را خراب می کنند؟
در یک مقاله Hub لازم نیست تمام جزئیات فنی LCP را باز کنیم، اما برای تشخیص اولیه باید بدانیم که LCP ضعیف معمولا می تواند از چند بخش ناشی شود.
- پاسخ اولیه سرور دیر دریافت می شود.
- تصویر اصلی صفحه بیش از حد سنگین است.
- مرورگر دیر متوجه می شود کدام منبع باید با اولویت بالا دانلود شود.
- CSS یا JavaScript رندر محتوای اصلی را به تاخیر می اندازد.
- عنصر LCP بعد از دریافت فایل ها با تاخیر روی صفحه Render می شود.
اگر LCP Element یک تصویر بزرگ باشد، نحوه انتخاب فرمت، ابعاد و بارگذاری تصویر نیز اهمیت پیدا می کند. این نقطه ارتباط مستقیمی با سئو تصاویر و بهینه سازی فنی تصاویر دارد.
برای بهبود LCP ابتدا باید بفهمیم عنصر LCP چیست و زمان در کدام مرحله تلف می شود؛ نه اینکه بدون تشخیص شروع به فشرده کردن تمام فایل های سایت کنیم.
INP چیست؟
INP مخفف Interaction to Next Paint است و پاسخگویی صفحه به تعاملات کاربر را اندازه گیری می کند.
اگر کاربر روی یک دکمه کلیک کند، یک گزینه را انتخاب کند یا با صفحه از طریق ورودی صفحه کلید تعامل داشته باشد، انتظار دارد نتیجه تعامل خیلی سریع روی صفحه دیده شود.
INP بررسی می کند از زمان شروع یک تعامل واجد شرایط تا زمانی که مرورگر بتواند فریم بعدی را نمایش دهد چه مدت طول می کشد.
برخلاف معیار قدیمی FID که فقط اولین تعامل را بررسی می کرد، INP تعاملات انجام شده در طول حضور کاربر روی صفحه را زیر نظر می گیرد و تلاش می کند تصویری بهتر از پاسخگویی کلی صفحه ارائه دهد.
INP خوب چند است؟
| وضعیت | INP |
|---|---|
| خوب | 200 میلی ثانیه یا کمتر |
| نیازمند بهبود | بیشتر از 200 تا 500 میلی ثانیه |
| ضعیف | بیشتر از 500 میلی ثانیه |
در عمل، INP پایین یعنی کاربر معمولا بعد از تعامل با صفحه خیلی سریع بازخورد بصری دریافت می کند.
INP بالا یعنی ممکن است کاربر کلیک کند و برای لحظه ای احساس کند سایت هنگ کرده یا فرمان او را دریافت نکرده است.
این تجربه در صفحات تعاملی مانند فروشگاه ها، پنل ها، فرم های پیچیده، فیلتر محصولات، منوهای JavaScript و Single Page Applicationها اهمیت بیشتری پیدا می کند.
چرا INP ضعیف می شود؟
یکی از دلایل متداول، اشغال بودن Main Thread مرورگر است.
فرض کنید کاربر روی دکمه «افزودن به سبد خرید» کلیک می کند، اما هم زمان یک اسکریپت بزرگ مشغول پردازش است. تا زمانی که مرورگر نتواند کار قبلی را تمام کند، رسیدگی به تعامل کاربر و نمایش نتیجه ممکن است عقب بیفتد.
اما مشکل INP فقط JavaScript نیست. پیچیدگی Render، اندازه DOM، Handlerهای سنگین، کدهای Third-party و نحوه به روز شدن رابط کاربری نیز می توانند در آن نقش داشته باشند.
نکته اصلی این است که INP درباره احساس پاسخگویی صفحه در زمان استفاده است؛ نه فقط سرعت لود اولیه.
چه اتفاقی برای FID افتاد؟
اگر مقاله ای قدیمی درباره Core Web Vitals بخوانید ممکن است به جای INP با معیار FID یا First Input Delay روبرو شوید.
این اطلاعات مربوط به مجموعه قدیمی Core Web Vitals است.
Google از 12 مارس 2024، INP را جایگزین FID کرد. بنابراین مجموعه فعلی Core Web Vitals شامل LCP، INP و CLS است.
دلیل این تغییر نیز منطقی است.
FID فقط تاخیر اولین تعامل کاربر را اندازه گیری می کرد، در حالی که تجربه یک صفحه ممکن است در اولین کلیک خوب باشد اما در تعاملات بعدی کند شود. INP دید گسترده تری نسبت به پاسخگویی صفحه در طول بازدید کاربر ارائه می کند.
به همین دلیل اگر ابزار، گزارش یا مقاله ای هنوز FID را به عنوان یکی از سه Core Web Vital فعلی معرفی می کند، باید تاریخ آن محتوا را بررسی کنید.
CLS چیست؟
CLS مخفف Cumulative Layout Shift است و ثبات بصری صفحه را اندازه گیری می کند.
یک مثال ساده را تصور کنید.
صفحه محصول باز شده و شما می خواهید روی دکمه «خرید» کلیک کنید. درست در لحظه کلیک، یک بنر در بالای صفحه ظاهر می شود و تمام محتوا چند ده پیکسل پایین می رود. در نتیجه به جای خرید محصول روی گزینه دیگری کلیک می کنید.
این همان تجربه ای است که CLS قصد دارد اندازه گیری کند.
CLS بررسی می کند عناصر قابل مشاهده صفحه تا چه حد به شکل غیرمنتظره موقعیت خود را تغییر می دهند. امتیاز CLS برخلاف LCP و INP واحد زمان ندارد.
CLS خوب چند است؟
| وضعیت | CLS |
|---|---|
| خوب | 0.1 یا کمتر |
| نیازمند بهبود | بیشتر از 0.1 تا 0.25 |
| ضعیف | بیشتر از 0.25 |
هدف این است که کاربر هنگام مطالعه، کلیک یا تعامل با صفحه با جابه جایی ناگهانی محتوا مواجه نشود.
چه چیزهایی معمولا CLS را افزایش می دهند؟
- تصاویر بدون عرض و ارتفاع مشخص
- تبلیغات و iframeهایی که فضای آن ها از قبل رزرو نشده است
- محتوایی که بعدا به بالای بخش فعلی صفحه اضافه می شود
- برخی مشکلات مربوط به بارگذاری Web Font
- کامپوننت های Dynamic با ابعاد نامشخص
در اینجا نیز هدف فقط رسیدن به یک عدد سبز نیست. CLS بالا معمولا نشانه تجربه ای آزاردهنده است که کاربر مستقیما آن را حس می کند.
جدول استاندارد Core Web Vitals
اگر بخواهیم تمام Thresholdهای اصلی را در یک جدول ببینیم، وضعیت به شکل زیر است:
| معیار | خوب | نیازمند بهبود | ضعیف |
|---|---|---|---|
| LCP | حداکثر 2.5 ثانیه | بیشتر از 2.5 تا 4 ثانیه | بیشتر از 4 ثانیه |
| INP | حداکثر 200 میلی ثانیه | بیشتر از 200 تا 500 میلی ثانیه | بیشتر از 500 میلی ثانیه |
| CLS | حداکثر 0.1 | بیشتر از 0.1 تا 0.25 | بیشتر از 0.25 |
این اعداد را نباید فقط روی یک اجرای PageSpeed Insights قضاوت کرد. برای ارزیابی تجربه واقعی، مفهوم صدک 75 اهمیت اساسی دارد.
صدک 75 در Core Web Vitals یعنی چه؟
یکی از مفاهیمی که در Core Web Vitals زیاد می بینید، عبارت 75th percentile یا صدک 75 است.
اگر خیلی ساده توضیح دهیم، Google نمی خواهد فقط تجربه کاربر متوسط یا بهترین کاربران را ببیند. هدف این است که صفحه برای اکثریت قابل توجهی از کاربران تجربه خوبی ایجاد کند.
فرض کنید هزاران بار بازدید از یک صفحه ثبت شده است و LCP هر بازدید با توجه به دستگاه، اینترنت، موقعیت جغرافیایی و شرایط دیگر متفاوت است.
اگر LCP در صدک 75 برابر 2.4 ثانیه باشد، یعنی حدود 75 درصد تجربه های اندازه گیری شده LCP برابر یا بهتر از این مقدار داشته اند و حدود 25 درصد تجربه های کندتری داشته اند.
Google توصیه می کند معیارهای Core Web Vitals در صدک 75 و به تفکیک موبایل و دسکتاپ بررسی شوند.
این روش یک مزیت مهم دارد:
ممکن است سایت برای شما که یک گوشی جدید، اینترنت سریع و موقعیت جغرافیایی نزدیک به سرور دارید بسیار سریع باشد، اما تعداد زیادی از کاربران با دستگاه های ضعیف تر یا شبکه کندتر تجربه خوبی نداشته باشند.
Core Web Vitals قرار است تا حد ممکن آن تجربه گسترده تر را نشان دهد.
تفاوت Core Web Vitals و Web Vitals چیست؟
این دو اصطلاح به هم مرتبط هستند، اما کاملا یکسان نیستند.
Web Vitals مفهوم گسترده تری برای مجموعه معیارهای مرتبط با تجربه و Performance وب است.
Core Web Vitals زیرمجموعه اصلی و محدودتری از این معیارها است که Google آن ها را برای ارزیابی جنبه های کلیدی تجربه کاربر انتخاب کرده است.
در حال حاضر Core Web Vitals فقط سه معیار LCP، INP و CLS را شامل می شود.
معیارهای دیگری مانند FCP یا First Contentful Paint و TTFB یا Time to First Byte نیز می توانند در تحلیل Performance بسیار مهم باشند، اما در حال حاضر جزو سه Core Web Vital اصلی نیستند.
مثلا TTFB می تواند به شما کمک کند بفهمید پاسخ اولیه سرور چقدر زمان برده است و ممکن است یکی از ریشه های LCP ضعیف باشد، اما نباید آن را با یک Core Web Vital مستقل اشتباه گرفت.
همین تفاوت باعث می شود هنگام تحلیل سرعت سایت به جای تمرکز کور روی سه عدد، از معیارهای تشخیصی دیگر نیز برای پیدا کردن علت مشکل استفاده کنیم.
Core Web Vitals چه ارتباطی با تجربه صفحه دارد؟
Core Web Vitals بخشی از مفهوم گسترده تر Page Experience یا تجربه صفحه است، اما این دو مترادف نیستند.
یک صفحه می تواند از نظر LCP، INP و CLS عملکرد خوبی داشته باشد و همچنان تجربه ضعیفی برای کاربر ایجاد کند.
مثلا ممکن است صفحه با سرعت بالا باز شود اما:
- نمایش مناسبی روی موبایل نداشته باشد.
- تبلیغات مزاحم بخش بزرگی از محتوا را بپوشانند.
- یک Interstitial ناگهانی دسترسی کاربر به محتوا را مختل کند.
- طراحی صفحه طوری باشد که تشخیص محتوای اصلی دشوار شود.
بنابراین رابطه این دو مفهوم را می توان این طور خلاصه کرد:
Core Web Vitals بخشی قابل اندازه گیری از تجربه صفحه است، اما تجربه صفحه فقط Core Web Vitals نیست.
این تمایز برای SEO نیز اهمیت دارد؛ چون سبز کردن سه عدد به تنهایی تضمین نمی کند کاربر تجربه عالی داشته باشد.
آیا Core Web Vitals عامل رتبه بندی Google است؟
پاسخ کوتاه این است:
Core Web Vitals در سیستم های رتبه بندی Google استفاده می شود، اما امتیاز خوب Core Web Vitals تضمین کننده رتبه بالا نیست.
اگر یک صفحه محتوای ضعیف و نامرتبطی داشته باشد اما Core Web Vitals عالی باشد، نباید انتظار داشته باشیم صرفا با سرعت و ثبات صفحه از محتوای بسیار مرتبط و مفید رقبا عبور کند.
در طرف مقابل نیز نباید نتیجه بگیریم Core Web Vitals اهمیتی ندارد.
وقتی چند صفحه بتوانند پاسخ مفیدی به جستجوی کاربر بدهند، کیفیت تجربه صفحه می تواند بخشی از مجموعه عواملی باشد که به موفقیت در Search کمک می کند.
پس بهتر است Core Web Vitals را در کنار سایر اجزای رتبه بندی گوگل ببینیم، نه به عنوان میانبری برای رسیدن به رتبه یک.
آیا باید برای گرفتن امتیاز 100 در PageSpeed Insights تلاش کنیم؟
نه لزوما.
این یکی از رایج ترین اشتباهات در پروژه های بهینه سازی سرعت است.
عدد Performance که در Lighthouse یا بخش Lab Data در PageSpeed Insights می بینید یک امتیاز آزمایشگاهی است. این امتیاز با Core Web Vitals Field Data یکسان نیست.
فرض کنید یک فروشگاه از امتیاز 88 به 100 می رسد، اما برای رسیدن به این عدد تیم توسعه دهنده چند هفته روی بهینه سازی هایی کار می کند که تقریبا هیچ تفاوت قابل مشاهده ای برای کاربران ایجاد نمی کند.
در همان زمان Checkout سایت روی موبایل مشکل دارد یا INP کاربران واقعی ضعیف است.
در چنین شرایطی تمرکز روی عدد 100 تصمیم درستی نیست.
هدف باید بهبود تجربه کاربر و رفع Bottleneckهای واقعی باشد، نه تولید یک Screenshot سبز برای گزارش ماهانه.
Core Web Vitals چگونه اندازه گیری می شود؟
برای تحلیل Core Web Vitals باید دو نوع داده را از هم تفکیک کنیم:
Field Data و Lab Data.
این تفاوت یکی از مهم ترین مفاهیم در تحلیل Performance است؛ زیرا بسیاری از سردرگمی ها زمانی ایجاد می شوند که کاربر یک نتیجه خوب در Lighthouse می بیند اما Search Console همچنان وضعیت Poor نشان می دهد.
Field Data چیست؟
Field Data یا داده میدانی از تجربه کاربران واقعی به دست می آید.
کاربران واقعی با دستگاه های مختلف، سرعت اینترنت متفاوت، CPUهای ضعیف و قوی، مرورگرها و شرایط شبکه متفاوت وارد سایت می شوند.
این داده نشان می دهد سایت شما در دنیای واقعی چگونه عمل کرده است.
Chrome User Experience Report یا CrUX یکی از منابع اصلی داده واقعی کاربران است. گزارش Core Web Vitals در Search Console نیز بر داده CrUX متکی است.
PageSpeed Insights نیز در بخش تجربه کاربران واقعی، داده CrUX را نمایش می دهد و این داده یک بازه زمانی از تجربه کاربران واقعی را منعکس می کند.
مزیت Field Data این است که مشکلات واقعی کاربران را نشان می دهد.
محدودیت آن این است که برای Debug کردن علت دقیق یک مشکل همیشه اطلاعات کافی ارائه نمی کند و سایت یا URL نیز باید داده واقعی کافی داشته باشد.
Lab Data چیست؟
Lab Data در یک محیط کنترل شده و شبیه سازی شده جمع آوری می شود.
Lighthouse صفحه را در شرایط مشخص اجرا می کند و مجموعه ای از معیارها و Diagnostics را گزارش می دهد.
مزیت Lab Data این است که تست را می توان بارها تکرار کرد، تغییرات را قبل و بعد از اصلاح مقایسه کرد و دلایل احتمالی مشکل را پیدا کرد.
اما یک تست آزمایشگاهی نمی تواند دقیقا نماینده تمام کاربران واقعی باشد.
داده واقعی یک گزارش تاریخی از کاربران در دستگاه ها و شبکه های مختلف است، در حالی که Lab Data بر اساس بارگذاری شبیه سازی شده روی یک دستگاه و شرایط شبکه مشخص تولید می شود. در نتیجه اختلاف این دو کاملا طبیعی است.
تفاوت Field Data و Lab Data در یک نگاه
| ویژگی | Field Data | Lab Data |
|---|---|---|
| منبع | کاربران واقعی | محیط شبیه سازی شده |
| نمونه ابزار | CrUX و Search Console | Lighthouse |
| کاربرد اصلی | فهم تجربه واقعی کاربران | تشخیص و Debug |
| شرایط دستگاه | متنوع | کنترل شده |
| شرایط شبکه | واقعی و متنوع | شبیه سازی شده |
| داده تاریخی | بله | معمولا اجرای همان لحظه |
| مناسب برای پیدا کردن علت فنی | محدودتر | بسیار مناسب |
| مناسب برای ارزیابی تجربه واقعی | بسیار مناسب | تقریبی |
بهترین تحلیل زمانی اتفاق می افتد که این دو نوع داده را مقابل هم قرار ندهیم، بلکه از هرکدام برای هدف مناسب استفاده کنیم.
Field Data می گوید آیا کاربران واقعا مشکل دارند. Lab Data کمک می کند بفهمیم احتمالا چرا مشکل دارند.
PageSpeed Insights دقیقا چه چیزی نشان می دهد؟
PageSpeed Insights ابزار مفیدی است چون دو دنیا را در یک صفحه کنار هم قرار می دهد.
در بخش داده واقعی کاربران، از CrUX استفاده می کند.
در بخش تشخیصی آزمایشگاهی، Lighthouse صفحه را تحلیل می کند.
به همین دلیل ممکن است در بالای گزارش ببینید Core Web Vitals Assessment موفق است، اما Performance Score آزمایشگاهی مثلا 72 باشد.
یا برعکس، ممکن است Lighthouse امتیاز 98 نشان دهد اما داده کاربران واقعی همچنان LCP ضعیف داشته باشد.
هیچ تناقض عجیبی وجود ندارد؛ دو بخش در حال پاسخ دادن به دو سوال متفاوت هستند.
- Field Data: کاربران واقعی در هفته های اخیر چه تجربه ای داشته اند؟
- Lab Data: در این اجرای کنترل شده، صفحه چگونه عمل کرد و چه مشکلات فنی قابل تشخیصی دارد؟
چرا Search Console با PageSpeed Insights متفاوت است؟
این سوال زمانی مطرح می شود که یک URL را در PageSpeed Insights تست می کنید و نتیجه خوب است، اما Search Console همچنان گروهی از صفحات را Poor اعلام می کند.
چند دلیل مهم برای این اختلاف وجود دارد.
Search Console از داده واقعی CrUX استفاده می کند و URLهای مشابه را در گروه هایی قرار می دهد. وضعیت گزارش نیز برای Mobile و Desktop جداگانه است.
PageSpeed Insights ممکن است داده همان URL را نشان دهد، اما اگر برای آن URL داده کافی وجود نداشته باشد، ممکن است داده در سطح گسترده تری در دسترس باشد. همچنین Lab Test فقط وضعیت اجرای همان تست را نشان می دهد.
عامل مهم دیگر زمان است.
اگر امروز یک مشکل LCP را رفع کنید، اجرای Lighthouse ممکن است همان لحظه بهتر شود، اما Field Data بلافاصله تمام داده تاریخی کاربران را فراموش نمی کند.
بنابراین بعد از Deploy کردن یک اصلاح نباید انتظار داشته باشید همه گزارش های Field Data همان لحظه سبز شوند.
گزارش Core Web Vitals در Search Console چگونه کار می کند؟
گزارش Core Web Vitals در Search Console برای مشاهده وضعیت کلی سایت بسیار کاربردی است.
این گزارش صفحات را بر اساس داده واقعی کاربران و وضعیت معیارهای LCP، INP و CLS دسته بندی می کند و صفحات مشابه را در URL Groupها قرار می دهد.
یک نکته مهم این است که گزارش Search Console لیست کامل تمام URLهای سایت نیست.
وجود داده کافی اهمیت دارد. اگر یک سایت یا گروه URL ترافیک و داده واقعی کافی نداشته باشد، ممکن است اطلاعات Core Web Vitals برای آن نمایش داده نشود.
به همین دلیل پیام «No data» الزاما به معنی عالی بودن یا خراب بودن وضعیت نیست.
ممکن است فقط داده کافی وجود نداشته باشد.
برای یک سایت بزرگ بهتر است Search Console را نقطه شروع تشخیص بدانیم: ابتدا مشخص کنیم کدام Device و کدام Metric مشکل دارد، سپس گروه URL متاثر را پیدا کنیم و چند نمونه از آن صفحات را با ابزارهای تشخیصی عمیق تر بررسی کنیم.
برای پاس شدن Core Web Vitals چه اتفاقی باید بیفتد؟
در ارزیابی استاندارد Core Web Vitals، هر سه معیار باید در محدوده Good قرار داشته باشند.
یعنی اگر LCP و CLS عالی باشند اما INP ضعیف باشد، نمی توان گفت صفحه از نظر Core Web Vitals وضعیت کاملا خوبی دارد.
این مسئله در عمل مهم است؛ چون گاهی تیم فنی فقط روی Loading Speed تمرکز می کند.
تصاویر فشرده می شوند، CDN راه اندازی می شود و سرور سریع تر پاسخ می دهد، اما رابط کاربری همچنان JavaScript سنگینی دارد و تعاملات روی موبایل کند هستند.
در این حالت LCP ممکن است بهبود زیادی کند، ولی INP همچنان مانع تجربه مناسب شود.
Core Web Vitals عمدا از سه معیار استفاده می کند تا بهینه سازی فقط به یک بعد محدود نشود.
اگر Core Web Vitals ضعیف باشد، از کجا شروع کنیم؟
اولین قدم این نیست که فهرستی از تمام توصیه های PageSpeed Insights را به توسعه دهنده بدهیم.
باید ابتدا مشخص کنیم کدام Metric، برای کدام گروه صفحه و برای کدام نوع دستگاه مشکل دارد.
| چیزی که مشاهده می کنید | اولین سوال تشخیصی | مسیر بررسی |
|---|---|---|
| LCP ضعیف | عنصر LCP چیست و تاخیر در کدام مرحله ایجاد می شود؟ | Server Response، تصویر اصلی، CSS، Resource Priority و Rendering |
| INP ضعیف | کدام تعامل ها کند هستند؟ | Long Task، Main Thread، JavaScript، DOM و Third-party Script |
| CLS ضعیف | کدام عنصر باعث جابه جایی شده است؟ | تصاویر بدون ابعاد، تبلیغات، محتوای Dynamic و فونت |
| Search Console ضعیف ولی Lighthouse خوب | آیا مشکل در کاربران واقعی یا گروه دیگری از صفحات رخ می دهد؟ | Field Data، Device، URL Group و CrUX |
| Lighthouse ضعیف ولی Field Data خوب | آیا مشکل فقط در محیط شبیه سازی شده رخ می دهد؟ | شرایط تست، Regression احتمالی و Diagnostic |
| فقط Mobile ضعیف | آیا سخت افزار و شبکه ضعیف تر مشکل را آشکار می کنند؟ | CPU، JavaScript، حجم منابع و Responsive Assets |
این رویکرد یک مزیت مهم دارد:
به جای ده ها تغییر تصادفی، ابتدا Hypothesis مشخصی درباره علت مشکل می سازیم و بعد تاثیر اصلاح را اندازه گیری می کنیم.
برای بهبود LCP روی چه چیزهایی تمرکز کنیم؟
بهینه سازی کامل LCP موضوع یک مقاله مستقل است، اما در سطح Hub چهار سوال بسیار مهم وجود دارد:
- آیا پاسخ اولیه سرور سریع است؟
- آیا مرورگر خیلی زود عنصر LCP را پیدا می کند؟
- آیا فایل مورد نیاز عنصر LCP سریع دانلود می شود؟
- آیا بعد از دانلود، Render آن بدون تاخیر غیرضروری انجام می شود؟
به عنوان مثال اگر LCP صفحه یک Hero Image باشد و تصویر با JavaScript بعد از چند مرحله ساخته شود، مرورگر ممکن است خیلی دیر دانلود آن را شروع کند.
در مثال دیگر، تصویر از همان ابتدا در HTML وجود دارد ولی حجم آن چند مگابایت است و برای موبایل Resize نشده است.
هر دو صفحه LCP ضعیف دارند، اما راه حل آن ها یکسان نیست.
این همان دلیلی است که Diagnostics از امتیاز خام مهم تر است.
برای بهبود INP روی چه چیزهایی تمرکز کنیم؟
در INP باید لحظه تعامل کاربر را بررسی کنیم.
اگر کاربر روی یک Tab کلیک می کند و تغییر محتوا دیر نمایش داده می شود، باید ببینیم تاخیر قبل از اجرای Handler است، خود Handler طولانی اجرا می شود یا مرورگر برای Render نتیجه زمان زیادی نیاز دارد.
Main Thread شلوغ یکی از متهمان اصلی است.
Taskهای طولانی JavaScript می توانند فرصت رسیدگی سریع به Input کاربر را از مرورگر بگیرند. اندازه بزرگ DOM و کار زیاد هنگام Rendering نیز می تواند پاسخگویی را کند کند.
در تست های آزمایشگاهی، Total Blocking Time یا TBT می تواند یکی از معیارهای تشخیصی مفید برای شناسایی مشکلات مربوط به Blocking باشد، اما TBT جای INP واقعی کاربران نیست.
بنابراین نباید مثلا با کاهش TBT نتیجه بگیریم مشکل INP تمام کاربران قطعا حل شده است. بعد از اصلاح باید Field Data را نیز بررسی کرد.
برای بهبود CLS روی چه چیزهایی تمرکز کنیم؟
CLS معمولا با پیدا کردن عوامل ایجاد Layout Shift شروع می شود.
اگر برای تصویر فضایی از قبل رزرو نشده باشد، مرورگر پس از بارگذاری تصویر مجبور می شود عناصر پایین صفحه را جابه جا کند.
اگر تبلیغ یا Banner بعدا با ارتفاع نامشخص وارد صفحه شود، همین اتفاق ممکن است رخ دهد.
Web Font نیز در بعضی سناریوها می تواند باعث تغییر ابعاد متن و جابه جایی عناصر اطراف آن شود.
بنابراین در تحلیل CLS فقط نباید دنبال «سرعت بیشتر» باشیم.
گاهی راه حل اصلا سریع تر کردن Download نیست؛ بلکه باید از ابتدا فضای مورد نیاز عنصر را رزرو کنیم تا حتی اگر آن عنصر کمی دیر رسید، Layout صفحه تغییر نکند.
آیا سایت های کوچک هم باید Core Web Vitals را بررسی کنند؟
بله.
Core Web Vitals مستقیما درباره تجربه کاربران است و تقریبا هر سایت عمومی می تواند از بررسی آن سود ببرد.
اما میزان سرمایه گذاری باید منطقی باشد.
یک سایت خدماتی کوچک که تمام معیارهای Field Data آن Good هستند نباید فقط برای رساندن Lighthouse Performance از 94 به 100 هفته ها زمان توسعه صرف کند.
در طرف مقابل، اگر کاربران موبایل یک فروشگاه با INP بالاتر از 500 میلی ثانیه یا CLS شدید مواجه هستند، بهبود Core Web Vitals می تواند هم برای تجربه کاربر و هم برای کیفیت فنی سایت ارزش قابل توجهی ایجاد کند.
اصل تصمیم گیری این است:
شدت مشکل و تاثیر آن بر کاربر را مبنا قرار دهید، نه وسواس روی عدد.
آیا Core Web Vitals فقط برای موبایل مهم است؟
خیر.
Core Web Vitals در موبایل و دسکتاپ باید جداگانه بررسی شود.
یک صفحه ممکن است در Desktop کاملا خوب باشد اما در Mobile وضعیت Poor داشته باشد.
این اختلاف دلایل قابل فهمی دارد.
کاربران موبایل ممکن است CPU ضعیف تری داشته باشند، از شبکه کندتری استفاده کنند و صفحه نیز در Layout متفاوتی نمایش داده شود.
همچنین ممکن است سایت در نسخه موبایل اسکریپت، منو یا کامپوننت متفاوتی داشته باشد که تجربه تعامل را تغییر دهد.
بنابراین گزارش Desktop نمی تواند جای گزارش Mobile را بگیرد و برعکس.
چند اشتباه رایج در تحلیل Core Web Vitals
Core Web Vitals همان سرعت سایت است
دقیق نیست.
LCP به Loading مربوط است، اما INP Responsiveness و CLS Visual Stability را اندازه گیری می کنند.
Core Web Vitals تصویری گسترده تر از صرفا «زمان لود صفحه» ارائه می دهد.
هرچه PageSpeed Score بالاتر باشد SEO بهتر است
چنین رابطه مستقیمی وجود ندارد.
Performance Score آزمایشگاهی یک ابزار تشخیصی مفید است، اما رتبه بندی Google بر اساس یک عدد Lighthouse انجام نمی شود.
اگر سایت روی لپ تاپ من سریع است، Core Web Vitals باید خوب باشد
تجربه شما فقط یک Sample است.
Field Data شامل کاربران با شرایط بسیار متنوع است و دقیقا برای همین ساخته شده است.
اگر امروز مشکل را حل کنیم Search Console باید همان لحظه سبز شود
Field Data تاریخی است.
رفع فنی ممکن است بلافاصله در Lab Test دیده شود، اما داده واقعی به مرور با بازدیدهای جدید تغییر می کند.
FID هنوز یکی از Core Web Vitals است
خیر.
INP از 12 مارس 2024 جای FID را گرفته است.
سبز شدن Core Web Vitals یعنی تجربه صفحه عالی است
نه لزوما.
Core Web Vitals سه بخش مهم تجربه را می سنجد، اما تجربه صفحه ابعاد بیشتری دارد.
مثال عملی: فروشگاهی که PageSpeed آن 95 است اما کاربران ناراضی هستند
فرض کنیم یک فروشگاه اینترنتی در Lighthouse امتیاز Performance برابر 95 دارد.
مدیر سایت نتیجه می گیرد که Performance عالی است.
اما در Search Console گزارش Mobile نشان می دهد INP بسیاری از صفحات محصول Poor است.
وقتی داده واقعی بررسی می شود مشخص می شود کاربران بعد از باز شدن صفحه با فیلتر انتخاب مدل، گالری تصاویر و دکمه های خرید تعامل زیادی دارند.
در اجرای اولیه Lighthouse، هیچ کاربری واقعا با تمام این بخش ها تعامل نکرده است. بنابراین Load اولیه بسیار خوب به نظر می رسد.
اما وقتی کاربر واقعی روی گزینه انتخاب مدل کلیک می کند، چند اسکریپت هم زمان اجرا می شوند، قیمت دوباره محاسبه می شود، گالری به روز می شود و ابزار Analytics چند Event پردازش می کند.
Main Thread برای مدتی درگیر می شود و کاربر بازخورد تعامل را دیر می بیند.
اینجا مشکل نه LCP است و نه «سرعت اینترنت».
مشکل Responsiveness است.
تیم فنی به جای فشرده کردن دوباره تصاویر یا نصب افزونه Cache دیگر، باید Interaction کند را Profile کند و JavaScript و Rendering مرتبط با آن را بهینه کند.
این مثال نشان می دهد چرا Core Web Vitals باید به شکل Metric-specific تحلیل شود.
عدد کلی Performance به تنهایی نمی گوید کاربر در تمام مراحل استفاده از صفحه چه تجربه ای دارد.
مثال دوم: سایت خبری با CLS بالا
یک سایت خبری را تصور کنید که عنوان و متن مقاله خیلی سریع نمایش داده می شوند.
LCP عالی است.
INP نیز مشکل خاصی ندارد.
اما بعد از یک ثانیه محل تبلیغ بالای متن با ارتفاع کامل نمایش داده می شود و مقاله به پایین حرکت می کند.
چند لحظه بعد فونت اختصاصی بارگذاری می شود و ارتفاع خطوط تغییر می کند.
در ادامه یک باکس پیشنهاد عضویت نیز به بالای متن اضافه می شود.
از نظر کاربر، خواندن مقاله دائما مختل می شود.
در چنین سایتی شاید کاهش 100 میلی ثانیه از LCP تقریبا هیچ ارزش قابل احساس جدیدی ایجاد نکند؛ در حالی که کاهش CLS می تواند تجربه مطالعه را به شکل محسوسی بهتر کند.
این همان منطق Core Web Vitals است:
ابتدا بفهمید کدام جنبه تجربه خراب است، سپس همان مشکل را حل کنید.
چگونه Core Web Vitals را در یک پروژه واقعی بررسی کنیم؟
برای یک سایت واقعی بهتر است ارزیابی از داده کاربران شروع شود.
Search Console می تواند مشخص کند آیا گروه هایی از URLها در Mobile یا Desktop وضعیت Poor یا Needs Improvement دارند.
بعد از شناسایی Metric مشکل دار، PageSpeed Insights امکان مشاهده Field Data و Diagnostics را فراهم می کند.
برای تحلیل دقیق تر می توان از Chrome DevTools و ابزارهای Performance استفاده کرد تا عنصر LCP، Long Taskها، Interactionهای کند یا Layout Shift Culpritها پیدا شوند.
در سایت های بزرگ تر، داده RUM یا Real User Monitoring اختصاصی نیز می تواند ارزش زیادی داشته باشد.
CrUX یک تصویر Aggregate ارائه می دهد، اما RUM داخلی می تواند داده را بر اساس Template، کشور، Browser، Device، مسیر کاربر و حتی Feature مشخص تقسیم کند.
در چنین شرایطی تیم فنی دیگر فقط نمی داند «INP بد است»، بلکه می تواند بفهمد مثلا:
INP صفحه محصول روی گوشی های ضعیف Android بعد از تعامل با فیلتر رنگ مشکل دارد.
این سطح از تشخیص است که به اصلاح هدفمند منجر می شود.
آیا Core Web Vitals همه چیز را درباره Performance می گوید؟
خیر.
حتی اگر هر سه Core Web Vital سبز باشند، همچنان ممکن است فرصت های مهمی برای بهبود Performance وجود داشته باشد.
مثلا First Contentful Paint ممکن است کند باشد. TTFB ممکن است بالاتر از حد مطلوب باشد. دانلودهای غیرضروری می توانند پهنای باند کاربر را مصرف کنند. مصرف حافظه یا باتری ممکن است زیاد باشد.
از طرف دیگر Core Web Vitals لزوما تمام جنبه های Usability را اندازه گیری نمی کند.
ممکن است فرم شما بسیار سریع و پایدار باشد اما طراحی آن گیج کننده باشد.
ممکن است صفحه از نظر فنی عالی باشد اما متن اصلی خوانایی ضعیفی داشته باشد.
به همین دلیل این سه Metric را باید شاخص های مهم تجربه کاربر دانست، نه کل تعریف تجربه کاربر.
اولویت بهینه سازی Core Web Vitals را چگونه تعیین کنیم؟
اگر سایت چندین مشکل هم زمان دارد، کار را بر اساس تاثیر واقعی اولویت بندی کنید.
صفحات تجاری مهم و Templateهایی که تعداد زیادی URL را تحت تاثیر قرار می دهند معمولا اولویت بیشتری دارند.
همچنین مشکل Poor معمولا باید قبل از Needs Improvement بررسی شود.
اگر اصلاح یک Component مشترک بتواند LCP هزاران صفحه محصول را بهتر کند، تاثیر آن بسیار بیشتر از اصلاح دستی یک Landing Page کم بازدید خواهد بود.
از زاویه کسب و کار نیز مسیرهای مهم اهمیت بیشتری دارند.
مشکل INP روی دکمه خرید یا Checkout ممکن است مهم تر از یک Interaction کند در صفحه ای باشد که تقریبا هیچ کاربری با آن تعامل ندارد.
بنابراین اولویت خوب ترکیبی از این عوامل است:
شدت مشکل + تعداد کاربران متاثر + اهمیت صفحه + هزینه اصلاح
این نگاه جلوی پروژه های Performance بی پایان را می گیرد.
Core Web Vitals و تجربه کاربر؛ عدد را به مسئله واقعی ترجمه کنید
مهم ترین مهارت در تحلیل Core Web Vitals، ترجمه Metric به تجربه واقعی است.
LCP برابر 4.8 ثانیه فقط یک عدد قرمز نیست.
یعنی تعداد قابل توجهی از کاربران مدت زیادی منتظر دیدن محتوای اصلی می مانند.
INP برابر 650 میلی ثانیه فقط یک Threshold ناموفق نیست.
یعنی بعضی تعاملات به اندازه ای دیر پاسخ می دهند که کاربر می تواند تاخیر را کاملا احساس کند.
CLS برابر 0.4 فقط یک امتیاز ضعیف نیست.
یعنی Layout صفحه به شکل قابل توجهی جابه جا می شود و ممکن است مطالعه یا تعامل کاربر مختل شود.
وقتی Metric را به تجربه واقعی ترجمه کنیم، تصمیم فنی بهتر می شود.
در غیر این صورت بهینه سازی Performance خیلی راحت تبدیل به مسابقه ای برای سبز کردن Dashboard می شود.
جمع بندی؛ Core Web Vitals را برای کاربر بهینه کنید، نه برای رنگ سبز ابزار
Core Web Vitals روشی برای تبدیل چند بخش مهم تجربه کاربر به معیارهای قابل اندازه گیری است.
LCP به ما می گوید محتوای اصلی با چه سرعتی ظاهر می شود.
INP نشان می دهد صفحه هنگام تعامل تا چه اندازه پاسخگو است.
CLS مشخص می کند Layout صفحه چقدر پایدار باقی می ماند.
برای وضعیت Good، هدف فعلی LCP حداکثر 2.5 ثانیه، INP حداکثر 200 میلی ثانیه و CLS حداکثر 0.1 در صدک 75 کاربران است.
اما مهم ترین نکته این مقاله خود این اعداد نیستند.
Core Web Vitals زمانی ارزش واقعی پیدا می کند که از آن برای پیدا کردن تجربه ضعیف کاربران استفاده کنیم.
اگر Metric ضعیف است، ابتدا باید مشخص شود مشکل برای کدام Device، کدام گروه صفحات و کدام کاربران رخ می دهد. بعد باید علت فنی همان Metric شناسایی شود و پس از اصلاح، هم Lab Data و هم Field Data دوباره بررسی شوند.
Core Web Vitals را نیز نباید با کل SEO برابر دانست. Google از این معیارها در سیستم های Ranking استفاده می کند، اما صفحه سریع و پایدار بدون محتوای مفید و مرتبط تضمینی برای رتبه بالا ندارد.
بنابراین هدف نهایی این نیست که تمام نمودارها به رنگ سبز دربیایند.
هدف این است که وقتی کاربر وارد صفحه می شود، محتوای اصلی را سریع ببیند، هنگام کلیک و تعامل معطل نشود و در زمان استفاده با جابه جایی آزاردهنده عناصر مواجه نشود.
اگر این سه اتفاق رخ دهد، عددهای خوب Core Web Vitals دیگر فقط یک Score فنی نیستند؛ نشانه یک تجربه واقعی بهتر برای کاربران هستند.
اولین دیدگاه را بنویسید