سرعت سایت را چطور بسنجیم و گزارش را بخوانیم؟
۴ دقیقه مطالعهبروزرسانی:
یک عدد «نمره‌ی سرعت» به‌تنهایی کار زیادی برای شما نمی‌کند. چیزی که لازم دارید این است که بدانید کند بودن از کجاست و کدام کار بیشترین اثر را دارد. این راهنما نشان می‌دهد چطور سرعت را بسنجید، گزارش را بخوانید و کارها را اولویت‌بندی کنید.
اول بدانیم چه چیزی را می‌سنجیم
دو نوع داده درباره‌ی سرعت وجود دارد و بسیاری از سردرگمی‌ها از اختلاط آن‌ها می‌آید:
- داده‌ی آزمایشگاهی (Lab): یک ابزار مثل Lighthouse صفحه را در شرایط ثابت و شبیه‌سازی‌شده باز می‌کند. تکرارپذیر است و برای پیدا کردن مشکل عالی است، ولی تجربه‌ی همه‌ی کاربران نیست.
- داده‌ی میدانی (Field): اندازه‌گیری از کاربران واقعی (مثلاً گزارش Core Web Vitals در Search Console). واقعی است، ولی دلیل مشکل را نمی‌گوید و برای سایت‌های کم‌بازدید ممکن است وجود نداشته باشد.
برای بهبود سایت از داده‌ی آزمایشگاهی شروع می‌کنیم و برای اطمینان از اثر واقعی، داده‌ی میدانی را کنترل می‌کنیم.
گام ۱: یک اندازه‌گیری پایه بگیرید
- آدرس صفحه‌ی مهم (صفحه‌ی اصلی یا پرفروش‌ترین صفحه) را در واکاوی سایت وارد کنید.
- حالت موبایل را انتخاب کنید؛ سخت‌گیرانه‌تر است و گوگل نسخه‌ی موبایل را مبنا می‌گیرد.
- نتیجه را ذخیره کنید (عدد‌ها و مشکل‌های اصلی)؛ بعداً برای مقایسه لازم است.
گام ۲: چهار نمره را بشناسید
| نمره | چه چیزی را می‌سنجد | برای چه کسی مهم است؟ |
|---|---|---|
| عملکرد | سرعت و روانی بارگذاری | کاربر و رتبه‌بندی |
| دسترس‌پذیری | قابل‌استفاده بودن برای همه، از جمله کم‌بینایان | کاربر و الزام‌های قانونی بعضی بازارها |
| بهترین‌روش‌ها | امنیت، HTTPS و خطاهای فنی | امنیت و کیفیت |
| سئو | پایه‌های فنی دیده شدن در جست‌وجو | موتورهای جست‌وجو |
نمره‌ی بالای «سئو» در Lighthouse یعنی پایه‌ها سالم است، نه اینکه رتبه‌ی خوبی دارید. بعد از عملکرد، همین سه نمره را هم نگاه کنید؛ واکاوی ما برای مشکل‌های آن‌ها هم نمونه‌ی عنصر مشکل‌دار و راه‌حل می‌دهد.
گام ۳: معیارهای عملکرد را بخوانید
| معیار | یعنی چه | خوب |
|---|---|---|
| TTFB | سرعت پاسخ‌دادن سرور | حدود ۰٫۸ ثانیه یا کمتر |
| FCP | اولین نمایش محتوا | تا ۱٫۸ ثانیه |
| LCP | نمایش محتوای اصلی | تا ۲٫۵ ثانیه |
| TBT | مدت مشغول بودن مرورگر با جاوااسکریپت (نماینده‌ی پاسخ‌گویی) | هر چه کمتر، بهتر |
| CLS | جابه‌جایی ناگهانی محتوا | تا ۰٫۱ |
این معیارها زنجیره‌ای‌اند: اگر TTFB بد باشد، FCP و LCP هم بد می‌شوند. پس از ابتدای زنجیره شروع کنید.
گام ۴: اولویت‌بندی کنید
گزارش ما «فرصت‌های بهبود» را بر اساس بیشترین صرفه‌جویی تخمینی مرتب می‌کند. یک قاعده‌ی عملی:
- اگر TTFB بالا است، اول سرور: کش صفحه، هاست، ریدایرکت‌های اضافه.
- اگر LCP بالا است، ببینید عنصر LCP تصویر است یا متن. تصویر را فشرده و به WebP تبدیل کنید و lazy نکنید؛ اگر متن است، سراغ فونت و CSS بروید.
- اگر TBT بالا است، جاوااسکریپت: اسکریپت‌های بی‌استفاده و شخص ثالث (تبلیغ، ردیاب) را کم کنید.
- اگر CLS بالا است، برای تصویر و تبلیغ جا رزرو کنید.
چند اشتباه رایج
- دنبال نمره‌ی ۱۰۰ بودن. بعد از یک نقطه، هزینه‌ی بهبود از فایده‌اش بیشتر می‌شود. هدف تجربه‌ی خوب است.
- مقایسه‌ی ابزارها با هم. هر ابزار سخت‌افزار و شبکه‌ی خودش را دارد؛ عدد‌ها فرق می‌کنند. با یک ابزار و شرایط ثابت مقایسه کنید.
- تست فقط صفحه‌ی اصلی. صفحه‌ی محصول و مقاله معمولاً سنگین‌ترند.
- نادیده گرفتن موبایل. بیشتر بازدیدها از موبایل است و موبایل ضعیف‌تر از دسکتاپ نتیجه می‌دهد.
بعد از رفع مشکل چه کنیم؟
دوباره اندازه بگیرید و با اندازه‌ی پایه مقایسه کنید. برای اینکه یک به‌روزرسانی بعدی سایت را ناخواسته کند نکند، صفحه‌های مهم را در پایش سرعت بگذارید تا روند امتیاز خودکار ثبت شود.
با ابزار امتحان کنید
سؤالات متداول
چرا نمره‌ی سایت من در دو ابزار فرق دارد؟
چون هر ابزار پردازنده، شبکه و مکان آزمایش متفاوتی دارد. تفاوت چند امتیازی طبیعی است؛ روند و مشکل‌های اصلی مهم‌ترند.
نمره‌ی موبایل خیلی پایین‌تر از دسکتاپ است. مشکل از چیست؟
در موبایل پردازنده و اینترنت کندتری شبیه‌سازی می‌شود؛ جاوااسکریپت سنگین و تصویر بزرگ بیشتر اثر می‌گذارد. این تفاوت نشانه‌ی مشکل واقعی است، نه خطای ابزار.
سرعت سایت دقیقاً چقدر روی سئو اثر دارد؟
سرعت یکی از چند سیگنال تجربه‌ی صفحه است و مهم‌تر از آن، روی ماندن کاربر و تبدیل اثر مستقیم دارد. سایت کند با محتوای عالی هم می‌تواند رتبه بگیرد، ولی کاربر را از دست می‌دهد.