Core Web Vitals سه عدد خشک نیست؛ زبان مشترک گوگل و کاربر برای اینکه بفهمند سایت شما سریع، پایدار و قابل کلیک است یا نه.
چرا سرعت در ۱۴۰۵ غیرقابل مذاکره است؟
کاربر ایرانی با اینترنت ناپایدار و موبایل وارد سایت میشود. اگر صفحه دیر بیاید:
- تبلیغات گوگل گرانتر تمام میشود
- نرخ پرش بالا میرود
- گوگل سیگنال تجربه ضعیف میگیرد
- اعتماد برند آسیب میبیند
سرعت فقط موضوع سئو تکنیکال نیست؛ بخشی از تبدیل و بازگشت سرمایه تبلیغات است.
اگر تازه با مفهوم Core Web Vitals آشنا میشوید، این معیارها استاندارد رسمی گوگل برای سنجش تجربه واقعی کاربر هستند — نه یک عدد اختیاری که آژانسها اختراع کرده باشند. برای دیدن سرعت در کنار کل مسیر طراحی سایت، مرکز راهنمای طراحی سایت را هم ببینید.
سه معیار اصلی را بشناسید
LCP — بزرگترین عنصر محتوایی
معمولاً تصویر هیرو یا عنوان بزرگ. هدف: زیر ۲٫۵ ثانیه.
اقدامات: فشردهسازی تصویر، اولویتبندی لود، کاهش CSS مسدودکننده، هاست بهتر.
INP — پاسخ به تعامل
تأخیر بعد از کلیک/تپ. هدف: زیر ۲۰۰ میلیثانیه.
اقدامات: کم کردن جاوااسکریپت، شکستن تسکهای سنگین، تعویق اسکریپتهای چت و آنالیتیکس.
CLS — پرش چیدمان
جابهجایی ناگهانی دکمهها هنگام لود. هدف: زیر ۰٫۱.
اقدامات: ابعاد ثابت برای تصویر و تبلیغ، اجتناب از تزریق دیرهنگام بنر.
آزمایشگاه در برابر میدان (Lab vs Field)
PageSpeed Insights دو دنیا را نشان میدهد:
- آزمایشگاه: شرایط شبیهسازیشده؛ برای دیباگ عالی است
- میدان (CrUX / Search Console): تجربه کاربران واقعی کروم
سایت ممکن است در آزمایشگاه سبز و در میدان نارنجی باشد — یا برعکس. برای تصمیم کسبوکار، داده میدانی Search Console را جدیتر بگیرید.
چکلیست ۷ روزه بهبود سرعت
روز ۱: اندازهگیری با Search Console و موبایل واقعی
روز ۲: تبدیل تصاویر به WebP و تعیین width/height
روز ۳: فعالسازی کش و CDN
روز ۴: حذف یا جایگزینی افزونههای سنگین
روز ۵: بهینهسازی فونت فارسی (نمایش swap + زیرمجموعه)
روز ۶: تعویق اسکریپتهای شخص ثالث
روز ۷: مقایسه دوباره و ثبت گزارش
اولویتبندی برای سایتهای ایرانی
اگر بودجه محدود دارید، همه چیز را همزمان اصلاح نکنید. اول صفحههایی را بهینه کنید که پول میسازند: صفحه اصلی، صفحات خدمات، صفحات دستهبندی، صفحات محصول و فرم تماس. بهتر شدن سرعت بلاگ خوب است، اما صفحه محصول کند مستقیماً فروش را کم میکند.
در وردپرس معمولاً سه عامل بیشتر مشکل میسازد: تصاویر بزرگ، افزونههای زیاد و قالبهای سنگین. در سایت اختصاصی، مشکل بیشتر از جاوااسکریپت زیاد، رندر اشتباه یا API کند میآید.
جدول علت و اقدام سریع
| مشکل رایج | نشانه | اقدام اول |
|---|---|---|
| تصویر هیرو سنگین | LCP بد | فشردهسازی + preload |
| چت و پیکسل زیاد | INP بد | تعویق بارگذاری |
| بنر دیررس | CLS بد | رزرو فضا / ابعاد ثابت |
| فونت فارسی درشت | تأخیر متن | subset + font-display |
| هاست ضعیف | همه معیارها | ارتقا یا بهینهسازی سرور |
ارتباط سرعت با طراحی فروشگاهی
در طراحی سایت فروشگاهی سرعت بخشی از مسیر خرید است. صفحه محصول زیبا اگر چند ثانیه دیر لود شود، سبد پر نمیشود. همین منطق برای لندینگ خدمات و فرم مشاوره هم صادق است. برای دیدن اثر مستقیم سرعت روی خرید، افزایش نرخ تبدیل فروشگاه را هم بخوانید.
مرتبط: طراحی سایت، سئو و نمونه بهینهسازی فروشگاهی در ریو پتشاپ.
گزارش سرعت باید چه داشته باشد؟
گزارش خوب فقط یک اسکرینشات PageSpeed نیست. باید شامل موارد زیر باشد:
- وضعیت LCP، INP و CLS روی موبایل
- صفحات اولویتدار برای اصلاح
- علتهای فنی هر مشکل
- اقدامهای سریع و اقدامهای عمیق
- اندازهگیری قبل و بعد از اجرا
وقتی گزارش این ساختار را داشته باشد، سرعت از یک عدد مبهم به برنامه اجرایی تبدیل میشود.
ارتباط سرعت با اعتماد
کاربر معمولاً نمیگوید «LCP بد بود». فقط حس میکند سایت کند، نامطمئن یا غیرحرفهای است. همین حس کافی است تا قبل از تماس یا خرید خارج شود. به همین دلیل سرعت بخشی از UX، برند و فروش است، نه فقط سئو تکنیکال.
اشتباهات رایج بعد از بهینهسازی
خیلی از سایتها یکبار سرعت را بهتر میکنند و بعد دوباره با نصب افزونه، چت آنلاین، اسکریپت تبلیغات و تصاویر سنگین کند میشوند. بهینهسازی سرعت باید بخشی از فرایند انتشار باشد: هر صفحه جدید، هر تصویر جدید و هر ابزار جدید باید اثرش روی موبایل بررسی شود.
برای تیم محتوا هم یک قانون ساده کافی است: تصویر را قبل از آپلود فشرده کنید، عنوان و بخش بالای صفحه را سبک نگه دارید و از گذاشتن چند اسکریپت غیرضروری در همه صفحات خودداری کنید. این کارهای کوچک در مجموع Core Web Vitals را پایدار نگه میدارند.
وردپرس: مسیر عملی بهینهسازی
- قالب سبک یا فرزند بهینهشده
- یک راهکار کش معتبر
- بهینهسازی تصویر هنگام آپلود
- حذف افزونههای متروک
- محدود کردن اسکریپت به صفحات لازم
- مانیتور ماهانه Search Console
اگر سایت وردپرسی اهواز دارید و نگهداری میخواهید، پشتیبانی منظم جلوی برگشت کندی را میگیرد.
سایت اختصاصی / Next.js
کنترل بیشتر یعنی مسئولیت بیشتر:
- بودجهبندی جاوااسکریپت
- تصویر با اندازه پاسخگو
- استریمینگ و اولویتبندی محتوا
- مانیتورینگ واقعی کاربران (RUM) در صورت امکان
سرعت و تبلیغات پولی
در کمپینهای کلیک، فرود کند یعنی هزینه هر تبدیل بالاتر. قبل از افزایش بودجه تبلیغات، LCP صفحه فرود را درست کنید. این کار معمولاً ROI تبلیغ را بهتر از افزایش بودجه خام بالا میبرد.
چه زمانی به متخصص نیاز دارید؟
اگر بعد از اقدامات پایه هنوز میدان نارنجی/قرمز است، یا فروشگاه با هزاران تصویر و فیلتر دارید، بهینهسازی عمیق (کد، سرور، معماری) لازم میشود. وب ریزان این کار را در قالب سئو تکنیکال انجام میدهد.
تصاویر؛ بزرگترین دشمن LCP در فروشگاهها
در عمل، بیش از نیمی از مشکلات LCP فروشگاهها به تصویر برمیگردد:
- آپلود فایل چندمگابایتی از موبایل
- نبود عرض و ارتفاع مشخص
- اسلایدر هیرو با چند تصویر همزمان
- فرمت قدیمی بهجای WebP/AVIF در مرورگرهای پشتیبانیکننده
قانون ساده تیم محتوا: قبل از آپلود، تصویر را برای وب خروجی بگیرید. یک چکلیست کنار پنل بگذارید تا هر همکار جدید همان کار را تکرار کند. بهینهسازی سرعت فقط کار برنامهنویس نیست.
جاوااسکریپت شخص ثالث را مدیریت کنید
چت آنلاین، نقشه حرارتی، پیکسل تبلیغات، تگمنیجر و ویجت نظرسنجی هرکدام ممکن است INP را خراب کنند. راهکارها:
- بارگذاری را به بعد از تعامل یا تایماوت معقول موکول کنید
- ویجت را فقط در صفحات لازم نشان دهید، نه کل سایت
- هر فصل یکبار لیست اسکریپتها را مرور و موارد مرده را حذف کنید
- اثر هر ابزار جدید را روی موبایل قبل از انتشار سراسری بسنجید
سرعت و بازاریابی باید توافق کنند؛ نه اینکه هر تیم ابزار خودش را بدون هماهنگی تزریق کند.
فونت فارسی و پایداری بصری
فونتهای فارسی زیبا اگر سنگین و بدون subset باشند، متن دیر ظاهر میشود یا فونت جایگزین میپرد و CLS میسازد. پیشنهادها:
- فقط وزنهای لازم را لود کنید
font-display: swapرا درست تنظیم کنید- از بارگذاری پنج خانواده فونت در یک صفحه بپرهیزید
- آیکونها را در صورت امکان با SVG سبک جایگزین فونتآیکون سنگین کنید
هاست، کش و واقعیت زیرساخت ایران
گاهی کد خوب است و سرور ضعیف. قبل از بازنویسی قالب:
- TTFB را چک کنید
- کش صفحه و آبجکت را درست پیکربندی کنید
- از هاست شلوغ اشتراکی برای فروشگاه پرترافیک فاصله بگیرید
- بکاپ و مانیتورینگ را بخشی از سرعت پایدار بدانید (بازیابی بعد از حمله/خطا هم تجربه کاربر است)
ارتقای هاست گاهی ارزانتر و سریعتر از سه هفته درگیری با افزونه است.
فرهنگ انتشار سریع و امن
یک قانون تیمی کافی است تا سرعت برنگردد:
هیچ صفحه، تصویر یا اسکریپت جدیدی بدون چک موبایل منتشر نمیشود.
این قانون را در کانال داخلی تیم بنویسید. Core Web Vitals وقتی پایدار میماند که بخشی از عادت انتشار باشد، نه پروژه سالانه.
اولویت صفحات پولساز؛ ماتریس ساده
همه URLها ارزش یکسان ندارند. این ماتریس را پر کنید و از بالا شروع کنید:
| صفحه | ترافیک | تبدیل | وضعیت سرعت | اولویت اصلاح |
|---|---|---|---|---|
| صفحه اصلی | بالا/متوسط | متوسط | ؟ | معمولاً بالا |
| دسته پرفروش | بالا | بالا | ؟ | خیلی بالا |
| محصول پرفروش | متوسط | بالا | ؟ | خیلی بالا |
| لندینگ تبلیغاتی | وابسته به کمپین | بالا | ؟ | قبل از افزایش بودجه |
| بلاگ قدیمی | متغیر | پایین | ؟ | پایینتر |
این کار جلوی بهینهسازی پراکنده را میگیرد و بودجه فنی را روی اثر فروش متمرکز میکند.
ابزارها و جریان کار پیشنهادی
- Search Console → Core Web Vitals (میدان)
- PageSpeed Insights / WebPageTest → تشخیص علت
- کروم DevTools روی موبایل واقعی یا throttling
- لیست اقدام با مالک و تاریخ
- اندازهگیری مجدد بعد از هر تغییر بزرگ
بدون مرحله ۵، تیم در حلقه «حس میکنیم بهتر شد» میماند.
ارتباط سرعت با سئو محلی و فروشگاهی
برای کسبوکار اهوازی، کاربر موبایل روی نقشه یا جستجوی محلی وارد میشود و انتظار پاسخ سریع دارد. صفحه خدمت کند یعنی تماس از دسترفته. برای فروشگاه، هر ثانیه اضافه در محصول یعنی سبد رهاشده بیشتر. سرعت را کنار سئو و طراحی ببینید، نه بهعنوان پروژه جدا در انتهای صف.
چکلیست پذیرش بعد از بهینهسازی
قبل از بستن پروژه سرعت، این موارد را تیک بزنید:
- داده میدانی Search Console بعد از بازه کافی بررسی شده
- صفحات پولساز روی موبایل واقعی تست شدهاند
- تصاویر جدید فرایند فشردهسازی دارند
- فهرست اسکریپتهای شخص ثالث مستند است
- مسئول نگهداری ماهانه مشخص است
- گزارش قبل/بعد با URLهای مشخص ثبت شده
اگر فقط اسکرینشات آزمایشگاهی دارید، پروژه کامل نیست. هدف، تجربه کاربر واقعی است.
سرعت بعد از لانچ کمپین
در زمان کمپین تبلیغاتی معمولاً اسکریپتهای ردیابی زیاد میشوند و سرعت برمیگردد عقب. قبل از هر کمپین بزرگ، یک تست موبایل از صفحه فرود بگیرید و اسکریپتهای موقت را بعد از کمپین پاک یا محدود کنید. سرعت پایدار یعنی انضباط بازاریابی، نه فقط بهینهسازی یکباره فنی.
جمعبندی فنی برای مدیر پروژه
اگر فقط یک جمله به تیم بدهید، این باشد: اول تصاویر و اسکریپتهای شخص ثالث صفحات پولساز، بعد کش و هاست، بعد ظرافتهای کد. ترتیب غلط، بودجه را میسوزاند. سرعت یک پروژه نمایشی نیست؛ یک استاندارد انتشار است که باید در تعریف Done هر تسک باشد.
اشتباه اندازهگیری فقط دسکتاپ
بسیاری از گزارشهای داخلی هنوز دسکتاپ را مبنا میگذارند، در حالی که کاربر ایرانی عمدتاً موبایل است. هر تصمیم سرعت را با داده موبایل بگیرید؛ در غیر این صورت بهینهسازیتان از واقعیت فاصله دارد و بودجه روی صفحهای خرج میشود که مشتری کمتر میبیند.
عیبیابی گامبهگام؛ یک مثال واقعی
فرض کنید صفحه محصول اصلی فروشگاهتان در Search Console «نیاز به بهبود» نشان میدهد. مسیر عیبیابی معمولاً اینطور پیش میرود:
- بررسی داده میدانی: ببینید مشکل موبایل است یا دسکتاپ، و کدام معیار (LCP/INP/CLS) قرمز است.
- بازتولید در آزمایشگاه: همان صفحه را با throttling شبکه موبایل در DevTools یا PageSpeed تست کنید.
- شناسایی عنصر مقصر: اگر LCP بد است، ببینید کدام عنصر بهعنوان Largest Contentful Paint شناخته شده — معمولاً تصویر هیرو یا عنوان بزرگ.
- اندازهگیری علت ریشهای: آیا فایل تصویر بزرگ است؟ آیا CSS مسدودکننده قبل از آن لود میشود؟ آیا سرور دیر جواب میدهد (TTFB)؟
- اصلاح هدفمند: فقط همان علت را برطرف کنید — مثلاً فشردهسازی و پیشبارگذاری تصویر هیرو.
- اندازهگیری دوباره: هم در آزمایشگاه و هم بعد از چند هفته در داده میدانی.
این فرایند ششمرحلهای معمولاً چند ساعت طول میکشد و بسیار مؤثرتر از تغییرات تصادفی «شاید همین کمک کند» است.
بودجه عملکرد (Performance Budget)؛ ابزار عملی برای تیم فنی
بدون یک عدد مشخص، «سریعتر کن» یک درخواست بیپایان میشود. بودجه عملکرد یعنی برای هر بخش صفحه یک سقف مشخص بگذارید تا تیم فنی و محتوا بدانند کجا مرز است:
| بخش صفحه | سقف پیشنهادی | چرا |
|---|---|---|
| کل حجم تصاویر above-the-fold | حدود ۳۰۰ تا ۵۰۰ کیلوبایت | مستقیم روی LCP اثر میگذارد |
| جاوااسکریپت شخص ثالث | حداقل لازم، با لود تأخیری | مستقیم روی INP اثر میگذارد |
| تعداد فونت وب فعال | یک تا دو خانواده | کاهش تأخیر رندر متن |
| زمان پاسخ سرور (TTFB) | زیر ۶۰۰ میلیثانیه | پایه همه معیارهای بعدی |
وقتی تیم بازاریابی میخواهد اسکریپت یا بنر جدید اضافه کند، این جدول مرجع تصمیم میشود: «آیا از بودجه رد میشویم یا نه؟» — نه بحث ذوقی.
چطور سرعت را برای مدیر غیرفنی توضیح دهید
اگر مدیر یا صاحب کسبوکار عدد LCP و INP را درک نمیکند، مشکل ارتباط شماست نه او. این تشبیهها معمولاً کار میکنند:
- LCP یعنی چقدر طول میکشد تا مشتری چیزی که آمده ببیند را واقعاً ببیند — مثل مدت انتظار جلوی ویترین بسته.
- INP یعنی وقتی مشتری دکمه را میزند، فروشگاه چقدر سریع جواب میدهد — مثل فروشندهای که فوراً یا با تأخیر پاسخ میدهد.
- CLS یعنی آیا قفسهها ثابتاند یا هر لحظه جای کالا عوض میشود و مشتری گیج میشود.
با این زبان، تصمیم بودجه برای بهینهسازی سرعت بهجای بحث فنی، تبدیل به بحث تجربه مشتری میشود — که برای هر مدیر ملموستر است.
چه زمانی سرعت واقعاً روی رتبه اثر میگذارد؟
سرعت یکی از دهها سیگنال رتبهبندی گوگل است، نه تنها عامل. اما در عمل، اثرش بیشتر از عدد خامش است چون:
- سایت کند نرخ پرش بالاتری میسازد؛ نرخ پرش بالا سیگنال منفی غیرمستقیم است
- در نتایج نزدیک به هم (محتوای مشابه، اعتبار مشابه)، سرعت میتواند تعیینکننده باشد
- سرعت پایین تجربه کاربر را خراب میکند و مستقیماً فروش و بازگشت کاربر را کم میکند — حتی اگر رتبه ثابت بماند
سناریوهای رایج کندی سایت
فروشگاه با اسلایدر تصویر بزرگ در صفحه اصلی
اسلایدر با ۵ عکس سنگین همزمان، یکی از رایجترین دلایل LCP بد در فروشگاههای ایرانی است. راهحل: یک تصویر اول سبک و آماده preload، بقیه با تأخیر بارگذاری شوند.
سایت شرکتی با ویدیوی پسزمینه در هدر
ویدیوی خام و بدون فشردهسازی در هدر میتواند بهتنهایی چند ثانیه به LCP اضافه کند. اگر ویدیو ضروری است، نسخه فشرده و کوتاه بگذارید یا آن را بعد از لود اولیه صفحه شروع کنید.
بلاگ یا صفحه محتوا با دهها تصویر تزئینی
هر تصویر تزئینی که مستقیماً به محتوا کمکی نمیکند، فقط بار صفحه را زیاد میکند. برای وبلاگ، اولویت با شفافیت و سرعت خواندن است، نه تراکم تصویر.
فرم چندمرحلهای با اعتبارسنجی سنگین در سمت کلاینت
اگر فرم تماس یا checkout با هر کلید فشرده شدن، محاسبات سنگین اجرا کند، INP آسیب میبیند. اعتبارسنجی را ساده و غیرمسدودکننده نگه دارید.
اعتراضات رایج تیم توسعه و پاسخ
| اعتراض | پاسخ عملی |
|---|---|
| «مشتری این تصاویر باکیفیت را میخواهد» | کیفیت بصری و حجم فایل دو چیز متفاوتاند؛ فشردهسازی درست کیفیت را حفظ میکند و حجم را کم میکند. |
| «این اسکریپت را بازاریابی خواسته، نمیشود حذفش کرد» | لازم نیست حذف شود؛ لود تأخیری یا محدود به صفحات لازم معمولاً بدون از دست دادن قابلیت، اثر منفی را کم میکند. |
| «سرور خوبی داریم، چرا هنوز کند است؟» | سرور قوی مشکل کد سنگین فرانت یا تصاویر بزرگ را حل نمیکند؛ باید هر دو لایه را جدا بررسی کرد. |
| «همه رقبا هم کند هستند» | کندی رقبا مزیت شما را کم نمیکند، برعکس؛ فرصت تمایز در تجربه سریعتر ایجاد میشود. |
چکلیست شروع برای فروشگاههای بزرگ (هزاران محصول)
فروشگاههای بزرگ چالشهای خاص خودشان را دارند:
- بررسی سرعت بهصورت نمونهای روی چند دسته پرترافیک، نه فقط صفحه اصلی
- بررسی اثر فیلترهای پیشرفته روی زمان رندر
- مانیتورینگ خودکار (RUM) بهجای تست دستی مکرر
- بررسی اثر تصاویر تولیدشده توسط کاربران (نظرات با عکس) روی سرعت
- برنامه فصلی مرور و حذف اسکریپتهای شخص ثالث متروک
در این مقیاس، بهینهسازی دستی کافی نیست؛ نیاز به فرایند و مانیتورینگ مستمر دارید. اگر هنوز بین وردپرس و پلتفرم اختصاصی برای این مقیاس تصمیم نگرفتهاید، وردپرس یا سایت اختصاصی را هم ببینید — سرعت یکی از معیارهای اصلی همان تصمیم است.
جمعبندی
Core Web Vitals پروژه یکباره نیست؛ فرهنگ نگهداری است. اول صفحات پولساز، بعد ابزارها، بعد مانیتور مستمر.
اگر نیاز به اجرای تخصصی دارید، از تماس با وب ریزان شروع کنید یا خدمات سئو را ببینید.