سرعت سایت و Core Web Vitals؛ راهنمای سئوی فارسی

سرعت سایت یک سیگنال رسمی رتبۀ گوگل است، نه نیمی از رتبۀ شما؛ از ۲۰۲۱ که Core Web Vitals رسماً به سیگنال Page Experience تبدیل شد، «سایت زیبا ولی کند» بهانه نیست — و گوگل تأکید می‌کند این سیگنال در کنار صدها سیگنال دیگر وزن می‌گیرد، نه به‌جای آنها.

کاربرِ ناچیده‌شده صبر نمی‌کند؛ صفحه‌ای که اولین محتوا را دیر نشان دهد، در دادهٔ CrUX به‌عنوان تجربۀ ضعیف ثبت می‌شود و گوگل همان رفتار واقعی را می‌بیند. خبر خوب: در تجربۀ تیم ما روی سایتهای فارسی، بیشتر کُندی از دو منبع می‌آید — تصویر سنگین هدر و اسکریپت شخص ثالث؛ همان‌جا که با چند اصلاح ساده برطرف می‌شود.

در این راهنمای وبلاگ AdMetrix می‌خوانید Core Web Vitals دقیقاً چه می‌سنجد، عدد سالم چند است، و چطور بدون تیم فنی بزرگ سایت را به آستانۀ سبز برسانید.

Core Web Vitals چه می‌سنجد: سه متریک، سه سؤال

• LCP — بزرگترین محتوا: چقدر طول می‌کشد اصلیترین محتوای صفحه (بنر، تصویر هدر) ظاهر شود؟ آستانۀ خوب: زیر ۲٫۵ ثانیه.
• INP — پاسخدهی تعامل: وقتی کاربر کلیک یا لمس می‌کند، صفحه چقدر طول می‌کشد واکنش نشان دهد؟ آستانۀ خوب: زیر ۲۰۰ میلیثانیه. این متریک جایگزین «FID» قدیمی شده (FID، سنجش پیشین پاسخ‌دهی، از ۲۰۲۴ بازنشسته شد) و کل زمان پردازش جاوااسکریپت را می‌سنجد.
• CLS — ثبات چیدمان: هنگام بارگذاری، عناصر صفحه چقدر می‌پرند و جابه‌جا می‌شوند؟ آستانۀ خوب: زیر ۰٫۱.

نکتۀ مهم: گوگل این اعداد را از دادهٔ واقعی کاربر (CrUX) می‌خواند، نه فقط از تست؛ بنابراین قضاوت نهایی، رفتار کاربر واقعی است.

قاعدۀ طلایی: اول LCP را درست کنید، بعد INP، در آخر CLS.

از کجا بفهمیم مشکل کجاست

1. PageSpeed Insights: آدرس را وارد کنید؛ گزارش موبایل را جدیتر بگیرید — ایندکس گوگل روی نسخۀ موبایل است.
2. Search Console: بخش Core Web Vitals، URLها را دستهبندی می‌کند: «Poor», «Needs improvement», «Good». اول صفحۀ پولسازِ خراب را درست کنید.
3. Lighthouse در DevTools: برای عیبیابی دقیق؛ ستارۀ Waterfall نشان می‌دهد کدام درخواست وقت را خورده است.

هشت اصلاح با بازدهی اثباتشده

۱. تصاویر: بزرگترین قاتل LCP

هدر سایت را با فرمت مدرن WebP یا AVIF سرو کنید، ابعاد واقعی نمایش را مشخص کنید (width/height)، و تصویر بالای صفحه را با fetchpriority="high" و بدون lazy-load بارگذاری کنید.

lazy-loading روی تصویر LCP، خودش یک خطای رایج است؛ تنبلی فقط برای تصاویر پایین صفحه.

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

۲. کش مرورگر و CDN

آستانۀ Cache-Control مناسب برای فایلهای استاتیک (حداقل چند ماه) و استفاده از CDN نزدیک مخاطب ایرانی، زمان بارگذاری دوم را دراماتیک کم می‌کند.

برای هاستینگ داخل ایران، سرویسهای کش و فشردهسازی سمت سرور را فعال نگه دارید.

۳. جاوااسکریپت: کم، تاخیری، و به‌جا

هر پلاگین، چت، آنالیتیکس و اسکریپت بازاریابی اضافه، INP را می‌خورد.

سه قانون: اسکریپت غیرضروری را حذف کنید، بقیه را defer/async بارگذاری کنید، و تگ مدیریت (مثل GTM) را سبک نگه دارید. فونت فارسی را بهینه سرو کنید: حداکثر دو وزن، فرمت woff2، و font-display: swap.

۴. HTML اولیه و رندر سمت سرور

صفحه باید پیش از اجرای جاوااسکریپت، محتوای اصلی را نشان دهد؛ بنابراین برای صفحات مهم، SSR یا حداقل prerender، LCP را نجات می‌دهد.

۵. جای خالی رزرو کنید: درمان CLS

برای بنر تبلیغاتی، جایگاه تصویر و المانهای داینامیک، ارتفاع مشخص بگذارید تا صفحه هنگام بار بپرد.

پرش ناگهانی دکمۀ «افزودن به سبد» زیر انگشت کاربر، بدترین تجربۀ ممکن است — و دقیقاً همان چیزی که CLS تنبیه می‌کند.

۶. فشردهسازی و HTTP/2

Brotli یا Gzip فعال، CSS/JS ادغامشده و مینیفایشده، و حذف فایلهای بلاککنندۀ رندر. در CMSهای آماده، افزونۀ بهینۀ معتبر معمولاً همینها را یکجا انجام می‌دهد.

۷. موبایل را اول بسنجید

ترافیک موبایل در ایران بخشِ بیشترِ کل است (رویۀ رایج صنعت؛ بدون آمار رسمیِ خودِ ما)؛ پس اگر با انگشت روی موبایل تست نکردهاید، بهینۀ واقعی نکردهاید.

۸. فونت فارسی را سبک کنید

فونت فارسی کامل با همهٔ وزنها چند صد کیلوبایت حجم دارد. فقط وزنهای استفادهشده را بارگذاری کنید.

از زیرمجموعهسازی (subset) هم استفاده کنید.

میزبانی را روی دامنهٔ خودتان با کش بلندمدت بگذارید؛ همین یک تغییر، LCP را در سایتهای فونتمحور پایین می‌آورد.

سرعت سایت، مستقیم روی جیب شما

هر یک‌ثانیه تأخیر می‌تواند ریزش مشتری را محسوس بالا ببرد (بازۀ مشهور صنعت؛ تقریبی، نه تضمین)؛ این یعنی سرعت سایت پروژۀ فروش است، نه کار فنی آرایشگاهی.

وقتی LCP بهتر شد، نرخ پرش پایین می‌آید و سیگنالهای رفتاری که در مقالۀ کلیدواژه دنبالهبلند به آنها اشاره کردیم تقویت می‌شوند؛ چون کاربرِ مانده، کاربرِ خریدار است.

چکلیست انتشار: قبل از هر آپدیت بزرگ

این چکلیست را به فرآیند انتشار محتوا وصل کنید.

امتیاز سئوی هر مقالۀ جدید را پیش از انتشار بسنجید تا سرعت و کیفیت قربانی عجله نشود؛ منطق آن در مقالۀ امتیاز سئو پیش از انتشار توضیح داده شده است.

سرعت سایت و سئوی محلی

کسبوکار محلی دو امتیاز می‌گیرد: سرعت سایت خوب، صفحۀ شهرِ کامل.

کاربر «تعمیرکار پکیج نزدیک من» روی موبایل و با عجله جستوجو می‌کند؛ سرعت پایین یعنی از دست دادن تماسی که پولش قطعی بود. ترکیب این دو در راهنمای سئوی محلی باز شده است.

روتین هفتگی: پنج دقیقه در هفته

سرعت، پروژۀ یکباره نیست؛ باغچه است. روتین هفتگی: یک بار PageSpeed روی سه صفحۀ پولساز (هوم، محصول پرفروش، مقالۀ ارگانیک برتر) و نگاهی به کُندترین URLها در Search Console.

ماهانه افزونهها و قالب را بهروز کنید و بعد از هر آپدیت همین سه عدد را مقایسه کنید؛ بیشتر فاجعههای سرعت، روزِ آپدیت اتفاق می‌افتد.

سرعت سایت: تعمیر سریع یا بازسازی؟

سایتهای قدیمی با ده افزونۀ رویهمانباشته اغلب در «تعمیر» جا می‌زنند.

نشانۀ بازسازی: LCP بالای ۵ ثانیه با وجود بهینه‌سازی تصویر، قالبی که آخرین آپدیتش دو سال پیش بوده، و پوستهای که هر صفحه ۱۲۰ درخواست می‌زند.

در این حالت، مهاجرت به قالب سبکتر ارزانتر از مرگ تدریجی رتبههاست.

مستندات رسمی تعریف متریکها و آستانهها را گوگل در Web.dev منتشر کرده و مرجع همیشگی عددهاست؛ بخش Core Web Vitals در Web.dev را به تیم فنی بدهید تا با همزبان رسمی صحبت کنید.

پرسشهای پرتکرار

امتیاز ۱۰۰ در PageSpeed لازم است؟

نه. امتیاز آزمایشگاهی عدد نسبی است؛ هدف سبز بودن سه متریک در دادهٔ واقعی (CrUX) است. سایتی با امتیاز ۷۵ که LCPاش ۲ ثانیه است، از سایت ۱۰۰ِ بدون ترافیک بهتر است.

کیفیت هاست علت کندی است؟

می‌تواند باشد، ولی معمولاً نه تنها علت. اول تصویر و اسکریپت را درست کنید؛ اگر باز هم TTFB بالای ۶۰۰ میلیثانیه ماند، سراغ هاست و CDN بروید.

افزونۀ کش کافی است؟

برای شروع بله، اما افزونۀ کش بدون بهینۀ تصویر و فونت، نیمۀ راه است. ترتیب: تصویر → فونت → اسکریپت → کش → CDN.

چقدر طول می‌کشد اثرش در رتبه دیده شود؟

دادهٔ CrUX ماهانه بهروز می‌شود و گوگل هم برای بازطبقهبندی زمان لازم دارد؛ ۴ تا ۸ هفته بازۀ واقعبینانه برای قضاوت است.

سخن آخر

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

سه متریک را بشناسید، هشت اصلاح را به ترتیب اجرا کنید، و ماهانه با دادهٔ واقعی بسنجید؛ سایت سریع، خودش رتبه می‌خرد.

نویسنده: تیم محتوای AdMetrix — برای انتشار همزمان در وبلاگ و پیامرسانها، از داشبورد AdMetrix استفاده کنید.