سرعت سایت اولین چیزی است که بازدیدکننده پیش از دیدن محتوا تجربه میکند؛ اگر صفحه دیر بالا بیاید یا حین بارگذاری جابهجا شود، خیلیها پیش از خواندن حتی یک خط برمیگردند. در این راهنما میبینیم چرا یک سایت کند میشود، سرعت را دقیقاً با چه ابزار و معیاری بسنجید و به چه ترتیبی مشکل را رفع کنید تا وقت و بودجهتان صرف کارهای کماثر نشود.
چرا سرعت سایت مهم است؟ فراتر از رتبه در گوگل
سرعت فقط یک عدد در گزارشهای فنی نیست:
- تجربهٔ کاربر: بیشتر بازدیدهای سایتهای ایرانی از موبایل و روی اینترنت همراهی است که کیفیتش همیشه ثابت نیست. صفحهای که روی وایفای دفتر سریع است، ممکن است روی موبایل مشتری کند باشد.
- فروش و سرنخ: فرم تماسی که دیر بارگذاری شود یا دکمهٔ خریدی که زیر انگشت کاربر جابهجا شود، مستقیم به از دست رفتن مشتری منجر میشود.
- سئو: گوگل تجربهٔ صفحه، از جمله شاخصهای Core Web Vitals، را در کنار عوامل دیگر در نظر میگیرد. البته سرعت بهتنهایی رتبه نمیآورد و مرتبطبودن و کیفیت محتوا وزن بیشتری دارد؛ اما وقتی دو صفحه از نظر محتوا نزدیکاند، تجربهٔ بهتر میتواند تفاوت ایجاد کند. اگر روی سئوی سایت کار میکنید، سرعت یکی از پایههای خدمات سئو و بهینهسازی فنی سایت است.
- هزینهٔ تبلیغات: در تبلیغات کلیکی، کیفیت صفحهٔ فرود روی ارزیابی تبلیغ اثر دارد. پولی که برای کلیک میدهید، اگر کاربر پیش از بارگذاری صفحه برگردد، عملاً هدر رفته است.
چرا سایت کند است؟ شش مقصر اصلی
پیش از هر اقدامی باید بدانید مشکل از کجاست. تقریباً همهٔ سایتهای کند، یک یا چند مورد از این فهرست را دارند.
۱. هاست ضعیف یا نامتناسب
اگر سرور برای ساختن صفحه زمان زیادی صرف کند، هیچ بهینهسازی دیگری جبرانش نمیکند. این زمان را با شاخص TTFB (زمان رسیدن اولین بایت) میبینید. علتهای رایج: هاست اشتراکی شلوغ، نسخهٔ قدیمی PHP، منابع ناکافی برای سایتهای سنگین مثل فروشگاهها و فاصلهٔ جغرافیایی سرور با مخاطب. برای سایتی که مخاطبش در ایران است، محل سرور و کیفیت ارتباط آن با شبکهٔ داخلی اهمیت زیادی دارد.
۲. تصاویر سنگین و بدون بهینهسازی
رایجترین مقصر همین است: عکسی که مستقیم از دوربین یا طراح آمده و با ابعاد چند هزار پیکسلی در کادری کوچک نمایش داده میشود. تصویر بزرگ صفحهٔ اول (معمولاً بنر یا اسلایدر) اغلب همان عنصری است که شاخص LCP را خراب میکند.
۳. افزونهها و اسکریپتهای زیاد
هر افزونه یا کتابخانهای که اضافه میکنید ممکن است فایل CSS و JavaScript خودش را در همهٔ صفحات بارگذاری کند، حتی صفحاتی که به آن نیازی ندارند. مشکل تعداد افزونهها بهتنهایی نیست؛ یک افزونهٔ بد نوشتهشده میتواند از ده افزونهٔ سبک کندتر باشد.
۴. نبود کش
بدون کش، سرور برای هر بازدید صفحه را از صفر میسازد: کوئری به دیتابیس، اجرای کد و تولید HTML. کش صفحه نتیجه را ذخیره میکند و به بازدیدکنندهٔ بعدی تحویل میدهد. کش مرورگر هم باعث میشود فایلهای ثابت مثل لوگو، فونت و CSS در بازدید بعدی دوباره دانلود نشوند.
۵. فونتهای سنگین یا بد بارگذاریشده
سایتهای فارسی معمولاً یک یا چند فونت سفارشی دارند. بارگذاری همهٔ وزنهای یک فونت (نازک، معمولی، متوسط، ضخیم، سیاه) در حالی که فقط دو وزن استفاده میشود، یا بارگذاری فونت از سرویس خارجی، هم زمان بارگذاری را زیاد میکند و هم ممکن است باعث پرش متن هنگام جایگزینی فونت شود.
۶. اسکریپتهای شخص ثالث
ابزار چت آنلاین، کدهای آمار و ردیابی، پیکسل تبلیغاتی، نقشهٔ جاسازیشده، ویدئوی آپارات یا یوتیوب و ویجت شبکههای اجتماعی همه از سرورهای دیگری بارگذاری میشوند که کنترلی روی سرعتشان ندارید. سرویسهایی که سرورشان خارج از ایران است ممکن است از داخل کشور کند یا ناپایدار باشند و بارگذاری بقیهٔ صفحه را هم معطل کنند.
چطور سرعت سایت را اندازه بگیریم؟
«سایت کند است» یک احساس است؛ برای رفع مشکل به عدد نیاز دارید.
PageSpeed Insights: دادهٔ واقعی در برابر دادهٔ آزمایشگاهی
ابزار رایگان PageSpeed Insights گوگل دو نوع داده نشان میدهد که نباید با هم قاطی شوند:
- دادهٔ میدانی (Field Data): تجربهٔ واقعی کاربران کروم در بازهٔ چند هفتهٔ اخیر. فقط در صورت ترافیک کافی نمایش داده میشود و معیار ارزیابی گوگل همین است.
- دادهٔ آزمایشگاهی (Lab Data): نتیجهٔ یک آزمایش شبیهسازیشده با Lighthouse در همان لحظه. نمرهٔ صفر تا صد مربوط به همین بخش است و برای پیدا کردن علت مشکل مفید است، اما از یک اجرا تا اجرای بعد کمی نوسان دارد.
اگر دادهٔ میدانی شما خوب است، نمرهٔ آزمایشگاهی متوسط جای نگرانی جدی ندارد.
Core Web Vitals به زبان ساده
گوگل سه شاخص را بهعنوان «شاخصهای حیاتی وب» تعریف کرده است. هر شاخص در صدک ۷۵ام بازدیدها سنجیده میشود؛ یعنی دستکم سهچهارم بازدیدها باید در محدودهٔ «خوب» باشند.
| شاخص | چه چیزی را میسنجد؟ | خوب | نیازمند بهبود | ضعیف |
|---|---|---|---|---|
| LCP | زمان نمایش بزرگترین بخش محتوای قابل مشاهده (معمولاً تصویر اصلی یا تیتر) | تا ۲٫۵ ثانیه | ۲٫۵ تا ۴ ثانیه | بیش از ۴ ثانیه |
| INP | سرعت واکنش صفحه به کلیک، لمس و تایپ کاربر | تا ۲۰۰ میلیثانیه | ۲۰۰ تا ۵۰۰ میلیثانیه | بیش از ۵۰۰ میلیثانیه |
| CLS | میزان جابهجایی ناخواستهٔ اجزای صفحه هنگام بارگذاری | تا ۰٫۱ | ۰٫۱ تا ۰٫۲۵ | بیش از ۰٫۲۵ |
به زبان ساده: LCP میگوید «کی محتوای اصلی را دیدم؟»، INP میگوید «وقتی دکمه را زدم، صفحه زود واکنش نشان داد؟» و CLS میگوید «وقتی داشتم میخواندم یا کلیک میکردم، چیزی زیر دستم جابهجا شد؟».
چند نکته برای اندازهگیری درست
- نتیجهٔ موبایل را ملاک بگیرید. گوگل نسخهٔ موبایل را مبنای ارزیابی قرار میدهد و مشکلات معمولاً آنجا جدیترند.
- فقط صفحهٔ اصلی را تست نکنید. یک صفحهٔ محصول، یک صفحهٔ دستهبندی و یک مقاله را هم بسنجید؛ قالب هر نوع صفحه متفاوت است.
- هر تست را چند بار تکرار کنید و میانگین بگیرید، مخصوصاً برای نمرهٔ آزمایشگاهی.
- گزارش Core Web Vitals در Google Search Console را ببینید؛ این گزارش صفحات مشابه را گروهبندی میکند و نشان میدهد مشکل در کدام دسته از صفحات است.
- پیش و پس از هر تغییر عدد ثبت کنید تا بدانید کدام اقدام واقعاً اثر داشته است.
افزایش سرعت سایت: فهرست اصلاحات به ترتیب اولویت
منطق اولویتبندی ساده است: اول کارهایی که اثر زیاد و ریسک کم دارند، بعد کارهای پیچیدهتر. جدول زیر یک نقطهٔ شروع عمومی است؛ ترتیب دقیق برای هر سایت به نتیجهٔ اندازهگیری بستگی دارد.
| اقدام | معمولاً روی کدام شاخص اثر دارد؟ | سختی و ریسک |
|---|---|---|
| بهینهسازی تصاویر | LCP | کم |
| فعالسازی کش صفحه و مرورگر | LCP و TTFB | کم تا متوسط |
| ارتقای هاست یا نسخهٔ PHP | TTFB و LCP | متوسط |
| حذف افزونه و اسکریپت اضافه | INP و LCP | متوسط |
| رزرو فضا برای تصاویر و بنرها | CLS | کم |
| بهینهسازی فونت | LCP و CLS | کم تا متوسط |
| بهتعویقانداختن JavaScript غیرضروری | INP و LCP | متوسط تا زیاد |
| استفاده از CDN | LCP | متوسط |
۱. تصاویر را درست کنید
- تصاویر را به فرمتهای سبکتر مثل WebP (یا AVIF، اگر قالب و مرورگرهای مخاطب پشتیبانی کنند) تبدیل کنید.
- ابعاد تصویر را متناسب با کادر نمایش بسازید و برای موبایل نسخهٔ کوچکتر ارائه دهید (ویژگی srcset).
- برای تصاویر پایین صفحه بارگذاری تنبل (lazy loading) فعال کنید، اما تصویر اصلی بالای صفحه را هرگز تنبل بارگذاری نکنید؛ این کار LCP را بدتر میکند. برای همین تصویر میتوانید اولویت بارگذاری را بالا ببرید (fetchpriority).
- اسلایدر چندتصویری بالای صفحه را با یک تصویر ثابت جایگزین کنید.
۲. کش را فعال کنید
کش صفحه، کش مرورگر برای فایلهای ثابت و فشردهسازی (Gzip یا Brotli) را روی سرور فعال کنید. در سایتهای پویا مثل فروشگاه، صفحات سبد خرید و حساب کاربری نباید کش شوند؛ این تنظیم را حتماً بررسی کنید.
۳. سرور را بررسی کنید
اگر TTFB بالاست، مشکل در سرور یا کد است، نه در مرورگر. نسخهٔ PHP را به نسخهٔ پشتیبانیشدهٔ جدیدتر ببرید، منابع هاست را با نیاز سایت مقایسه کنید و اگر هاست اشتراکی دیگر جواب نمیدهد، سراغ سرور مجازی یا پلن بالاتر بروید.
۴. هرچه لازم نیست را حذف کنید
فهرست افزونهها و کدهای شخص ثالث را بنویسید و برای هر کدام بپرسید: «اگر فردا حذفش کنم، چه چیزی خراب میشود؟». کدهای ردیابی قدیمی کمپینهای تمامشده و ابزارهایی که کسی به گزارششان نگاه نمیکند، کاندیدای اول حذفاند.
۵. جابهجایی صفحه را متوقف کنید
برای همهٔ تصاویر، ویدئوها و iframeها عرض و ارتفاع مشخص کنید تا مرورگر فضایشان را از قبل رزرو کند. بنرها و پاپآپهایی که بعد از بارگذاری بالای محتوا اضافه میشوند، از رایجترین علتهای CLS بالا هستند.
۶. فونتها را سبک کنید
فقط وزنهایی از فونت را بارگذاری کنید که واقعاً استفاده میشوند، فونت را روی سرور خودتان میزبانی کنید، از فرمت WOFF2 استفاده کنید و با تنظیم font-display مطمئن شوید متن تا رسیدن فونت نامرئی نمیماند.
۷. JavaScript و CSS را مدیریت کنید
اسکریپتهایی که برای نمایش اولیه لازم نیستند را با defer یا بارگذاری تأخیری اجرا کنید، CSS بدون استفاده را کم کنید و فایلها را فشرده (minify) کنید. این مرحله بیشترین احتمال خرابی ظاهری یا عملکردی را دارد؛ پس از هر تغییر، فرمها، منوی موبایل و فرایند خرید را دستی تست کنید.
نکات اختصاصی برای سایتهای وردپرسی
وردپرس انعطاف زیادی دارد و همین انعطاف، راه کند شدن را هم باز میکند. این موارد در سایتهای وردپرسی بیشترین تکرار را دارند:
- فقط یک افزونهٔ کش نصب کنید. افزونههایی مثل LiteSpeed Cache (اگر وبسرور هاست LiteSpeed باشد)، WP Rocket یا W3 Total Cache هر کدام بهتنهایی کار میکنند؛ نصب همزمان دو افزونهٔ کش یا دو افزونهٔ بهینهسازی معمولاً تداخل و خطا میسازد.
- صفحهسازها را با احتیاط استفاده کنید. صفحهسازهای کشیدنی و رهاکردنی کد و فایل اضافهٔ زیادی تولید میکنند. اگر قالب سایت از پایه روی صفحهساز بنا شده، بهینهسازی سقف محدودتری دارد.
- دیتابیس را تمیز نگه دارید. بازنویسیهای قدیمی نوشتهها (revisions)، دیدگاههای اسپم، دادهٔ موقت منقضیشده (transients) و تنظیمات بهجامانده از افزونههای حذفشده، دیتابیس را سنگین میکنند. تعداد بازنویسیهای ذخیرهشده را هم محدود کنید.
- در ووکامرس مراقب درخواستهای پسزمینه باشید. بهروزرسانی سبد خرید و ویجتهای «محصولات مرتبط» و فیلترهای پیشرفته میتوانند درخواستهای سنگینی به سرور بفرستند. در فروشگاههای بزرگ، کش آبجکت (مثل Redis) روی سرور کمک قابل توجهی میکند.
- قالب و افزونهها را بهروز نگه دارید و پیش از هر تغییر بزرگ، بکاپ بگیرید یا روی نسخهٔ آزمایشی تست کنید.
بسیاری از این کارها بخشی از نگهداری منظم سایت هستند، نه یک پروژهٔ جداگانه؛ فهرست کاملترش را در چکلیست نگهداری سایت وردپرس آوردهایم.
بهینهسازی یکباره کافی است یا پایش مداوم لازم است؟
سرعت سایت ثابت نمیماند. یک بنر جدید با حجم زیاد، افزونهای که برای کمپین نصب شد، کد ردیابی تازه یا بهروزرسانی قالب میتواند نتیجهٔ هفتهها بهینهسازی را در یک روز از بین ببرد. برای جلوگیری از این اتفاق:
- گزارش Core Web Vitals سرچ کنسول را دستکم ماهی یک بار بررسی کنید.
- پیش از انتشار تغییرات بزرگ، صفحات کلیدی را با PageSpeed Insights تست کنید.
- برای آپلود تصاویر در تیم محتوا قاعده بگذارید: حداکثر ابعاد، فرمت و حجم.
- دسترسیپذیری سایت (آپتایم) و زمان پاسخ سرور را با یک ابزار مانیتورینگ زیر نظر بگیرید.
اگر فرصت یا تیم فنی برای این پایش ندارید، میتوانید آن را به یک تیم پشتیبانی بسپارید؛ پایش سرعت، بهروزرسانی و بکاپ منظم بخشی از خدمات پشتیبانی و نگهداری سایت مای طرح است.
اشتباهاتی که بهینهسازی را خراب میکنند
- دنبال نمرهٔ ۱۰۰ بودن: هدف، تجربهٔ خوب کاربر واقعی و قرار گرفتن در محدودهٔ «خوب» Core Web Vitals است. صرف هفتهها برای چند نمرهٔ بیشتر در آزمایشگاه، معمولاً ارزشش را ندارد.
- نصب چند افزونهٔ بهینهسازی همزمان: بهجای جمع شدن اثرها، معمولاً تداخل و خرابی ایجاد میشود.
- فشردهسازی و ترکیب تهاجمی JavaScript بدون تست: نتیجهاش ممکن است فرمی باشد که ارسال نمیشود یا منویی که در موبایل باز نمیشود.
- تست فقط روی دسکتاپ و فقط صفحهٔ اصلی: مشکل واقعی اغلب در صفحات محصول و مقاله روی موبایل است.
سؤالات متداول
سرعت سایت چقدر روی رتبهٔ گوگل اثر دارد؟
گوگل تجربهٔ صفحه را در کنار دهها عامل دیگر در نظر میگیرد، اما کیفیت و مرتبطبودن محتوا اثر بیشتری دارد. سرعت را بیشتر بهعنوان بخشی از تجربهٔ کاربر و نرخ تبدیل ببینید تا یک اهرم مستقیم رتبه.
نمرهٔ PageSpeed من پایین است ولی سایت برایم سریع باز میشود؛ کدام درست است؟
احتمالاً هر دو. شما با اینترنت و دستگاه خودتان و اغلب با فایلهای کششده تست میکنید، در حالی که آزمایش PageSpeed یک موبایل متوسط با اینترنت کندتر را شبیهسازی میکند. ملاک نهایی دادهٔ میدانی کاربران واقعی است؛ اگر هنوز در دسترس نیست، نتیجهٔ آزمایشگاهی موبایل را جدی بگیرید.
آیا استفاده از CDN برای سایت ایرانی مفید است؟
بستگی به مخاطب دارد. اگر بیشتر بازدیدکنندگان در ایران هستند و سرور هم در ایران است، CDN خارجی ممکن است کمکی نکند یا حتی مسیر را طولانیتر کند. اگر مخاطب در چند کشور پخش است یا فایلهای سنگین زیادی دارید، CDN با نقاط حضور مناسب میتواند مفید باشد. پیش و پس از فعالسازی، اندازهگیری کنید.
بهینهسازی سرعت سایت وردپرسی را خودم هم میتوانم انجام دهم؟
بخشهایی مثل فشردهسازی تصاویر، حذف افزونههای بیاستفاده و نصب یک افزونهٔ کش را معمولاً میتوانید خودتان انجام دهید. کارهایی مثل تنظیم سرور، مدیریت JavaScript و بهینهسازی دیتابیس ریسک خرابی دارند و بهتر است با بکاپ و توسط فرد متخصص انجام شوند.
بعد از بهینهسازی، چه زمانی نتیجه در سرچ کنسول دیده میشود؟
دادهٔ میدانی گوگل میانگین چند هفتهٔ اخیر است، پس بهبود بهصورت تدریجی در گزارشها ظاهر میشود. دادهٔ آزمایشگاهی PageSpeed را بلافاصله میتوانید ببینید، اما برای تأیید اصلاحات در گزارش Core Web Vitals باید چند هفته صبر کنید.
سرعت سایت با یک افزونه یا یک ترفند درست نمیشود: اول با PageSpeed Insights و سرچ کنسول مشکل را دقیق پیدا کنید، بعد از کارهای پراثر و کمریسک مثل تصاویر و کش شروع کنید و در نهایت با پایش منظم نگذارید سایت دوباره کند شود. اگر میخواهید وضعیت فعلی سایتتان بررسی شود و فهرست اولویتدار اصلاحات را داشته باشید، از صفحهٔ پشتیبانی و بهینهسازی سایت برای مشاورهٔ رایگان با مای طرح در تماس باشید.
