نویسنده: مای محتوا
راهنمای جامع تحلیل گزارش Core Web Vitals فروشگاه اینترنتی در Google Search Console؛ بررسی معیارهای LCP، INP و CLS، تفاوت داده واقعی کاربران با PageSpeed Insights و Lighthouse، شناسایی مشکلات صفحات محصول و دسته‌بندی، اولویت‌بندی اصلاحات، تحلیل نمونه واقعی‌نما و پایش نتایج در بازه ۲۸روزه. همراه با جدول‌های تخصصی، روش‌های عیب‌یابی و چک‌لیست اجرایی.
فرض کنید فروشگاه اینترنتی شما صدها محصول دارد و از گوگل بازدیدکننده دریافت می‌کند. طراحی سایت مناسب است، تصاویر محصولات کیفیت خوبی دارند و فرایند خرید هم فعال است. اما وقتی وارد Google Search Console می‌شوید، در بخش Core Web Vitals مشاهده می‌کنید تعداد زیادی از صفحات موبایل در وضعیت Poor یا Need improvement قرار گرفته‌اند.
در ادامه یکی از صفحات محصول را با PageSpeed Insights بررسی می‌کنید و می‌بینید امتیاز عملکرد آن مناسب است. حتی ممکن است همان صفحه روی کامپیوتر بسیار سریع باز شود. پس چرا سرچ کنسول همچنان عملکرد بخشی از فروشگاه را ضعیف گزارش می‌کند؟
پاسخ این است که گزارش Core Web Vitals براساس تجربه واقعی کاربران و نحوه عملکرد صفحات در شرایط مختلف تهیه می‌شود؛ درحالی‌که یک تست سرعت، معمولاً شرایط محدود و کنترل‌شده‌ای را بررسی می‌کند.
علاوه بر این، سرعت نمایش صفحه تنها یکی از بخش‌های تجربه کاربری است. ممکن است تصویر محصول سریع بارگذاری شود، اما وقتی مشتری روی دکمه افزودن به سبد خرید کلیک می‌کند، پاسخ رابط کاربری با تأخیر نمایش داده شود. یا ممکن است هنگام بارگذاری تصاویر و بنرها، عناصر صفحه جابه‌جا شوند و کاربر به‌اشتباه روی گزینه دیگری بزند.
اینجاست که سه معیار اصلی Core Web Vitals یعنی LCP، INP و CLS اهمیت پیدا می‌کنند.
در این مقاله بررسی می‌کنیم چگونه گزارش Core Web Vitals را برای صفحات فروشگاهی تحلیل کنیم، هر معیار چه چیزی را اندازه می‌گیرد، چرا صفحات محصول و دسته‌بندی رفتار متفاوتی دارند، چگونه مشکلات را اولویت‌بندی کنیم و برای رفع آن‌ها چه تغییراتی در تصاویر، کدها، سرور و اجزای رابط کاربری لازم است. همچنین تفاوت گزارش سرچ کنسول با PageSpeed Insights، یک مثال تحلیلی، برنامه اجرایی و چک‌لیست کامل را ارائه می‌کنیم.
Core Web Vitals مجموعه‌ای از معیارهای اصلی تجربه کاربری وب است که توسط گوگل معرفی شده‌اند. این معیارها بر سه موضوع مهم تمرکز دارند: سرعت نمایش محتوای اصلی، پاسخ‌گویی صفحه به تعامل کاربر و ثبات بصری عناصر هنگام استفاده.
براساس مستندات رسمی Google Search Central، این معیارها برای ارزیابی تجربه واقعی کاربران در صفحات وب استفاده می‌شوند.
در یک فروشگاه اینترنتی، اهمیت آن‌ها کاملاً قابل درک است. مشتری انتظار دارد تصویر اصلی محصول سریع نمایش داده شود، انتخاب رنگ و اندازه بدون تأخیر انجام شود و دکمه خرید هنگام بارگذاری عناصر دیگر از جای خود حرکت نکند.
بااین‌حال، باید میان تجربه کاربری و رتبه‌بندی گوگل تفاوت قائل شویم. Core Web Vitals با جنبه‌هایی از تجربه صفحه ارتباط دارد که سیستم‌های رتبه‌بندی گوگل به آن‌ها توجه می‌کنند؛ اما کسب امتیاز خوب در این معیارها تضمین‌کننده رتبه بالاتر یا افزایش قطعی فروش نیست.
کیفیت محتوا، ارتباط صفحه با جست‌وجوی کاربر، اعتبار، قیمت محصول، موجودی و سایر عوامل نیز اهمیت دارند.
در ساختار فعلی Core Web Vitals، سه معیار اصلی عبارت‌اند از Largest Contentful Paint، Interaction to Next Paint و Cumulative Layout Shift.
| معیار | مفهوم | واحد | مصداق فروشگاهی |
|---|---|---|---|
| LCP | زمان نمایش بزرگ‌ترین عنصر محتوایی قابل مشاهده در بخش اولیه صفحه | ثانیه | نمایش تصویر اصلی محصول یا بنر دسته‌بندی |
| INP | میزان پاسخ‌گویی صفحه به تعامل‌های کاربر | میلی‌ثانیه | انتخاب رنگ، باز کردن منو یا افزودن به سبد |
| CLS | میزان جابه‌جایی غیرمنتظره عناصر صفحه | امتیاز بدون واحد | حرکت دکمه خرید هنگام بارگذاری عکس یا پیام |
هر سه معیار باید در محدوده مناسب قرار بگیرند تا تجربه کاربری از نظر Core Web Vitals خوب ارزیابی شود.
طبق مستندات web.dev درباره آستانه‌های Core Web Vitals، محدوده‌های زیر برای ارزیابی این سه معیار استفاده می‌شوند:
| معیار | خوب (Good) | نیازمند بهبود | ضعیف (Poor) |
|---|---|---|---|
| LCP | ۲٫۵ ثانیه یا کمتر | بیشتر از ۲٫۵ تا ۴ ثانیه | بیشتر از ۴ ثانیه |
| INP | ۲۰۰ میلی‌ثانیه یا کمتر | بیشتر از ۲۰۰ تا ۵۰۰ میلی‌ثانیه | بیشتر از ۵۰۰ میلی‌ثانیه |
| CLS | ۰٫۱ یا کمتر | بیشتر از ۰٫۱ تا ۰٫۲۵ | بیشتر از ۰٫۲۵ |
برای مثال، اگر مقدار LCP یک گروه از صفحات فروشگاهی ۳٫۲ ثانیه باشد، در محدوده نیازمند بهبود قرار می‌گیرد. اگر مقدار INP همان گروه ۵۸۰ میلی‌ثانیه باشد، وضعیت آن معیار ضعیف است.
نکته مهم: این مقدارها برای تحلیل تجربه کاربران در صدک ۷۵ استفاده می‌شوند؛ نه اینکه هر بار باز شدن یک صفحه دقیقاً باید نتیجه یکسانی داشته باشد.
در آموزش‌های قدیمی سئو ممکن است با معیاری به نام First Input Delay یا FID روبه‌رو شوید.
FID تأخیر اولین تعامل کاربر را اندازه می‌گرفت. اما ممکن بود صفحه در اولین کلیک سریع باشد و در تعامل‌های بعدی عملکرد ضعیفی داشته باشد.
از ۱۲ مارس ۲۰۲۴، معیار INP به‌صورت رسمی جایگزین FID در مجموعه Core Web Vitals شد.
بر اساس اطلاعیه رسمی web.dev، INP عملکرد تعامل‌های مختلف در طول حضور کاربر در صفحه را بررسی می‌کند و برای سنجش پاسخ‌گویی کلی مناسب‌تر است.
برای فروشگاه اینترنتی این تفاوت مهم است؛ زیرا کاربر ممکن است بعد از بارگذاری اولیه، چندین بار رنگ، تعداد، فیلتر یا روش ارسال را تغییر دهد.
نتیجه: اگر هنوز براساس آموزش‌های قدیمی فقط FID را بررسی می‌کنید، برای تحلیل Core Web Vitals فعلی باید INP را نیز در اولویت قرار دهید.
برای مشاهده گزارش، وارد Google Search Console شوید و Property مربوط به فروشگاه را انتخاب کنید.
در راهنمای رسمی Core Web Vitals سرچ کنسول توضیح داده شده که این گزارش صفحات را براساس وضعیت، نوع معیار و گروه URLهای مشابه دسته‌بندی می‌کند.
نام و محل بعضی گزینه‌ها ممکن است با تغییر رابط کاربری سرچ کنسول متفاوت شود. بنابراین بهتر است از عنوان گزارش و نوع داده‌ها برای یافتن بخش مربوط استفاده کنید.
یکی از اشتباهات رایج، بررسی فقط نسخه دسکتاپ سایت است.
ممکن است یک فروشگاه روی کامپیوتر با اینترنت سریع و پردازنده قدرتمند عملکرد خوبی داشته باشد؛ اما کاربران موبایل با اتصال ضعیف‌تر یا دستگاه‌های کم‌قدرت‌تر تجربه متفاوتی داشته باشند.
برای مثال، اسکریپت فیلتر محصولات ممکن است روی لپ‌تاپ بدون تأخیر اجرا شود، اما روی گوشی اقتصادی زمان بیشتری از پردازنده بگیرد.
همچنین تصاویر بزرگ، فونت‌های متعدد و اسکریپت‌های سنگین ممکن است برای کاربران موبایل هزینه بیشتری داشته باشند.
روش بررسی: ابتدا تعداد گروه‌ها و URLهای دارای وضعیت Poor در موبایل را مشخص کنید. سپس همین وضعیت را در دسکتاپ بررسی کنید.
اگر مشکل فقط در موبایل دیده می‌شود، باید تفاوت اندازه صفحه، منابع مصرفی، قدرت پردازش، اتصال شبکه و اجزای نمایش داده‌شده در نسخه موبایل بررسی شوند.
اگر هر دو نسخه مشکل مشابه دارند، احتمال وجود علت مشترک در کد، سرور یا ساختار اصلی صفحه بیشتر است؛ هرچند تشخیص قطعی نیازمند آزمایش است.
در گزارش سرچ کنسول، صفحات یا گروه‌های URL با سه وضعیت اصلی ارزیابی می‌شوند.
Good: معیارهای دارای داده کافی در محدوده مناسب قرار دارند و گروه از نظر گزارش وضعیت خوب دارد.
Need improvement: حداقل یکی از معیارهای مؤثر در محدوده نیازمند بهبود قرار گرفته و معیار ضعیف‌تری وضعیت کلی را به Poor تبدیل نکرده است.
Poor: حداقل یکی از معیارهای مؤثر در محدوده ضعیف قرار دارد.
برای مثال، ممکن است یک گروه از صفحات محصول LCP خوب و CLS خوب داشته باشد، اما INP آن ضعیف باشد. در چنین شرایطی، وضعیت کلی گروه می‌تواند Poor شود.
نکته: رنگ سبز یا قرمز گزارش، میانگین ساده سه معیار نیست. وضعیت گروه براساس ضعیف‌ترین معیار مؤثر آن تعیین می‌شود.
سه معیار Core Web Vitals سه جنبه متفاوت از تجربه کاربر را بررسی می‌کنند. اگر یک جنبه مشکل جدی داشته باشد، خوب بودن دو معیار دیگر لزوماً آن مشکل را جبران نمی‌کند.
فرض کنید یک گروه از صفحات محصول مقادیر زیر را دارد:
| معیار | مقدار فرضی | وضعیت |
|---|---|---|
| LCP | ۲٫۱ ثانیه | Good |
| INP | ۵۸۰ میلی‌ثانیه | Poor |
| CLS | ۰٫۰۶ | Good |
| وضعیت کلی گروه | بر اساس ضعیف‌ترین معیار | Poor |
در این مثال، سریع بودن نمایش صفحه نمی‌تواند تأخیر هنگام کلیک روی دکمه خرید را جبران کند.
بنابراین هنگام تحلیل گزارش، به‌جای تلاش برای بهتر کردن تمام اعداد به‌صورت هم‌زمان، ابتدا مشکل تعیین‌کننده وضعیت گروه را شناسایی کنید.
اگر علت INP ضعیف در یک اسکریپت مشترک سبد خرید باشد، اصلاح همان بخش ممکن است بر تعداد زیادی از صفحات تأثیر بگذارد.
یکی از مهم‌ترین مفاهیم تحلیل این گزارش، صدک ۷۵ است.
به زبان ساده، اگر مقدار LCP در صدک ۷۵ برابر ۳ ثانیه باشد، یعنی در مجموعه اندازه‌گیری موردنظر، تقریباً ۷۵ درصد مشاهده‌ها دارای مقدار LCP برابر یا کمتر از ۳ ثانیه بوده‌اند.
این مقدار میانگین ساده نیست.
فرض کنید ۱۰۰ تجربه بارگذاری صفحه را از سریع‌ترین تا کندترین مرتب کرده‌ایم. صدک ۷۵ به نقطه‌ای در نزدیکی مشاهده هفتادوپنجم اشاره می‌کند.
در نتیجه، اگر تعداد قابل توجهی از کاربران با تجربه کند روبه‌رو شوند، ممکن است حتی با وجود بارگذاری بسیار سریع برای بخشی از کاربران، معیار کلی مناسب نباشد.
گوگل برای ارزیابی Core Web Vitals از صدک ۷۵ داده‌های تجربه واقعی، به تفکیک موبایل و دسکتاپ استفاده می‌کند.
نکته مدیریتی: هدف این نیست که فقط بهترین تجربه کاربران را اندازه بگیرید؛ بلکه باید تجربه بخش بزرگی از کاربران واقعی فروشگاه قابل قبول باشد.
گزارش سرچ کنسول از داده‌های Chrome User Experience Report یا CrUX استفاده می‌کند. این داده‌ها تجربه واقعی کاربران واجد شرایط را در بازه‌های زمانی مشخص خلاصه می‌کنند.
مقادیر گروه‌ها در گزارش Core Web Vitals بر اساس داده‌های ۲۸ روز گذشته ارزیابی می‌شوند.
بنابراین اگر امروز یک مشکل فنی را رفع کنید، طبیعی است که گزارش سرچ کنسول بلافاصله تغییر نکند.
برای مثال، فرض کنید تصاویر محصولات تا هفته گذشته به‌صورت سنگین بارگذاری می‌شدند. امروز اندازه آن‌ها را اصلاح می‌کنید، اما داده‌های گزارش همچنان بخشی از تجربه کاربران روزهای قبل را در بر می‌گیرند.
با ورود داده‌های جدید و خارج شدن داده‌های قدیمی از پنجره ۲۸روزه، وضعیت ممکن است به‌تدریج تغییر کند.
نکته: منظور این نیست که هر اصلاح دقیقاً بعد از ۲۸ روز حتماً تأیید می‌شود. مقدار ترافیک، شرایط کاربران، کیفیت اصلاح و نحوه پردازش داده‌ها بر نتیجه تأثیر دارند.
سرچ کنسول برای تحلیل مشکلات مشترک، URLهای مشابه را در گروه‌هایی قرار می‌دهد.
برای مثال، ممکن است تعداد زیادی صفحه محصول با قالب یکسان داشته باشید. یک مشکل در گالری تصویر یا اسکریپت انتخاب تنوع می‌تواند روی تمام این صفحات اثر بگذارد.
به همین دلیل، سرچ کنسول ممکن است URLهای مشابه را در یک گروه عملکردی نمایش دهد.
نکته مهم: یک URL که در جدول مشاهده می‌کنید لزوماً تنها صفحه دارای مشکل نیست. ممکن است آن آدرس نماینده گروهی از صفحات باشد.
در گزارش رسمی، گروه‌بندی صفحات بر اساس شباهت URL و تجربه اندازه‌گیری‌شده انجام می‌شود. این گروه‌ها لزوماً دقیقاً برابر دسته‌های مدیریتی یا قالب‌های داخلی فروشگاه‌ساز شما نیستند.
برای تشخیص علت مشترک، چند URL از همان گروه را بررسی کنید و ببینید آیا از یک قالب، اسکریپت یا ساختار تصویر مشترک استفاده می‌کنند.
خیر. گزارش Core Web Vitals یک فهرست کامل از تمام صفحات سایت و مشکلات احتمالی آن‌ها نیست.
طبق راهنمای رسمی Search Console، فقط URLهای ایندکس‌شده‌ای که شرایط ورود به این گزارش را دارند می‌توانند در آن ظاهر شوند. همچنین برای نمایش یک گروه، داده کافی درباره معیارهای لازم باید وجود داشته باشد.
بنابراین اگر فروشگاه ۲۰۰۰ محصول دارد اما گزارش فقط برای بخشی از آن‌ها داده نشان می‌دهد، نباید نتیجه گرفت سایر صفحات حتماً سریع هستند.
ممکن است بعضی محصولات بازدید کافی از کاربران واجد شرایط نداشته باشند یا به دلایل دیگر در گزارش حاضر نباشند.
از طرف دیگر، وقتی گزارش اعلام می‌کند چند صد URL وضعیت Poor دارند، نباید بدون بررسی فرض کنید هر کدام دارای علت مستقل است.
ممکن است یک مشکل مشترک در قالب محصول بر بسیاری از آن‌ها اثر گذاشته باشد.
نتیجه: تعداد URLهای گزارش‌شده برای اولویت‌بندی مفید است، اما جایگزین بررسی ساختار کلی سایت و آزمایش صفحات کم‌بازدید نمی‌شود.
گاهی مدیر فروشگاه وارد بخش Core Web Vitals می‌شود و هیچ داده‌ای مشاهده نمی‌کند.
این وضعیت ممکن است به جدید بودن Property یا کافی نبودن داده‌های قابل گزارش در مجموعه CrUX مربوط باشد.
به همین دلیل، نبود داده به معنی خوب بودن یا بد بودن عملکرد سایت نیست.
راهکار: از ابزارهایی مانند PageSpeed Insights و Lighthouse برای بررسی آزمایشگاهی صفحات نمونه استفاده کنید.
اگر به داده‌های دقیق‌تری از کاربران خود نیاز دارید، می‌توانید با رعایت الزامات حریم خصوصی و امکانات فنی سایت، سیستم Real User Monitoring یا RUM راه‌اندازی کنید.
البته داده‌های RUM اختصاصی و CrUX ممکن است به دلیل تفاوت جمعیت کاربران و روش جمع‌آوری دقیقاً یکسان نباشند.
این دو ابزار مکمل یکدیگر هستند، اما عملکرد یکسانی ندارند.
گزارش سرچ کنسول برای مشاهده وضعیت کلی و گروه‌های URL دارای مشکل مناسب است.
در مقابل، PageSpeed Insights امکان بررسی آدرس مشخص و مشاهده داده‌های واقعی کاربران در صورت کافی بودن داده، همراه با تحلیل آزمایشگاهی Lighthouse را فراهم می‌کند.
| ویژگی | Search Console | PageSpeed Insights |
|---|---|---|
| هدف اصلی | پایش مشکلات عملکردی مجموعه صفحات | تحلیل یک URL و ارائه پیشنهاد اصلاح |
| داده واقعی کاربران | بله، از CrUX | بله، در صورت دسترسی به داده کافی |
| تست آزمایشگاهی | خیر، در خود گزارش | بله، با Lighthouse |
| گروه‌بندی URL | بله | عمدتاً تمرکز بر URL یا Origin |
| تحلیل منابع سنگین | محدود | جزئیات و پیشنهادهای آزمایشگاهی |
| بررسی موبایل و دسکتاپ | جداگانه | جداگانه |
طبق مستندات PageSpeed Insights، این ابزار دو نوع داده Field و Lab را ارائه می‌کند.
نکته: مقدارهای یک URL در PageSpeed Insights ممکن است با مقدارهای گروه آن در سرچ کنسول متفاوت باشند؛ زیرا مجموعه داده و سطح تجمیع یکسان نیستند.
Field Data داده‌ای است که از تجربه واقعی کاربران به دست می‌آید. این داده می‌تواند تحت تأثیر دستگاه، شبکه، موقعیت جغرافیایی و نحوه استفاده واقعی از سایت باشد.
Lab Data نتیجه آزمایش در شرایط کنترل‌شده یا شبیه‌سازی‌شده است. Lighthouse از این نوع داده برای تشخیص مشکلات احتمالی و ارائه پیشنهاد استفاده می‌کند.
برای مثال، ممکن است یک صفحه در تست آزمایشگاهی امتیاز عملکرد ۹۵ بگیرد، اما LCP کاربران واقعی آن همچنان ۳٫۵ ثانیه باشد.
این اختلاف لزوماً به معنی اشتباه بودن یکی از ابزارها نیست. شرایط تست و جامعه اندازه‌گیری متفاوت هستند.
قاعده تحلیلی: برای تشخیص وضعیت تجربه کاربران، داده واقعی را مبنا قرار دهید. برای پیدا کردن علت فنی و آزمایش تغییرات، از Lighthouse و ابزارهای توسعه‌دهنده استفاده کنید.
اگر داده واقعی مربوط به URL خاص موجود نیست، نباید با استناد به امتیاز آزمایشگاهی اعلام کنید آن URL حتماً Core Web Vitals خوبی دارد.
این سؤال از رایج‌ترین مشکلات هنگام بررسی سرعت فروشگاه اینترنتی است.
فرض کنید شما یک صفحه محصول را با PageSpeed Insights تست می‌کنید و امتیاز Performance برابر ۹۲ دریافت می‌کنید. بااین‌حال، گزارش موبایل سرچ کنسول نشان می‌دهد گروهی که این محصول در آن قرار دارد وضعیت Poor دارد.
علت‌های احتمالی عبارت‌اند از تفاوت شرایط کاربران واقعی با آزمایشگاه، کند بودن بعضی دستگاه‌ها، بارگذاری اسکریپت‌های شخص ثالث، رفتار کند هنگام تعامل با صفحه و باقی ماندن داده‌های قبل از اصلاح در گزارش ۲۸روزه.
همچنین امتیاز Performance آزمایشگاهی، همان ارزیابی Core Web Vitals نیست.
برای مثال، Lighthouse ممکن است هنگام بارگذاری اولیه عملکرد مناسبی ثبت کند، اما تعامل طولانی و واقعی مشتری با فیلترهای محصولات در همان تست شبیه‌سازی نشده باشد.
راهکار: ابتدا مشخص کنید مشکل از کدام معیار است. سپس تستی انجام دهید که تا حد امکان رفتار واقعی کاربران در همان صفحه را بازسازی کند.
Largest Contentful Paint یا LCP، زمان نمایش بزرگ‌ترین عنصر محتوایی واجد شرایط در محدوده قابل مشاهده اولیه صفحه را اندازه می‌گیرد.
این عنصر ممکن است یک تصویر، پوستر ویدئو یا بلوک بزرگ متن باشد.
در صفحه محصول فروشگاهی، تصویر اصلی کالا معمولاً یکی از نامزدهای مهم LCP است.
در صفحه دسته‌بندی، ممکن است بنر بالای صفحه یا بخش دیگری از محتوای اصلی این نقش را داشته باشد.
هدف توصیه‌شده این است که مقدار LCP در صدک ۷۵ برابر ۲٫۵ ثانیه یا کمتر باشد.
اما LCP به معنی زمان بارگذاری کامل تمام فایل‌های صفحه نیست. ممکن است صفحه هنوز تصاویر پایین‌تر را بارگذاری کند، درحالی‌که عنصر اصلی اولیه قبلاً نمایش داده شده است.
نکته: برای بهینه‌سازی صحیح، باید عنصر واقعی LCP را شناسایی کنید. بهینه کردن تصویری که در پایین صفحه قرار دارد، الزاماً تأثیر مستقیمی بر LCP نخواهد داشت.
در صفحه محصول، مشکلات متداول می‌توانند شامل تصویر اصلی بسیار بزرگ، دریافت دیرهنگام URL تصویر، تأخیر پاسخ سرور، فایل‌های CSS و JavaScript مسدودکننده رندر و اجرای اسکریپت‌های سنگین باشند.
برای مثال، اگر تصویر اصلی محصول فقط بعد از اجرای کامل جاوااسکریپت در HTML قرار بگیرد، مرورگر ممکن است نتواند دانلود آن را زود آغاز کند.
همچنین اگر تصویر اصلی به‌اشتباه با Lazy Loading بارگذاری شود، ممکن است شروع دانلود آن به تأخیر بیفتد.
براساس راهنمای رسمی بهینه‌سازی LCP، بهتر است منبع عنصر LCP زود قابل شناسایی باشد و بارگذاری آن بدون تأخیر غیرضروری انجام شود.
اشتباه مهم: قرار دادن loading='lazy' روی تصویر اصلی بالای صفحه، بدون بررسی نقش آن در LCP.
Lazy Loading برای تصاویر پایین صفحه می‌تواند مفید باشد، اما برای تصویر اصلی که باید بلافاصله دیده شود معمولاً انتخاب مناسبی نیست.
ابتدا در PageSpeed Insights یا Chrome DevTools مشخص کنید کدام عنصر به‌عنوان LCP شناسایی می‌شود.
اگر این عنصر تصویر اصلی محصول است، چند موضوع باید بررسی شوند.
برای نمونه، اگر تصویر اصلی واقعاً عنصر LCP است، توسعه‌دهنده می‌تواند استفاده از fetchpriority='high' را روی همان تصویر بررسی کند.
اما بالا بردن اولویت تمام تصاویر صفحه مناسب نیست؛ زیرا منابع برای دریافت زودتر با یکدیگر رقابت می‌کنند.
همچنین نباید تصاویر محصولات را فقط برای کاهش حجم، آن‌قدر فشرده کرد که مشتری نتواند رنگ، جنس یا جزئیات آن‌ها را ببیند.
برای تحلیل فنی دقیق‌تر، می‌توان زمان LCP را به چهار بخش تقسیم کرد.
| بخش | معنا | نمونه علت تأخیر |
|---|---|---|
| TTFB | زمان تا دریافت اولین بایت HTML | سرور کند، پردازش سنگین یا ریدایرکت |
| Resource load delay | تأخیر تا شروع دریافت منبع LCP | کشف دیرهنگام تصویر توسط JavaScript |
| Resource load duration | مدت دریافت منبع | تصویر بزرگ یا شبکه کند |
| Element render delay | تأخیر تا نمایش عنصر پس از آماده شدن منبع | CSS یا اسکریپت مسدودکننده رندر |
برای مثال، فرض کنید LCP یک صفحه ۴ ثانیه است و پس از بررسی مشخص می‌شود ۱٫۲ ثانیه مربوط به پاسخ اولیه، یک ثانیه تأخیر شروع تصویر، یک ثانیه دریافت تصویر و ۰٫۸ ثانیه تأخیر نمایش آن است.
این اعداد صرفاً آموزشی هستند.
در چنین وضعیتی، فقط کاهش حجم تصویر ممکن است کافی نباشد؛ زیرا تأخیر در کشف منبع و نمایش نهایی نیز بخش قابل توجهی از زمان را تشکیل می‌دهند.
روش درست: ابتدا بزرگ‌ترین بخش قابل اصلاح را شناسایی کنید و سپس نتیجه تغییر را دوباره اندازه‌گیری کنید.
بله. اگر سرور دیر پاسخ دهد، بارگذاری محتوای اصلی نیز دیرتر آغاز می‌شود.
معیار Time to First Byte یا TTFB یکی از معیارهای تشخیصی مفید برای تحلیل عملکرد سرور و مسیر شبکه است؛ اما خودش جزو سه معیار اصلی Core Web Vitals نیست.
طبق راهنمای web.dev درباره TTFB، مقدار حدود ۰٫۸ ثانیه یا کمتر به‌عنوان هدف راهنمای مناسب معرفی شده است؛ البته اهمیت مقدار نهایی باید با معماری سایت و اثر آن بر معیارهای اصلی سنجیده شود.
در فروشگاه اینترنتی، کندی TTFB ممکن است به پردازش درخواست، پایگاه داده، تعداد کوئری‌ها، وضعیت کش، فاصله سرور تا کاربران یا زنجیره ریدایرکت مربوط باشد.
نکته: فعال کردن کش عمومی برای تمام صفحات، بدون توجه به اطلاعات اختصاصی کاربران، می‌تواند مشکلات امنیتی و عملیاتی ایجاد کند.
برای مثال، سبد خرید و قیمت اختصاصی مشتری نباید به‌اشتباه از کش عمومی کاربر دیگری نمایش داده شوند.
بنابراین بهینه‌سازی کش باید میان صفحات عمومی و محتوای شخصی‌سازی‌شده تفاوت بگذارد.
Interaction to Next Paint یا INP میزان پاسخ‌گویی صفحه به تعامل‌های کاربر مانند کلیک، لمس و ورودی صفحه‌کلید را اندازه می‌گیرد.
این معیار فقط زمان اجرای یک تابع JavaScript نیست؛ بلکه تأخیر پیش از پردازش تعامل، مدت اجرای کد و زمان لازم تا نمایش نتیجه بصری تعامل را در نظر می‌گیرد.
برای مثال، وقتی مشتری روی دکمه افزودن به سبد خرید کلیک می‌کند، انتظار دارد صفحه به‌سرعت یک پاسخ بصری مناسب ارائه کند.
اگر مرورگر برای اجرای اسکریپت‌های دیگر مشغول باشد یا به‌روزرسانی سبد خرید محاسبات سنگینی ایجاد کند، ممکن است واکنش قابل مشاهده با تأخیر همراه شود.
هدف مناسب: INP در صدک ۷۵ باید ۲۰۰ میلی‌ثانیه یا کمتر باشد.
براساس راهنمای رسمی INP، این معیار تعامل‌های مختلف در طول حضور کاربر در صفحه را بررسی می‌کند و برخلاف FID فقط به اولین تعامل محدود نیست.
صفحات فروشگاهی معمولاً تعامل‌های بیشتری نسبت به صفحات اطلاع‌رسانی ساده دارند.
مشتری ممکن است رنگ محصول را عوض کند، سایز انتخاب کند، تعداد را افزایش دهد، محصول را مقایسه کند، کد تخفیف وارد کند یا فیلترها را فعال کند.
هر یک از این تعامل‌ها ممکن است به اجرای کد، تغییر DOM یا به‌روزرسانی عناصر صفحه نیاز داشته باشد.
اگر پاسخ‌گویی ضعیف باشد، کاربر ممکن است تصور کند دکمه کار نکرده و دوباره روی آن بزند.
این وضعیت می‌تواند به تجربه نامناسب، درخواست‌های تکراری یا سردرگمی در وضعیت سبد خرید منجر شود؛ هرچند وقوع این پیامدها باید در فرایند واقعی فروشگاه بررسی شود.
اولویت عملی: در فروشگاه‌هایی با INP ضعیف، تعامل‌های اصلی مانند افزودن به سبد، انتخاب تنوع، فیلتر محصولات و باز کردن منوی موبایل را آزمایش کنید.
در بسیاری از موارد، اجرای طولانی JavaScript و اشغال شدن Main Thread مرورگر می‌تواند باعث افزایش تأخیر تعامل‌ها شود.
برای مثال، ممکن است با انتخاب یک فیلتر، کد فروشگاه تمام محصولات را دوباره پردازش و تعداد زیادی عنصر HTML را بازسازی کند.
یا ممکن است چند اسکریپت تبلیغاتی و تحلیلی هم‌زمان با تعامل کاربر اجرا شوند.
علت‌های احتمالی دیگر شامل DOM بسیار بزرگ، محاسبات سنگین، تغییرهای مکرر چیدمان، Event Handlerهای پیچیده و رندر بیش از حد عناصر هستند.
براساس راهنمای بهینه‌سازی INP، تأخیر تعامل را می‌توان به سه قسمت اصلی تقسیم کرد: Input Delay، Processing Duration و Presentation Delay.
نکته: کندی پاسخ API همیشه معادل INP ضعیف نیست. INP فاصله تعامل تا نمایش فریم پاسخ بصری را می‌سنجد؛ یک درخواست شبکه طولانی ممکن است با بازخورد فوری به کاربر همراه باشد یا نباشد. بنابراین باید رفتار واقعی رابط کاربری را بررسی کرد.
فرض کنید پس از کلیک روی دکمه خرید، صفحه برای لحظه‌ای متوقف می‌شود و سپس تعداد سبد تغییر می‌کند.
برای بررسی، می‌توانید از بخش Performance در Chrome DevTools استفاده کنید و هنگام ثبت یک تعامل واقعی، فعالیت مرورگر را ضبط کنید.
سپس بررسی کنید چه کارهایی هنگام کلیک اجرا شده‌اند، کدام Taskها زمان زیادی گرفته‌اند و چه زمانی نتیجه قابل مشاهده نمایش داده شده است.
ممکن است مشکل از پردازش تکراری قیمت‌ها، اجرای چند Event Listener، بارگذاری سنگین اسکریپت یا ساخت دوباره بخش بزرگی از صفحه باشد.
راهکارهای قابل بررسی: کاهش پردازش غیرضروری، تقسیم کارهای طولانی، جلوگیری از رندر اضافی، سبک‌سازی اسکریپت‌های شخص ثالث و ارائه بازخورد بصری سریع مطابق وضعیت واقعی درخواست.
اگر ارسال درخواست خرید با تأخیر مواجه است، می‌توان وضعیت در حال پردازش را به‌شکل روشن نمایش داد. اما نباید پیش از تأیید معتبر سرور، به مشتری اعلام کرد سفارش قطعی ثبت شده است.
در صفحات دسته‌بندی، کاربر ممکن است چند فیلتر را پشت سر هم فعال کند.
برای مثال، ابتدا رنگ مشکی، سپس محدوده قیمت و بعد برند مشخصی را انتخاب می‌کند.
اگر با هر تغییر، تمام کارت‌های محصولات، تصاویر و بخش‌های صفحه بدون نیاز دوباره ساخته شوند، پردازش ممکن است سنگین شود.
در فروشگاه‌هایی با تعداد زیاد محصول، بهینه نبودن کد فیلتر یا مدیریت وضعیت رابط کاربری می‌تواند تأخیر ایجاد کند.
راهکار: بررسی کنید آیا پردازش در مرورگر بیش از اندازه انجام می‌شود، آیا فقط عناصر تغییرکرده قابل به‌روزرسانی هستند و آیا درخواست‌های غیرضروری تکرار می‌شوند.
برای فهرست‌های بسیار بزرگ، ممکن است نیاز به صفحه‌بندی، بارگذاری مرحله‌ای یا روش مناسب‌تری برای مدیریت عناصر DOM وجود داشته باشد.
البته این تغییرها باید با قابلیت دسترسی، عملکرد جست‌وجو، سئو و تجربه کاربران هماهنگ باشند.
Cumulative Layout Shift یا CLS، میزان جابه‌جایی غیرمنتظره عناصر قابل مشاهده صفحه را اندازه می‌گیرد.
فرض کنید مشتری قصد دارد روی دکمه افزودن به سبد خرید کلیک کند. درست در همان لحظه، یک بنر تبلیغاتی بالای صفحه بارگذاری می‌شود و دکمه به سمت پایین حرکت می‌کند.
ممکن است کاربر به‌اشتباه روی عنصر دیگری کلیک کند.
این نوع تغییر ناگهانی چیدمان می‌تواند باعث تجربه نامناسب شود.
هدف مناسب: CLS باید در صدک ۷۵ برابر ۰٫۱ یا کمتر باشد.
CLS برخلاف LCP و INP واحد ثانیه یا میلی‌ثانیه ندارد و با امتیاز بدون واحد بیان می‌شود.
همچنین هر تغییر چیدمانی لزوماً یک جابه‌جایی نامطلوب محسوب نمی‌شود. در محاسبه CLS، شرایط وقوع تغییر و ارتباط آن با تعامل کاربر اهمیت دارد.
در صفحات فروشگاهی، تصاویر بدون ابعاد مشخص از علت‌های متداول جابه‌جایی چیدمان هستند.
فرض کنید مرورگر هنگام نمایش اولیه صفحه نمی‌داند تصویر محصول چه ارتفاعی خواهد داشت. پس از دریافت فایل تصویر، فضای تازه‌ای به آن اختصاص می‌دهد و عناصر پایین‌تر جابه‌جا می‌شوند.
عوامل دیگر می‌توانند شامل بنرهای دیرهنگام، فونت‌هایی با تفاوت ابعادی، نوار اطلاع‌رسانی، ویجت پشتیبانی، پیام موجودی و محتوای پویا باشند.
براساس راهنمای رسمی بهینه‌سازی CLS، تعیین اندازه تصاویر و رزرو فضای عناصر پویا از راهکارهای مهم کاهش جابه‌جایی غیرمنتظره هستند.
راهکار: پیش از بارگذاری کامل محتوا، فضای لازم برای تصاویر، ویدئوها و اجزای متغیر را تا حد امکان مشخص کنید.
بهتر است تصاویر دارای ابعاد مشخص باشند تا مرورگر بتواند نسبت طول و عرض آن‌ها را پیش از دریافت کامل فایل محاسبه کند.
برای مثال، توسعه‌دهنده می‌تواند برای تصویری با ابعاد واقعی ۸۰۰ در ۸۰۰ پیکسل، ویژگی‌های زیر را در HTML قرار دهد:
<img src='/media/product.webp' alt='تصویر محصول' width='800' height='800'>سپس در CSS می‌توان نمایش واکنش‌گرا را به شکلی تنظیم کرد که تصویر از عرض فضای موجود فراتر نرود و نسبت ابعاد آن حفظ شود.
در کارت‌های محصولات، استفاده از محفظه تصویر با نسبت مشخص نیز می‌تواند به ثبات چیدمان کمک کند.
اگر تصاویر محصولات دارای نسبت‌های متفاوت هستند، باید سیاست نمایش آن‌ها روشن باشد. ممکن است استفاده از محفظه ثابت و روش مناسب برش یا نمایش کامل تصویر ضروری باشد.
نکته: تنظیم ابعاد تصویر باید با ساختار واقعی صفحه سازگار باشد و نباید باعث کشیدگی یا تغییر نامناسب تصویر کالا شود.
گاهی مشکل CLS از خود محصول نیست؛ بلکه از اجزای مشترک سایت ایجاد می‌شود.
برای مثال، نوار تخفیف بالای صفحه ممکن است پس از چند ثانیه به ساختار صفحه اضافه شود و بخش اصلی محتوا را به پایین ببرد.
یا بعد از بارگذاری فونت فارسی، عرض متن‌ها تغییر کند و عنوان محصول چند خطی شود.
همچنین نمایش ناگهانی پیام ارسال رایگان یا موجود شدن کالا می‌تواند جای عناصر دیگر را تغییر دهد.
راهکار: برای اجزایی که بعداً بارگذاری می‌شوند، فضای مناسب رزرو کنید. درباره فونت‌ها نیز روش بارگذاری و تفاوت ابعاد فونت جایگزین را بررسی کنید.
اگر پیام شناور قرار است نمایش داده شود، می‌توان در صورت مناسب بودن طراحی، آن را به‌صورت لایه مستقل نمایش داد تا محتوای اصلی جابه‌جا نشود.
این تصمیم باید با قابلیت استفاده در موبایل و دسترسی به دکمه‌های اصلی خرید هماهنگ باشد.
اگرچه تمام صفحات فروشگاه از یک زیرساخت مشترک استفاده می‌کنند، الگوی محتوای آن‌ها متفاوت است.
| نوع صفحه | مشکل احتمالی LCP | مشکل احتمالی INP | مشکل احتمالی CLS |
|---|---|---|---|
| صفحه اصلی | بنر یا اسلایدر بزرگ | اسکریپت‌های اسلایدر و منو | بنرها و بلوک‌های پویا |
| صفحه محصول | تصویر اصلی سنگین | تنوع محصول و افزودن به سبد | گالری، پیام موجودی و قیمت پویا |
| دسته‌بندی | بنر یا کارت‌های اولیه | فیلتر، مرتب‌سازی و جست‌وجو | تصاویر کارت‌ها و تغییر فهرست |
| سبد خرید | محتوای اولیه یا اسکریپت‌های ضروری | تغییر تعداد و حذف کالا | پیام‌های تخفیف و هزینه حمل |
| تسویه‌حساب | بارگذاری فرم و اجزای لازم | انتخاب ارسال و اعتبارسنجی فرم | خطاها و فیلدهای شرطی |
| بلاگ | تصویر شاخص یا تیتر بزرگ | منو و ویجت‌ها | تصاویر و محتوای جاسازی‌شده |
این جدول علت‌های احتمالی را نشان می‌دهد و به معنی آن نیست که تمام صفحات هر نوع دقیقاً این مشکلات را دارند.
پیشنهاد: ابتدا مشخص کنید مشکل مربوط به یک قالب مشترک است یا فقط چند محصول خاص. سپس به‌جای تغییر پراکنده صفحات، علت اصلی را برطرف کنید.
اگر در گزارش سرچ کنسول چند مشکل وجود دارد، بهتر است ابتدا موارد Poor را بررسی کنید.
راهنمای رسمی سرچ کنسول نیز پیشنهاد می‌کند ابتدا مشکلات ضعیف و سپس موارد نیازمند بهبود در اولویت قرار گیرند.
اما داخل هر گروه باید اهمیت تجاری و گستره تأثیر مشکل نیز بررسی شود.
برای مثال، یک مشکل مشترک در قالب صفحات محصول که صدها URL را درگیر کرده ممکن است از اصلاح یک صفحه کم‌بازدید اهمیت بیشتری داشته باشد.
همچنین اگر صفحه اصلی یا دسته‌بندی پرفروش مشکل جدی دارد، ممکن است به دلیل اهمیت آن در مسیر خرید اولویت بالایی داشته باشد.
اولویت پیشنهادی: شدت مشکل، تعداد URLهای درگیر، اهمیت صفحه برای کسب‌وکار و امکان اصلاح علت مشترک را هم‌زمان بررسی کنید.
فرض کنید در گزارش موبایل یک فروشگاه اینترنتی، سه گروه URL با داده کافی نمایش داده شده‌اند.
اعداد جدول کاملاً فرضی هستند و برای آموزش تحلیل استفاده می‌شوند.
| گروه | LCP | INP | CLS | وضعیت کلی |
|---|---|---|---|---|
| صفحات محصول | ۴٫۶ ثانیه | ۱۸۰ میلی‌ثانیه | ۰٫۰۷ | Poor |
| صفحات دسته‌بندی | ۲٫۸ ثانیه | ۵۵۰ میلی‌ثانیه | ۰٫۰۸ | Poor |
| صفحات محتوایی | ۲٫۲ ثانیه | ۱۵۰ میلی‌ثانیه | ۰٫۱۷ | Need improvement |
در گروه صفحات محصول، مشکل اصلی LCP است. بنابراین بهتر است ابتدا تصویر اصلی، پاسخ سرور و زمان بارگذاری محتوای اولیه بررسی شوند.
در گروه دسته‌بندی، مشکل اصلی INP است. در این حالت ممکن است بررسی اسکریپت فیلترها و رفتار تعامل با فهرست محصولات اهمیت بیشتری داشته باشد.
در گروه صفحات محتوایی، CLS به بهبود نیاز دارد. برای این گروه، می‌توان تصاویر بدون ابعاد، بنرهای دیرهنگام و فونت‌ها را بررسی کرد.
نتیجه مهم: هر سه گروه به بهینه‌سازی نیاز دارند، اما راهکار یکسانی برای آن‌ها مناسب نیست.
بهینه‌سازی تصاویر معمولاً می‌تواند در کاهش حجم منابع و بهبود تجربه بارگذاری مفید باشد، اما نباید بدون بررسی فرض کرد تمام مشکلات Core Web Vitals از حجم تصاویر هستند.
اگر LCP ضعیف است و تصویر اصلی عنصر تعیین‌کننده باشد، بهینه‌سازی آن می‌تواند اولویت داشته باشد.
اما اگر INP به دلیل اجرای سنگین JavaScript ضعیف شده، کاهش حجم تصویر به‌تنهایی مشکل تعامل را برطرف نمی‌کند.
همچنین اگر CLS مربوط به نداشتن ابعاد مشخص تصویر است، فقط فشرده‌سازی فایل مشکل جابه‌جایی را حل نخواهد کرد.
روش اصولی: ابتدا علت مشکل را با ابزار مناسب شناسایی کنید. سپس تغییر مرتبط را اعمال و نتیجه را اندازه‌گیری کنید.
برای فروشگاه‌هایی با تصاویر زیاد، استفاده از اندازه‌های متفاوت متناسب با موبایل و دسکتاپ، فرمت مناسب، کش و بارگذاری مرحله‌ای تصاویر خارج از محدوده اولیه می‌تواند مفید باشد.
خیر. CDN می‌تواند در بعضی شرایط زمان تحویل فایل‌ها و فاصله شبکه را کاهش دهد، اما تمام مشکلات تجربه کاربری به سرعت دانلود منابع مربوط نیستند.
اگر مشکل از اجرای کد سنگین در مرورگر است، CDN لزوماً INP را اصلاح نمی‌کند.
همچنین اگر ارتفاع تصاویر مشخص نباشد، صرف استفاده از CDN باعث حذف جابه‌جایی چیدمان نخواهد شد.
در بعضی فروشگاه‌ها، پیکربندی اشتباه کش یا CDN ممکن است باعث نمایش قیمت یا موجودی قدیمی شود.
راهکار: برای استفاده از CDN، نوع منابع، سیاست کش، محل کاربران، زمان پاسخ سرور و نیاز به اطلاعات به‌روز را بررسی کنید.
CDN باید بخشی از برنامه بهینه‌سازی باشد، نه جایگزین تحلیل دقیق LCP، INP و CLS.
بسیاری از فروشگاه‌ها از ابزارهای تحلیل، چت آنلاین، نمایش اعلان، بازاریابی و سایر سرویس‌های جانبی استفاده می‌کنند.
هر ابزار ممکن است فایل‌های JavaScript، CSS یا درخواست‌های شبکه جدیدی به صفحه اضافه کند.
اگر چند ابزار به‌صورت هم‌زمان پردازش سنگینی انجام دهند، ممکن است پاسخ‌گویی صفحه یا زمان نمایش محتوای اصلی تحت تأثیر قرار گیرد.
همچنین بعضی ویجت‌ها می‌توانند بعد از بارگذاری صفحه فضای جدیدی اشغال کنند و باعث جابه‌جایی عناصر شوند.
پیشنهاد: فهرست ابزارهای شخص ثالث را تهیه کنید. سپس اثر هر ابزار را در شرایط آزمایشی و بدون ایجاد اختلال برای کاربران بررسی کنید.
هدف لزوماً حذف تمام ابزارها نیست؛ بلکه باید ابزارهای ضروری حفظ شوند و اجرای آن‌ها تا حد امکان بهینه شود.
برای مثال، بارگذاری دیرتر یک ویجت غیرضروری ممکن است مفید باشد، اما نباید اجزای ضروری پرداخت یا امنیت را بدون بررسی جابه‌جا یا غیرفعال کرد.
برای عیب‌یابی فنی، ابزارهای توسعه‌دهنده مرورگر Chrome امکانات مفیدی ارائه می‌کنند.
در بخش Performance می‌توان فعالیت مرورگر را هنگام بارگذاری و تعامل با صفحه ثبت کرد.
برای مثال، در یک صفحه محصول می‌توانید مراحل زیر را اجرا کنید:
برای تحلیل INP بهتر است رفتار واقعی مانند بازکردن فیلتر یا افزودن به سبد را در ضبط عملکرد انجام دهید.
برای CLS نیز می‌توانید محل تغییرهای چیدمان و عناصر جابه‌جاشده را بررسی کنید.
نکته: نتیجه یک ضبط آزمایشگاهی لزوماً معادل تجربه تمام کاربران واقعی نیست. بهتر است از این ابزار برای تشخیص علت و از داده واقعی برای سنجش نتیجه کلی استفاده شود.
در یک فروشگاه اینترنتی، هدف نهایی فقط دریافت برچسب Good نیست. عملکرد فنی باید در کنار تجربه خرید و شاخص‌های تجاری ارزیابی شود.
برای مثال، پس از بهینه‌سازی صفحه محصول، می‌توانید تغییر نرخ افزودن به سبد، نرخ تکمیل خرید، نرخ خطا و زمان تعامل را بررسی کنید.
اما نباید هر تغییر فروش را مستقیماً به Core Web Vitals نسبت داد.
ممکن است هم‌زمان قیمت محصولات، موجودی، کمپین تبلیغاتی یا شرایط بازار تغییر کرده باشند.
روش پیشنهادی: تاریخ اجرای اصلاحات فنی را ثبت کنید و شاخص‌های عملکرد را در بازه‌های قابل مقایسه بررسی کنید. در صورت امکان، تغییرهای بزرگ دیگر را نیز در گزارش یادداشت کنید.
به این ترتیب می‌توانید تصویر دقیق‌تری از رابطه احتمالی بهینه‌سازی فنی و رفتار مشتریان داشته باشید؛ بدون اینکه درباره علت افزایش یا کاهش فروش نتیجه‌گیری شتاب‌زده انجام دهید.
تغییر تعداد URLهای گزارش‌شده ممکن است علت‌های مختلفی داشته باشد.
گاهی یک مشکل فنی تازه ایجاد شده است. اما در شرایط دیگر، اضافه شدن داده کافی برای گروه‌های بیشتر، تغییر ترکیب کاربران یا جابه‌جایی مقدار یک معیار در مرز وضعیت‌ها می‌تواند در نمودار اثر بگذارد.
برای مثال، اگر LCP گروهی از ۴ ثانیه عبور کند، وضعیت آن معیار ممکن است از Need improvement به Poor تغییر کند.
همچنین اگر تعداد بیشتری از صفحات وارد گروه دارای داده کافی شوند، تعداد URLهای قابل مشاهده در گزارش تغییر می‌کند.
راهکار: هنگام مشاهده جهش ناگهانی نمودار، ابتدا مقدار واقعی معیار، تاریخ تغییر، گروه‌های درگیر و تغییرهای فنی سایت را بررسی کنید.
فقط از روی افزایش عدد URLهای Poor نمی‌توان علت را با اطمینان تعیین کرد.
پس از برطرف کردن علت فنی، بهتر است ابتدا اصلاح را با ابزارهای آزمایشگاهی بررسی کنید.
برای مثال، اگر مشکل مربوط به LCP تصویر اصلی بوده است، دوباره عنصر LCP و زمان دریافت و نمایش آن را بررسی کنید.
اگر مشکل INP بوده، تعامل‌های واقعی را مجدداً آزمایش کنید.
سپس از گزارش Core Web Vitals در سرچ کنسول، بخش مربوط به همان مشکل را باز کنید.
در راهنمای فعلی سرچ کنسول، گزینه‌ای با عنوان Start Tracking برای آغاز پیگیری اعتبارسنجی مشکل معرفی شده است.
طبق راهنمای رسمی گوگل، این فرایند بررسی داده‌های CrUX را طی یک بازه ۲۸روزه دنبال می‌کند.
نکته بسیار مهم: شروع اعتبارسنجی باعث ایندکس مجدد فوری صفحات یا اجرای تست سرعت ویژه روی سرور شما نمی‌شود. این فرایند، پیگیری وضعیت داده‌های تجربه واقعی کاربران است.
اگر مشکل در یکی از URLهای مرتبط همچنان وجود داشته باشد، ممکن است اعتبارسنجی آن مشکل موفق نشود. بنابراین بهتر است تا حد امکان علت مشترک را برای همه صفحات درگیر اصلاح کنید.
یکی از دلایل اصلی، باقی ماندن داده‌های عملکرد قبلی در بازه گزارش است.
برای مثال، فرض کنید در تاریخ مشخصی حجم تصویر اصلی محصولات کاهش داده شده و نتایج آزمایشگاهی بهبود پیدا کرده‌اند. بااین‌حال، تجربه کاربران روزهای قبل همچنان در پنجره ۲۸روزه حضور دارد.
دلیل دیگر می‌تواند این باشد که اصلاح فقط روی چند صفحه اعمال شده، اما سایر اعضای گروه هنوز مشکل دارند.
همچنین ممکن است تغییر فنی انجام‌شده مشکل اصلی را کامل برطرف نکرده باشد.
راهکار: وضعیت نسخه منتشرشده، داده‌های جدید، گروه‌های درگیر و عملکرد کاربران واقعی را بررسی کنید.
تکرار چندباره اعتبارسنجی بدون اصلاح واقعی معمولاً راهکار مناسبی نیست.
برای ارائه وضعیت به مدیر فروشگاه یا تیم فنی، لازم نیست تمام جزئیات عملکرد مرورگر در گزارش مدیریتی قرار گیرند.
بهتر است گزارش شامل وضعیت فعلی، مشکل اصلی، علت احتمالی، اقدام انجام‌شده و نتیجه قابل اندازه‌گیری باشد.
| بخش | نمونه گزارش فرضی |
|---|---|
| محدوده بررسی | صفحات محصول و دسته‌بندی در موبایل |
| منبع داده | Google Search Console و PageSpeed Insights |
| مشکل اول | LCP ضعیف تصاویر اصلی محصول |
| مشکل دوم | INP ضعیف فیلترهای دسته‌بندی |
| مشکل سوم | CLS ناشی از تصاویر بدون فضای ثابت |
| اقدام فنی | بهینه‌سازی تصویر، اصلاح کد فیلتر و رزرو فضای عناصر |
| تست بعد از اصلاح | بررسی آزمایشگاهی و تست تعامل |
| وضعیت داده واقعی | نیازمند پایش دوره جدید |
| هدف | رسیدن به محدوده Good در هر سه معیار |
این نمونه، گزارش واقعی یک سایت مشخص نیست.
توصیه: مقدار هر معیار را همراه با تاریخ، دستگاه و گروه URL ثبت کنید. عبارت‌هایی مانند «سرعت سایت عالی شد» بدون داده قابل مقایسه، برای ارزیابی مدیریتی کافی نیستند.
گزارش Core Web Vitals را در موبایل و دسکتاپ بررسی کنید. مشکلات Poor و Need improvement و URLهای نمونه را ثبت کنید. تاریخ بررسی و مقادیر معیارها را نگه دارید.
از میان صفحات محصول، دسته‌بندی، صفحه اصلی و محتوای آموزشی نمونه‌های مرتبط انتخاب کنید. مطمئن شوید نمونه‌ها با گروه‌های گزارش‌شده ارتباط دارند.
صفحات نمونه را با PageSpeed Insights و Chrome DevTools بررسی کنید. عنصر LCP، تعامل‌های کند و عوامل Layout Shift را شناسایی کنید.
در صورت تأیید علت، تصاویر اصلی، کش، درخواست‌های شبکه و منابع مسدودکننده رندر را اصلاح کنید. بهینه‌سازی تصویر را بدون تخریب کیفیت موردنیاز محصول انجام دهید.
اسکریپت‌های سنگین، فیلترها، انتخاب تنوع و اجزای پویا را بررسی کنید. برای تصاویر و بخش‌هایی که بعداً بارگذاری می‌شوند، فضای مناسب در نظر بگیرید.
ورود به صفحه محصول، انتخاب رنگ، تغییر تعداد، افزودن به سبد و رفتن به تسویه‌حساب را روی موبایل و دسکتاپ بررسی کنید. مطمئن شوید بهینه‌سازی باعث اختلال در عملکرد خرید نشده است.
نتایج آزمایشگاهی را با وضعیت قبل مقایسه کنید. در صورت اطمینان از رفع علت، فرایند پیگیری اعتبارسنجی سرچ کنسول را آغاز یا ادامه دهید و وضعیت داده واقعی را در دوره بعد بررسی کنید.
توجه: این برنامه برای تحلیل و اجرای اصلاحات اولیه است. به معنی تضمین دریافت وضعیت Good در ۱۴ روز نیست؛ زیرا داده‌های واقعی و فرایند اعتبارسنجی در بازه زمانی طولانی‌تری بررسی می‌شوند.
عملکرد فنی سایت یکی از بخش‌های مهم تجربه خرید اینترنتی است. فروشگاه باید بتواند تصاویر محصولات، محتوای صفحات، دسته‌بندی‌ها و مسیر خرید را به‌شکلی منظم ارائه کند.
مای‌تارنما یک سایت‌ساز اختصاصی فروشگاهی است که امکانات معرفی‌شده‌ای مانند مدیریت محصولات، دسته‌بندی کالاها، محصولات متغیر و چندقیمتی، ثبت سفارش، درگاه پرداخت، وبلاگ، اتصال دامنه اختصاصی و ساختار مناسب برای فعالیت‌های سئو دارد.
این امکانات می‌توانند برای ایجاد فروشگاه اینترنتی با برند اختصاصی و مدیریت منظم اطلاعات محصولات کاربرد داشته باشند.
بااین‌حال، باید میان وجود زیرساخت مناسب و تضمین امتیاز Good در Core Web Vitals تفاوت قائل شد.
مقدار LCP، INP و CLS به عوامل مختلفی مانند تصاویر واقعی محصولات، ساختار صفحات، شبکه و دستگاه کاربران، نحوه اجرای کدها و ابزارهای جانبی وابسته است.
بنابراین نباید بدون اندازه‌گیری واقعی اعلام کرد تمام صفحات یک فروشگاه یا تمام سایت‌های ساخته‌شده با یک فروشگاه‌ساز، همیشه در محدوده Good قرار می‌گیرند.
اگر سرعت و تجربه کاربری برای کسب‌وکار شما اهمیت زیادی دارد، بهتر است صفحات نمونه را با PageSpeed Insights بررسی کنید و درباره روش مدیریت تصاویر، کش، اسکریپت‌ها و امکانات بهینه‌سازی با پشتیبانی فنی هماهنگ شوید.
در تست رایگان ۱۰روزه مای‌تارنما می‌توانید چند محصول با تصاویر واقعی ثبت کنید، صفحات محصول و دسته‌بندی را روی موبایل آزمایش کنید و عملکرد بارگذاری و تعامل‌های اصلی را بررسی کنید.
در صورت نبود داده کافی از کاربران واقعی در دوره آزمایشی، نتایج Lighthouse و PageSpeed Insights می‌توانند برای تشخیص اولیه مفید باشند؛ اما نباید با داده‌های کامل Core Web Vitals اشتباه گرفته شوند.
گزارشی است که تجربه واقعی کاربران را در زمینه سرعت نمایش محتوا، پاسخ‌گویی تعامل‌ها و ثبات بصری بررسی می‌کند و وضعیت گروه‌های URL را با سه معیار LCP، INP و CLS نشان می‌دهد.
برای وضعیت Good، مقدار LCP در صدک ۷۵ باید ۲٫۵ ثانیه یا کمتر باشد. مقدار بیشتر از ۴ ثانیه در محدوده Poor قرار می‌گیرد.
مقدار ۲۰۰ میلی‌ثانیه یا کمتر خوب محسوب می‌شود. بیشتر از ۲۰۰ تا ۵۰۰ میلی‌ثانیه نیازمند بهبود و بیشتر از ۵۰۰ میلی‌ثانیه ضعیف است.
مقدار ۰٫۱ یا کمتر خوب است. مقدار بیش از ۰٫۲۵ در محدوده Poor قرار می‌گیرد.
خیر. از مارس ۲۰۲۴، معیار INP جایگزین FID شد و برای تحلیل پاسخ‌گویی صفحه باید INP را بررسی کرد.
خیر. PageSpeed Insights هم داده واقعی کاربران و هم داده آزمایشگاهی Lighthouse را نمایش می‌دهد. امتیاز Performance آزمایشگاهی با ارزیابی Core Web Vitals یکسان نیست.
ممکن است تفاوت شرایط تست، دستگاه کاربران واقعی، تعامل‌های اندازه‌گیری‌نشده در آزمایشگاه یا داده‌های دوره قبلی باعث این اختلاف باشد. همچنین مقدار یک URL با گروه URLهای مشابه یکسان نیست.
گزارش، URLهای مشابه را برای تحلیل گروهی کنار هم قرار می‌دهد؛ اما ممکن است عملکرد تک‌تک صفحات متفاوت باشد. بهتر است چند صفحه نماینده بررسی و علت مشترک شناسایی شود.
خیر. نبود داده ممکن است به بازدید ناکافی کاربران واجد شرایط یا شرایط گزارش مربوط باشد. برای تحلیل اولیه می‌توان از Lighthouse و ابزارهای دیگر استفاده کرد.
ممکن است تصویر حجم زیادی داشته باشد، دیر شناسایی شود، با Lazy Loading نامناسب بارگذاری شود یا نمایش آن به اجرای اسکریپت و فایل‌های مسدودکننده وابسته باشد.
خیر. این فرمت‌ها می‌توانند به کاهش حجم تصویر کمک کنند، اما اگر مشکل اصلی از TTFB، کشف دیرهنگام منبع یا تأخیر رندر باشد، بهینه‌سازی‌های دیگری نیز لازم هستند.
باید تعامل را با ابزار Performance بررسی کرد. کاهش پردازش سنگین، جلوگیری از رندر اضافی و ارائه بازخورد بصری مناسب می‌توانند مفید باشند؛ اما علت واقعی باید با آزمایش مشخص شود.
اگر ابعاد یا نسبت تصویر پیش از بارگذاری مشخص نباشد، مرورگر ممکن است پس از دریافت فایل فضای تازه‌ای ایجاد کند و عناصر دیگر را جابه‌جا کند.
خیر. CDN ممکن است دریافت بعضی منابع را سریع‌تر کند، اما مشکلات جاوااسکریپت، پاسخ‌گویی تعامل‌ها و چیدمان صفحه را به‌صورت خودکار برطرف نمی‌کند.
بهتر است براساس شدت مشکل، تعداد URLهای درگیر و اهمیت تجاری تصمیم بگیرید. گاهی یک مشکل مشترک در قالب صفحات محصول اولویت بیشتری از صفحه اصلی دارد.
زمان مشخص و تضمین‌شده‌ای وجود ندارد. گزارش از داده‌های تجربه واقعی در بازه ۲۸روزه استفاده می‌کند و تغییرات پس از جمع‌آوری و پردازش داده جدید منعکس می‌شوند.
این گزینه فرایند پیگیری وضعیت مشکل را براساس داده‌های CrUX آغاز می‌کند. اجرای آن به معنی ایندکس مجدد فوری یا تضمین رفع مشکل نیست.
می‌تواند به بهبود تجربه صفحه و برخی جنبه‌های ارزیابی جست‌وجو کمک کند، اما افزایش رتبه یا کلیک قطعی نیست. کیفیت و ارتباط محتوا و سایر عوامل سئو همچنان اهمیت دارند.
ابتدا وضعیت موبایل و دسکتاپ و گروه‌های Poor را بررسی کنید. سپس معیار اصلی مشکل، URLهای نماینده و علت فنی را با PageSpeed Insights و DevTools مشخص کنید. پس از اصلاح، عملکرد واقعی را در گزارش‌های بعدی پایش کنید.
پاسخ سؤال چگونه گزارش Core Web Vitals را برای صفحات فروشگاهی تحلیل کنیم؟ فقط در بررسی یک امتیاز سرعت خلاصه نمی‌شود.
برای تحلیل درست، باید بدانیم LCP سرعت نمایش محتوای اصلی، INP پاسخ‌گویی صفحه به تعامل کاربر و CLS ثبات بصری عناصر را اندازه می‌گیرند.
گزارش Google Search Console بر پایه تجربه واقعی کاربران در مجموعه CrUX و بازه ۲۸روزه تهیه می‌شود. این گزارش URLهای مشابه را گروه‌بندی می‌کند و وضعیت هر گروه براساس ضعیف‌ترین معیار مؤثر آن تعیین می‌شود.
بنابراین ممکن است یک صفحه در تست Lighthouse امتیاز مناسبی داشته باشد، اما گروه آن در سرچ کنسول هنوز Poor باشد.
در صفحات محصول، تصویر اصلی، اطلاعات تنوع و دکمه خرید اهمیت زیادی دارند. در صفحات دسته‌بندی، فیلترها، مرتب‌سازی و کارت‌های محصولات می‌توانند بر عملکرد اثر بگذارند. در صفحات تسویه‌حساب نیز پاسخ‌گویی فرم‌ها و ثبات چیدمان اهمیت دارند.
برای اصلاح مشکلات، ابتدا علت واقعی را شناسایی کنید. ممکن است نیاز به بهینه‌سازی تصویر، کاهش تأخیر سرور، اصلاح کدهای JavaScript، رزرو فضای عناصر یا مدیریت منابع جانبی داشته باشید.
پس از تغییرات نیز باید سلامت فرایند خرید را آزمایش و نتایج را با داده‌های واقعی کاربران ارزیابی کنید. بهبود آزمایشگاهی ارزشمند است، اما به‌تنهایی به معنی تغییر فوری گزارش سرچ کنسول نیست.
اصل کلیدی این است: به‌جای تلاش برای کسب یک عدد سبز در تست سرعت، مشکلاتی را پیدا و برطرف کنید که واقعاً باعث کندی، تأخیر یا جابه‌جایی عناصر در تجربه خرید مشتری می‌شوند.
اگر قصد دارید فروشگاه اینترنتی خود را با محصولات، دسته‌بندی‌ها و محتوای مستقل راه‌اندازی کنید، می‌توانید امکانات سایت‌ساز مای‌تارنما و دوره تست رایگان ۱۰روزه آن را بررسی کنید. با ثبت چند محصول نمونه و آزمایش صفحات در موبایل و دسکتاپ، می‌توانید پیش از شروع فعالیت گسترده، بخش مهمی از نیازهای فنی و تجربه کاربری فروشگاه را ارزیابی کنید.
برای طراحی سایت اختصاصی کسب‌وکارتان، همین حالا مشاوره رایگان دریافت کنید.
نام و شماره را بگذارید تا با شما تماس بگیریم.
دیگر محتوا های مرتبط را بخوانید
مای‌تارنما قویترین و سادهترین سایتسازاینترنتی برای راه‌اندازی کسب‌وکار آنلاین شماست. با ما می‌توانید در سریع‌ترین زمان ممکن، بدون نیاز به دانش برنامهنویسی، سایت فروشگاهی اختصاصی خود را بسازید، محصولاتتان را عرضه کنید و مستقیماً از مشتریان خود سفارش بگیرید. مای‌تارنما ابزارهای کامل مدیریت محصولات، گزارش‌های مالی و سیستم پرداخت ایمن را برای تضمین موفقیت و رشد پایدار فروشگاه شما فراهم میآورد.
