Core Web Vitals یعنی سه معیار اصلی گوگل برای سنجش تجربه واقعی کاربر از سرعت بارگذاری، واکنش پذیری و ثبات بصری صفحه: LCP، INP و CLS . این معیارها بهت می گن صفحه چقدر سریع محتوای اصلی را نشان می دهد، چقدر سریع به تعامل کاربر جواب می دهد و موقع لود شدن چقدر می پرد و جابه جا می شود. هشت پا این راهنما را برای سئوکارها، مدیران سایت، تیم های محتوا و دولوپرهایی نوشته که در Search Console با پیام های Poor، Needs improvement یا URL groups درگیرند و نمی خوان فقط امتیاز PageSpeed را تزئینی سبز کنند. خلاصه اش اینه: Core Web Vitals فقط بحث سرعت نیست؛ بحث تجربه واقعی آدم ها روی موبایل، اینترنت معمولی، قالب واقعی سایت و صفحات مهم تجاریه.

Core Web Vitals چیست؟

Core Web Vitals مجموعه ای از سه معیار تجربه کاربری است که گوگل برای سنجش عملکرد واقعی صفحات وب استفاده می کند: Largest Contentful Paint یا LCP برای سرعت نمایش محتوای اصلی، Interaction to Next Paint یا INP برای واکنش پذیری صفحه، و Cumulative Layout Shift یا CLS برای ثبات بصری. اگر این سه معیار در محدوده خوب باشند، صفحه از نظر تجربه فنی پایه وضعیت سالم تری دارد. گوگل در Search Central میگه Core Web Vitals مجموعه ای از metrics برای اندازه گیری تجربه واقعی کاربر در Loading Performance، Interactivity و Visual Stability است و ابزارهایی مثل Search Console، PageSpeed Insights و Chrome User Experience Report همین LCP، INP و CLS را اندازه گیری می کنند. این تعریف خیلی ساده به نظر میاد، اما در عمل یعنی باید سایت را با داده واقعی کاربران بررسی کنی، نه فقط با یک تست آزمایشگاهی روی لپ تاپ خودت.

نکته: Core Web Vitals قرار نیست جای محتوای خوب، لینک سازی درست یا Search Intent را بگیرد. اما اگر صفحه کند، پرش دار و دیرواکنش باشد، حتی محتوای خوب هم تجربه بدی می سازد. گوگل هم دقیقاً همین بخش تجربه واقعی را جدی تر از قبل می بیند.

Core Web Vitals شامل چه معیارهایی است؟

Core Web Vitals شامل LCP، INP و CLS است. این معیارها به‌ترتیب سرعت نمایش محتوای اصلی، واکنش‌پذیری صفحه و ثبات بصری را می‌سنجند.

معیار	خوب	نیازمند بهبود	ضعیف
LCP	۲.۵ ثانیه یا کمتر	۲.۵ تا ۴ ثانیه	بیشتر از ۴ ثانیه
INP	۲۰۰ میلی‌ثانیه یا کمتر	۲۰۰ تا ۵۰۰ میلی‌ثانیه	بیشتر از ۵۰۰ میلی‌ثانیه
CLS	۰.۱ یا کمتر	۰.۱ تا ۰.۲۵	بیشتر از ۰.۲۵

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

آیا Core Web Vitals فاکتور رتبه بندی گوگل است؟

تجربه صفحه باید در کنار ارتباط محتوا با نیت کاربر دیده شود؛ راهنمای Search Intent کمک می‌کند اولویت محتوا و عملکرد فنی را هماهنگ کنید.

Core Web Vitals بخشی از Page Experience signals گوگل است، اما به تنهایی مهم ترین عامل رتبه بندی نیست. اگر دو صفحه از نظر محتوا، ارتباط با جستجو و اعتبار نزدیک باشند، تجربه صفحه بهتر می تواند کمک کند؛ اما صفحه سریع با محتوای ضعیف معمولاً جای صفحه مفید و مرتبط را نمی گیرد. گوگل در مستندات Core Web Vitals میگه برای موفقیت در Google Search لازم نیست الزاماً همه Core Web Vitals را به بهترین شکل پاس کنی، اما داشتن تجربه صفحه خوب می تواند با آنچه سیستم های رتبه بندی گوگل دنبال پاداش دادن به آن هستند هم راستا باشد. ترجمه اجرایی اش اینه: اگر صفحه ات Intent را جواب نمی دهد، Title بد دارد، محتوای کم عمق دارد و اعتبار ندارد، سبز شدن LCP و CLS نجاتش نمی دهد. اما اگر محتوای خوبی داری و بین چند رقیب نزدیک رقابت می کنی، Core Web Vitals ضعیف می تواند ترمزت باشد. نکته: Core Web Vitals را نه بت کن، نه بی خیالش شو. باهاش مثل یکی از ستون های فنی سئو برخورد کن؛ مهم، اما نه تنها عامل بازی.

تفاوت Field Data و Lab Data در Core Web Vitals چیست؟

Field Data تجربه واقعی کاربران را نشان می‌دهد و برای تصمیم‌های سئویی مهم‌تر است. Lab Data در شرایط آزمایشگاهی تولید می‌شود و برای پیدا‌کردن علت فنی مشکل کاربرد دارد.

نوع داده	منبع	کاربرد
Field Data	کاربران واقعی Chrome	ارزیابی وضعیت واقعی
Lab Data	Lighthouse	عیب‌یابی فنی
Search Console CWV	داده‌های گروه‌بندی‌شده	شناسایی الگوهای مشکل‌دار
DevTools Performance	تست داخل مرورگر	بررسی JavaScript و Rendering

LCP چیست؟

LCP یا Largest Contentful Paint مدت زمانی را اندازه می گیرد که طول می کشد تا بزرگ ترین عنصر محتوایی قابل مشاهده در viewport بارگذاری و نمایش داده شود. این عنصر معمولاً تصویر Hero، ویدئو، بنر اصلی یا یک بلوک بزرگ متن است. LCP خوب یعنی این عنصر باید در ۲.۵ ثانیه یا کمتر برای ۷۵ ٪ بازدیدها نمایش داده شود. گوگل در Search Console Help هم LCP را مدت زمان رندر شدن بزرگ ترین عنصر محتوایی قابل مشاهده در viewport از زمان درخواست URL تعریف می کند و می گوید این عنصر معمولاً تصویر، ویدئو یا یک متن بزرگ است. چند مثال:

• در صفحه مقاله، LCP ممکنه تصویر شاخص یا تیتر بزرگ مقاله باشد.
• در صفحه محصول، LCP معمولاً تصویر اصلی محصول است.
• در صفحه خدمات، LCP ممکنه Hero section یا تیتر و تصویر بالای صفحه باشد.

• در صفحه دسته بندی فروشگاه، LCP گاهی اولین تصویر محصول یا بنر بالای دسته است. نکته: LCP فقط لود کامل صفحه نیست. ممکنه کل صفحه هنوز کامل نشده باشد، اما محتوای اصلی دیده شده باشد. تمرکز LCP روی همان چیزی است که کاربر اول از همه باید ببیند.

چطور LCP را بهتر کنیم؟

برای بهبود LCP باید بزرگ ترین عنصر محتوایی صفحه را سریع تر به کاربر برسانی. معمولاً مشکل از تصویر Hero سنگین، TTFB بالا، CSS و JS مسدودکننده، نبود کش مناسب، فونت های کند یا رندر سمت کلاینت بیش از حد میاد. راه حل های مهم:

• کاهش TTFB یا زمان پاسخ سرور: اگر سرور دیر جواب بده، همه چیز دیر شروع می شود. کش سمت سرور، CDN، بهینه سازی دیتابیس و کاهش پردازش های سنگین بک اند کمک می کنند.
• بهینه سازی تصویر LCP : تصویر Hero را با فرمت مناسب مثل WebP یا AVIF، سایز درست، فشرده سازی منطقی و ابعاد مشخص استفاده کن. تصویر ۳۰۰۰ پیکسلی برای نمایش ۹۰۰ پیکسلی یعنی خودآزاری فنی.
• Preload کردن عنصر مهم: اگر تصویر اصلی LCP است، در بعضی موارد preload می تونه کمک کند مرورگر زودتر آن را دریافت کند.
• حذف یا کاهش Render-blocking resources: CSS و JS سنگین قبل از نمایش محتوای اصلی می توانند LCP را عقب بیندازند. Critical CSS و defer/async برای JS های غیرضروری کمک می کند.
• استفاده درست از Lazy Loading : تصویر LCP را lazy-load . نکن این اشتباه را زیاد می بینم؛ تصویر اصلی صفحه را تنبل بارگذاری می کنند، بعد تعجب می کنند چرا LCP قرمز شده.
• بهینه سازی فونت: فونت های فارسی اگر بد لود شوند، می توانند نمایش متن را عقب بیندازند. font-display: swap و محدود کردن وزن های فونت کمک می کند.

نمونه فرضی: صفحه خدماتی یک آژانس، تصویر Hero با حجم ۱.۸ مگابایت دارد و روی موبایل هم همان تصویر دسکتاپ را لود می کند. LCP موبایل ۴.۲ ثانیه است. با ساخت نسخه موبایل تصویر، فشرده سازی، preload تصویر اصلی و کش درست، میشه انتظار داشت LCP به محدوده قابل قبول نزدیک تر شود. عدد دقیق بدون تست واقعی نمی دم، چون هر هاست، قالب و دستگاه فرق دارد.

INP چیست؟

INP یا Interaction to Next Paint معیار واکنش پذیری صفحه است و نشان می دهد صفحه بعد از تعامل کاربر، مثل کلیک، لمس یا تایپ، چقدر سریع پاسخ بصری می دهد. INP از سال ۲۰۲۴ جای FID را به عنوان Core Web Vital مربوط به تعامل گرفت، چون تجربه تعامل را کامل تر از FID می سنجد.توضیح می دهد INP با مشاهده تأخیر همه تعامل های کاربر در طول بازدید صفحه، واکنش پذیری را ارزیابی می کند و مقدار نهایی آن یکی از طولانی ترین تعامل هاست، با نادیده گرفتن برخی outlier . ها برای اینکه INP خوب باشد، باید ۲۰۰ میلی ثانیه یا کمتر باشد. این یعنی فقط اولین کلیک مهم نیست. اگر کاربر وارد صفحه محصول شود، روی فیلتر قیمت کلیک کند، سبد خرید را باز کند یا فرم را پر کند، همه این تعامل ها می توانند روی INP اثر بگذارند. دقیقاً برای همین INP از FID جدی تره؛ چون کل عمر صفحه را می بیند، نه فقط اولین تعامل. نکته: INP بیشتر از همه با JavaScript، Main Thread، Event Handler ها و کامپوننت های سنگین درگیره. اگر سایتت کلی اسلایدر، چت آنلاین، تگ تبلیغاتی، اسکریپت مارکتینگ و پاپ آپ دارد، INP می تونه خیلی راحت قرمز شود. بله، هر ابزار فقط یه اسکریپت کوچیک می ذاره؛ جمعشان میشه هیولا.

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

برای بهبود INP باید کاری کنی صفحه سریع تر به تعامل های کاربر جواب بدهد. در عمل یعنی JavaScript سنگین را کم کنی، Main Thread را آزادتر نگه داری، Event Handler ها را سبک تر کنی و کارهای طولانی را خرد یا به تعویق بیندازی. راه حل های مهم:

• کاهش JavaScript : غیرضروری هر کتابخانه، پلاگین و اسکریپت مارکتینگ را بررسی کن. اگر اسکریپتی روی صفحه خدمات یا مقاله هیچ نقشی ندارد، چرا باید آنجا لود شود؟
• تقسیم کارهای طولانی: Long Task هایی که Main Thread را قفل می کنند، تعامل کاربر را عقب می اندازند. باید پردازش های طولانی را chunk کنی یا بعد از تعامل اصلی انجام بدهی.
• بهینه سازی Event Handler : ها اگر کلیک روی فیلتر محصول چندین محاسبه، درخواست، تغییر DOM و رندر سنگین ایجاد می کند، INP آسیب می بیند.
• کاهش DOM بزرگ و پیچیده: صفحه ای با هزاران node، جدول های عظیم یا کامپوننت های تو در تو معمولاً تعامل کندتری دارد.
• استفاده درست از Web Worker : پردازش های سنگین را در صورت امکان از Main Thread جدا کن.
• حذف پلاگین های فرانت اند بی مصرف: مخصوصاً در وردپرس، افزونه های فرم، اسلایدر، پاپ آپ، چت و آنالیتیکس می توانند به شدت روی INP اثر بگذارند. نمونه فرضی: یک سایت فروشگاهی روی موبایل وقتی کاربر فیلتر سایز را باز می کند، ۷۰۰ میلی ثانیه طول می کشد تا UI واکنش نشان دهد. بررسی Performance نشان می دهد کلیک فیلتر همزمان چند اسکریپت ریتارگتینگ، مرتب سازی محصول و رندر دوباره کل لیست را فعال می کند. با جدا کردن اسکریپت ها، رندر تدریجی و کاهش DOM، INP قابل کنترل تر می شود.

CLS چیست؟

CLS یا Cumulative Layout Shift میزان جابه جایی ناگهانی و غیرمنتظره عناصر صفحه را اندازه می گیرد. اگر صفحه هنگام لود شدن بپرد، دکمه پایین تر برود، تصویر ناگهان جا باز کند یا بنر تبلیغاتی وسط متن ظاهر شود، CLS بالا می رود. CLS خوب باید ۰.۱ یا کمتر باشد.

گوگل در Search Console Help میگه CLS مجموع امتیاز همه layout shift های غیرمنتظره در طول عمر صفحه را اندازه می گیرد. این یعنی فقط لحظه اول لود مهم نیست؛ هر جابه جایی غیرمنتظره در تجربه کاربر می تونه وارد محاسبه شود. چند مثال خیلی ملموس:

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

چطور CLS را بهتر کنیم؟

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

• تعیین width و height برای تصاویر و ویدئوها: وقتی مرورگر از قبل ابعاد را بداند، جای عنصر را رزرو می کند و صفحه کمتر می پرد.
• رزرو فضا برای تبلیغات و iframe : ها اگر بنر تبلیغاتی داری، container آن باید قبل از لود شدن تبلیغ ارتفاع مشخص داشته باشد.
• مدیریت فونت ها: استفاده از font-display، preload فونت های مهم و کاهش وزن های غیرضروری کمک می کند پرش متن کمتر شود.
• اضافه نکردن محتوا بالای محتوای موجود: پاپ آپ، نوار نصب اپ، پیام کوکی یا بنر تخفیف اگر ناگهانی از بالا وارد شود، CLS می‌سازد.

• جلوگیری از تزریق دیرهنگام کامپوننت ها: مثلاً فرم خبرنامه یا ویجت پیشنهاد محصول نباید بعد از لود شدن متن، ناگهان وسط صفحه جا باز کند.
• استفاده از aspect-ratio در CSS : برای تصاویر واکنش گرا، نسبت ابعاد مشخص می تواند خیلی کمک کند. نمونه فرضی: در یک بلاگ، تصویر شاخص مقاله بدون ابعاد مشخص در HTML قرار گرفته. روی اینترنت کند، اول متن لود می شود، بعد تصویر جا باز می کند و متن پایین می پرد. با اضافه کردن width/height یا aspect-ratio، CLS همان صفحه می تواند به شکل محسوسی بهتر شود.

گزارش Core Web Vitals در Search Console را چطور بخوانیم؟

برای تحلیل صفحات ورودی کمپین، داده‌های سرچ کنسول را کنار عملکرد تبلیغات بررسی کنید تا URLهای کند و کم‌اثر زودتر مشخص شوند.

گزارش Core Web Vitals در Search Console صفحات سایت را بر اساس داده واقعی کاربران Chrome و به تفکیک Mobile و Desktop گروه بندی می کند. این گزارش URL ها را در وضعیت Good، Needs improvement و Poor نشان می دهد و معمولاً URL های مشابه را در یک گروه قرار می دهد. Search Console Help توضیح می دهد این گزارش URL ها را بر اساس status، metric type و URL group نشان می دهد و داده ها برای Mobile و Desktop جدا هستند. همچنین مقدار گروه برای LCP، INP و CLS بر اساس ۷۵ ٪ درخواست های صفحه در ۲۸ روز گذشته گزارش می شود. موقع خواندن گزارش، این مسیر را برو:

1. اول Mobile و Desktop را جدا بررسی کن. در بیشتر سایت های ایرانی، مشکل موبایل جدی تره؛ چون کاربران با اینترنت و دستگاه های متنوع تری وارد میشن.
2. مشکل را بر اساس metric جدا کن. LCP، INP و CLS راه حل های متفاوت دارند. همه را با افزونه کش حل نمی کنی.
3. URL Group را ببین. اگر یک الگوی صفحه مشکل دارد، مثلاً همه صفحات محصول یا همه مقالات، مشکل احتمالاً قالبی است.

4. Sample URL ها را جدا تست کن. چند URL از هر گروه را در PageSpeed Insights، DevTools و ابزارهای فنی بررسی کن.
5. بعد از اصلاح، Validate Fix را بزن. اما حواست باشد داده Search Console با تأخیر و بر اساس داده ۲۸ روزه تغییر می کند. نکته: Search Console برای تشخیص الگو عالیه، اما برای پیدا کردن ریشه فنی کافی نیست. وقتی گفت LCP مشکل دارد، تازه باید با PageSpeed Insights، DevTools، WebPageTest یا لاگ های فرانت اند بفهمی چرا.

چرا PageSpeed Insights با Search Console فرق دارد؟

PageSpeed Insights یک URL مشخص را بررسی می کند و هم Field Data، هم Lab Data نشان می دهد. Search Console URL ها را گروه بندی می کند و وضعیت را بر اساس داده واقعی کاربران و بازه زمانی گزارش می دهد. برای همین ممکنه PageSpeed یک صفحه را خوب نشان دهد، اما Search Console هنوز گروه آن صفحه را Needs improvement یا Poor . بداند دلایل اختلاف:

• Search Console داده ۲۸ روزه دارد و دیرتر آپدیت می شود.
• PSI ممکنه برای URL خاص Field Data کافی نداشته باشد و Origin-level data نشان دهد.
• Lab Data در PSI شرایط شبیه سازی شده است، نه تجربه همه کاربران واقعی.
• URL Group در Search Console ممکنه چند صفحه مشابه را با هم قضاوت کند.
• تفاوت Mobile و Desktop می تواند نتیجه را عوض کند.
• بهبودهای تازه هنوز در داده CrUX کامل منعکس نشده اند. نمونه فرضی: امروز تصویر Hero را بهینه می کنی و Lab Score بهتر می شود. اما Search Console هنوز تا چند هفته ممکنه همان URL Group را Poor نشان دهد، چون داده واقعی کاربران در بازه ۲۸ روزه جمع می شود. پس بعد از اصلاح، فوری انتظار سبز شدن نداشته باش. سئو تکنیکال هم مثل آش نیست که همین الان هم بزنی جا بیفتد 😄

Core Web Vitals در موبایل مهم تر است یا دسکتاپ؟

هر دو مهم اند، اما در بیشتر پروژه ها موبایل اولویت بالاتری دارد. چون گوگل مدت هاست Mobile-first indexing را مبنا قرار داده و در خیلی از بازارها بخش بزرگی از کاربران با موبایل وارد سایت می شوند. ضمن اینکه مشکلات LCP، INP و CLS معمولاً روی موبایل شدیدتر دیده می شوند. مشکل های رایج موبایل:

• تصویرهای دسکتاپ روی موبایل لود می شوند.
• فونت ها و اسکریپت ها برای صفحه کوچک بهینه نیستند.
• منوها و فیلترها با JS سنگین باز می شوند.
• بنرها، پاپ آپ ها و چت آنلاین فضای زیادی می گیرند.
• اینترنت کندتر و دستگاه ضعیف تر تجربه واقعی را خراب می کند.
• Layout در Breakpoint های مختلف پرش دارد. نکته: اگر فقط روی لپ تاپ دفتر تست می کنی و میگی برای من که، خوبه داری خودت را گول می زنی. کاربر واقعی شاید با موبایل میان رده، اینترنت 4G ناپایدار و مرورگر پر از تب وارد سایتت شده باشد.

اول LCP را بهتر کنیم یا INP یا CLS؟

اولویت اصلاح به وضعیت داده واقعی و نوع صفحه بستگی دارد. اما معمولاً اگر LCP خیلی بد است، از آن شروع کن چون کاربر قبل از هر تعامل باید محتوای اصلی را ببیند. بعد سراغ INP و CLS برو، مگر اینکه یک مشکل CLS یا INP به وضوح تجربه را نابود کرده باشد. اولویت پیشنهادی من:

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

4. INP را برای صفحات تعاملی جدی بگیر فروشگاه، فیلتر محصول، فرم، سبد خرید، داشبورد و صفحات رزرو بیشتر درگیر INP میشن.
5. CLS را اگر کاربر را اذیت می کند فوری رفع کن پرش دکمه خرید یا فرم تماس می تواند مستقیم روی تبدیل اثر بگذارد. نکته: هدف این نیست که همه صفحات سایت را همزمان کامل کنی. اول الگوهای پرترافیک و پول ساز را درست کن. بهینه سازی صفحه ای که سالی ۱۰ بازدید دارد، وقتی صفحه محصول اصلی قرمز است، اولویت ندارد.

بهبود Core Web Vitals در وردپرس

در وردپرس، Core Web Vitals معمولاً تحت تأثیر قالب سنگین، افزونه های زیاد، تصاویر غیربهینه، فونت های نامنظم، صفحه سازها، اسکریپت های ثالث و کش ضعیف قرار می گیرد. وردپرس ذاتاً بد نیست؛ اما وردپرس شلوغ و بی مدیریت خیلی راحت کند می شود. کارهای مهم در وردپرس:

• قالب سبک و به روز انتخاب کن.
• افزونه های غیرضروری را حذف کن.
• کش سمت سرور و مرورگر را فعال کن.
• تصاویر را با WebP/AVIF و سایز مناسب سرو کن.
• Lazy Loading را برای تصاویر پایین صفحه فعال کن، نه تصویر Hero .
• CSS و JS غیرضروری را در صفحات نامرتبط لود نکن.
• فونت های فارسی را محدود و بهینه کن.
• صفحه سازها را کنترل کن؛ هر سکشن یک عالمه div و JS نسازد.
• اسکریپت های چت، پاپ آپ، آنالیتیکس و تبلیغات را با وسواس اضافه کن.
• CDN را برای فایل های استاتیک بررسی کن. نمونه فرضی: یک سایت وردپرسی خدماتی ۲۸ افزونه فعال دارد، سه فونت با چند وزن لود می کند، چت آنلاین در همه صفحات فعاله و صفحه ساز برای هر صفحه کلی CSS اختصاصی می سازد. اینجا نصب یک افزونه کش شاید کمک کند، اما درمان کامل نیست. باید بار صفحه را کم کنی، نه فقط فشرده ترش کنی.

بهبود Core Web Vitals در فروشگاه اینترنتی

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

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

• تصاویر محصول زیاد و سنگین
• فیلترهای Ajax سنگین
• اسکریپت های پیشنهاد محصول
• Review widget های کند
• بنرهای تخفیف و پاپ آپ
• اسلایدرهای بزرگ صفحه دسته بندی
• کارت های محصول بدون ابعاد تصویر مشخص
• سبد خرید و wishlist با JS سنگین
• موجودی و قیمت گذاری پویا بدون کش درست راه حل ها:
• عکس های محصول را responsive و فشرده کن.
• Pagination یا Infinite Scroll را فنی درست پیاده کن.
• برای کارت محصول ابعاد تصویر رزرو کن.
• فیلترها را از نظر INP تست کن.
• تبلیغات و بنرها را بدون ایجاد CLS اضافه کن.
• صفحات دسته بندی مهم را جداگانه بهینه کن.
• Product Schema، قیمت و موجودی را با صفحه هماهنگ نگه دار.
• مسیر خرید را با دستگاه واقعی تست کن، نه فقط Lighthouse .

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

اسکریپت های ثالث چه اثری روی Core Web Vitals دارند؟

اسکریپت های ثالث مثل چت آنلاین، ابزارهای آنالیتیکس، پیکسل تبلیغاتی، Heatmap، A/B Testing، فرم ها، پاپ آپ ها و ابزارهای مارکتینگ می تونن روی LCP، INP و CLS اثر منفی بذارن. مشکل اینجاست که هر تیم میگه این فقط یه تگ، کوچیکه اما مجموعشان صفحه را سنگین و دیرواکنش می کند. چطور مدیریتشان کنیم؟

• همه اسکریپت های ثالث را Inventory . کن
• مشخص کن کدام صفحه واقعاً به کدام اسکریپت نیاز دارد.
• تگ ها را با Delay یا Consent مناسب لود کن.
• اسکریپت های غیرضروری را از صفحات مهم حذف کن.
• اثر هر تگ را قبل و بعد از حذف تست کن.
• چت آنلاین را در همه صفحات لود نکن، مگر واقعاً لازم باشد.
• ابزارهای تکراری را حذف کن؛ دو Heatmap و سه ابزار Analytics لازم نداری.
• Tag Manager را تمیز نگه دار. نمونه فرضی: یک صفحه مقاله ساده ۶ تگ تبلیغاتی، یک چت آنلاین، دو ابزار رفتار کاربر و سه پیکسل تبلیغاتی دارد. بعد تیم می پرسه چرا INP بده؟ خب صفحه مقاله است یا نمایشگاه ابزارهای مارکتینگ؟

Core Web Vitals و CRO چه ارتباطی دارند؟

برای هماهنگ‌کردن بهینه‌سازی فنی با پیام، CTA و ساختار لندینگ پیج ، هر تغییر را با داده واقعی کاربران و نرخ تبدیل بسنجید.

Core Web Vitals و CRO به هم نزدیک اند، چون هر دو به تجربه کاربر و مسیر تبدیل ربط دارند. اگر صفحه دیر محتوای اصلی را نشان دهد، با تأخیر به کلیک پاسخ دهد یا دکمه ها موقع لود جابه جا شوند، احتمالاً نرخ تبدیل هم آسیب می بیند. سه ارتباط مهم:

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

سناریوی عملی: وقتی LCP خوب شد اما فروش بهتر نشد

نمونه فرضی: یک سایت خدماتی روی صفحه لندینگ اصلی LCP را از حدود ۴.۸ ثانیه به ۲.۳ ثانیه رساند. گزارش PageSpeed بهتر شد، Search Console بعد از مدتی URL Group را از Poor به Good نزدیک تر نشان داد. اما تعداد فرم ها تغییر زیادی نکرد. چرا؟ چون مشکل اصلی فقط سرعت نبود. بررسی صفحه نشان می داد:

• پیام Hero مبهم بود.
• CTA بالای صفحه واضح نبود.
• فرم تماس پایین صفحه دفن شده بود.
• قیمت یا مدل همکاری توضیح داده نشده بود.
• نسخه موبایل دکمه تماس را به خوبی نشان نمی داد.
• اعتمادسازی مثل نمونه کار یا فرایند همکاری کم بود. اینجا Core Web Vitals یک مانع فنی را برداشت، اما CRO هنوز مشکل داشت. اصلاح بعدی باید روی پیام، CTA، فرم، اعتمادسازی و مسیر تصمیم انجام می شد. این سناریو را زیاد می بینم: تیم فنی فکر می کنه چون سرعت خوب شد، فروش هم باید خودکار بالا بره. نه عزیز، سرعت در را باز می کند؛ فروش با پیام و پیشنهاد و اعتماد جلو می رود.

اعداد خوب، متوسط و ضعیف برای Core Web Vitals

آستانه‌های رسمی برای همه صفحات یکسان‌اند، اما اولویت اصلاح باید براساس اهمیت صفحه و اثر آن بر کسب‌وکار تعیین شود.

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

صفحه آرشیو یا کم اهمیت بعد از صفحات اصلی نکته: همه Poor ها برابر نیستند. اگر صفحه درخواست مشاوره قرمز است، اول همان را درست کن. صفحه آرشیو برچسب سال ۱۳۹۸ می تونه منتظر بمونه، باور کن ناراحت نمی شه.

اشتباهات رایج در بهبود Core Web Vitals

خیلی ها Core Web Vitals را با چند افزونه کش، کم کردن حجم عکس و گرفتن اسکرین شات سبز از PageSpeed خلاصه می کنند. همین نگاه سطحی باعث میشه مشکل واقعی حل نشود. اشتباهات مهم:

• تمرکز روی امتیاز کلی PageSpeed به جای خود Metricها: عدد ۹۰ خوشگل است، اما باید ببینی LCP، INP و CLS واقعی چه می گویند.
• نادیده گرفتن داده موبایل: دسکتاپ سبز، موبایل قرمز؛ این وضعیت در سایت های زیادی دیده میشه. موبایل را جدی بگیر.
• Lazy-load کردن تصویر LCP : این اشتباه ساده می تونه LCP را نابود کند.
• لود اسکریپت های غیرضروری در همه صفحات: چت، پاپ آپ، اسلایدر و ابزارهای رفتار کاربر را فقط جایی لود کن که واقعاً لازم اند.
• رفع آزمایشگاهی بدون توجه به Field Data : اگر فقط Lighthouse را سبز کنی ولی کاربران واقعی هنوز مشکل داشته باشند، کار نیمه کاره است.
• تغییرات فنی بدون تست بعدی: بعد از اصلاح، باید دوباره PSI، Search Console و در صورت امکان داده RUM را بررسی کنی.
• ندیدن تفاوت قالب ها: مشکل صفحات محصول با مقاله یکی نیست. هر Template را جدا بررسی کن.
• بهینه سازی بیش از حد و خراب کردن UX : حذف تصویر، حذف فونت، حذف تعامل، فقط برای سبز شدن ابزار؟ نه. سایت باید سریع تر شود، نه بی جان تر.

چک لیست بهبود Core Web Vitals

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

قبل از اینکه سراغ اصلاح بروی، این چک لیست را روی صفحات مهم و Template های اصلی اجرا کن. همین چک لیست کمک می کند بفهمی مشکل از سرور است، تصویر است، JS است، قالب است یا اسکریپت های ثالث.

1. LCP element هر Template مشخص شده؟
2. تصویر Hero بهینه و responsive است؟
3. تصویر LCP اشتباهی lazy-load نشده؟
4. TTFB قابل قبول است؟
5. CDN و کش درست فعال اند؟
6. CSS های مسدودکننده کاهش پیدا کرده اند؟
7. JS های غیرضروری defer یا حذف شده اند؟
8. Long Task های Main Thread بررسی شده اند؟
9. تعامل های مهم صفحه از نظر INP تست شده اند؟
10. فونت ها بهینه و محدود هستند؟
11. ابعاد تصاویر و ویدئوها مشخص است؟
12. برای تبلیغات و iframe ها فضا رزرو شده؟
13. پاپ آپ ها و بنرها CLS نمی سازند؟
14. موبایل جدا از دسکتاپ تست شده؟
15. صفحات پول ساز در اولویت اصلاح اند؟
16. Search Console URL Group ها بررسی شده اند؟
17. PageSpeed Insights برای نمونه URL ها اجرا شده؟
18. DevTools Performance برای مشکل های INP استفاده شده؟
19. بعد از اصلاح، Validate Fix در Search Console انجام شده؟
20. اثر تغییرات روی نرخ تبدیل هم بررسی شده؟ نکته: اگر فقط یک مورد را انجام بدی، این باشه: اول LCP element و Long Task های اصلی را پیدا کن. بدون تشخیص، بهینه سازی میشه حدس درمانی.

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