چرا سایتم کند است؟ عیب‌یابی گام‌به‌گام کندی سایت از سرور تا CDN

کندی سایت از کجا می‌آید؟

وقتی کسی آدرس سایت شما را باز می‌کند، چند مرحله پشت سر هم اتفاق می‌افتد: پیدا کردن آی‌پی از DNS، برقراری اتصال و دست‌دهی TLS، پردازش درخواست روی سرور، ارسال HTML و در نهایت دانلود تصاویر، فونت‌ها و اسکریپت‌ها و اجرای آن‌ها در مرورگر. کندی در هرکدام از این مراحل، کل سایت را کند نشان می‌دهد.

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

قدم اول: اندازه‌گیری زمان پاسخ با curl

ابزار curl می‌تواند زمان هر مرحله را جداگانه نشان دهد. این دستور را از کامپیوتر خودتان (یا از یک سرور دیگر) اجرا کنید:

curl -o /dev/null -s -w "dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/

خروجی به ثانیه است و هر عدد زمان تجمعی از شروع درخواست تا پایان آن مرحله را نشان می‌دهد:

• dns: زمان پیدا کردن آی‌پی. اگر این عدد به‌طور محسوس بالاست، مشکل از سرویس DNS است.
• connect و tls: زمان برقراری اتصال و دست‌دهی امن. اختلاف زیاد این دو با dns نشان‌دهندهٔ فاصلهٔ زیاد شبکه‌ای یا شبکهٔ پرتلفات است.
• ttfb: زمان رسیدن اولین بایت پاسخ. اختلاف ttfb با tls تقریباً همان زمانی است که سرور صرف ساختن صفحه کرده است.
• total: کل زمان دریافت HTML.

این دستور را چند بار تکرار کنید و میانگین بگیرید. برای مقایسه، همین دستور را روی یک فایل ثابت مثل /robots.txt یا یک تصویر هم اجرا کنید. اگر فایل ثابت سریع است اما صفحهٔ اصلی کند، تقریباً مطمئن باشید مشکل در پردازش سمت سرور (PHP، دیتابیس یا کد برنامه) است.

قدم دوم: بررسی منابع سرور

اگر ttfb بالاست، به سرور وصل شوید و ببینید منابع در چه وضعی هستند. دستور htop یا top تصویر کلی می‌دهد:

uptime
free -h
df -h
top -o %CPU

به این موارد دقت کنید:

• Load average بیشتر از تعداد هسته‌ها برای مدت طولانی یعنی پردازنده زیر فشار است. راهنمای کامل در مقالهٔ مصرف بالای CPU در لینوکس آمده است.
• رم آزاد کم و Swap پر: وقتی سیستم مجبور شود از دیسک به‌جای رم استفاده کند، همه‌چیز به‌شدت کند می‌شود. مقالهٔ کمبود حافظه و Out of Memory را ببینید.
• دیسک پر یا کند: ستون wa در top نشان می‌دهد پردازنده چقدر منتظر دیسک مانده است. اگر این عدد بالا باشد، گلوگاه دیسک است.

برای تشخیص سریع‌تر، آموزش بررسی مصرف CPU و رم ابزارهای بیشتری معرفی می‌کند.

$ curl -o /dev/null -s -w 'ttfb: %{time_starttransfer}\n' https://example.com/ttfb: ...$ curl -o /dev/null -s -w 'ttfb: %{time_starttransfer}\n' https://example.com/robots.txtttfb: ...$ uptime ... load average: ..., ..., ...$ free -hMem:  total  used  free  shared  buff/cache  available$ 

قدم سوم: دیتابیس و کد برنامه

بیشتر سایت‌های پویا (وردپرس، لاراول، فروشگاه‌ها) در هر بازدید چندین کوئری دیتابیس اجرا می‌کنند. یک کوئری بدون ایندکس روی جدولی بزرگ می‌تواند به‌تنهایی صفحه را کند کند.

در MySQL و MariaDB لاگ کوئری‌های کند را فعال کنید:

sudo mysql -e "SET GLOBAL slow_query_log=1; SET GLOBAL long_query_time=1;"
sudo tail -f /var/lib/mysql/*-slow.log

پس از چند دقیقه بازدید از سایت، کوئری‌هایی که بیش از یک ثانیه طول کشیده‌اند در لاگ ظاهر می‌شوند. معمولاً با افزودن ایندکس مناسب یا حذف افزونه‌ای که کوئری سنگین می‌زند، مشکل حل می‌شود.

اگر از PHP-FPM استفاده می‌کنید، لاگ آن را هم بررسی کنید. پیغام server reached pm.max_children یعنی همهٔ پردازش‌های PHP مشغول‌اند و درخواست‌های جدید در صف می‌مانند. افزایش این مقدار فقط وقتی کمک می‌کند که رم کافی داشته باشید؛ هر پردازهٔ PHP مقداری رم مصرف می‌کند.

افزونه‌ها و درخواست‌های خارجی

در سایت‌های ایرانی یک علت رایج و پنهان کندی، درخواست‌هایی است که کد سایت به سرویس‌های خارجی می‌فرستد؛ مثل بررسی به‌روزرسانی افزونه‌ها، فونت‌های گوگل یا اسکریپت‌های آماری. اگر سرور به آن سرویس دسترسی نداشته باشد، هر درخواست تا پایان مهلت انتظار (Timeout) منتظر می‌ماند و صفحه چند ثانیه دیرتر بارگذاری می‌شود. با بررسی لاگ خطای PHP یا غیرفعال کردن موقت افزونه‌ها، مقصر را پیدا کنید.

قدم چهارم: سنگینی صفحه در مرورگر

اگر ttfb خوب است اما صفحه دیر کامل می‌شود، مشکل در منابعی است که مرورگر باید دانلود کند. در Chrome کلید F12 را بزنید، تب Network را باز کنید و صفحه را با Ctrl+Shift+R دوباره بارگذاری کنید. ستون Size و Time نشان می‌دهد کدام فایل‌ها بزرگ یا کندند.

راه‌حل‌های رایج:

1. فشرده‌سازی تصاویر: تصاویر را به فرمت WebP یا AVIF تبدیل کنید و ابعاد را به اندازهٔ نمایش واقعی کوچک کنید.
2. فشرده‌سازی متنی: Gzip یا Brotli را روی وب‌سرور فعال کنید؛ آموزش آن در فعال‌سازی Gzip و Brotli در Nginx آمده است.
3. بارگذاری تنبل (Lazy Load): تصاویر پایین صفحه فقط وقتی کاربر به آن‌ها می‌رسد دانلود شوند.
4. حذف اسکریپت‌های بی‌استفاده: هر اسکریپت اضافه زمان دانلود و اجرا دارد.

قدم پنجم: کش و CDN

کش یعنی نگه‌داشتن نتیجهٔ آماده تا دفعهٔ بعد دوباره ساخته نشود. سه لایهٔ کش داریم: کش مرورگر کاربر، کش CDN در لبهٔ شبکه و کش سمت سرور (مثل کش صفحه یا Redis). مفاهیم پایه را در مقالهٔ کش چیست؟ ببینید.

یک CDN فایل‌های ثابت را از نزدیک‌ترین نقطه به کاربر تحویل می‌دهد و بار سرور اصلی را کم می‌کند. اما CDN جادو نمی‌کند: اگر صفحهٔ HTML شما برای ساخته شدن چند ثانیه وقت لازم دارد و قابل کش نیست، CDN آن چند ثانیه را حذف نمی‌کند. ترتیب درست این است که اول مشکل سرور را حل کنید و بعد CDN را برای سرعت و پایداری بیشتر اضافه کنید. تنظیم درست هدرهای کش در مقالهٔ قوانین Cache-Control در CDN توضیح داده شده است.

چه زمانی باید سرور را ارتقا داد؟

ارتقای منابع وقتی منطقی است که اندازه‌گیری نشان دهد منابع واقعاً تمام می‌شوند: CPU به‌طور مداوم پر است، رم کم می‌آید و Swap فعال است، یا تعداد بازدیدکنندگان واقعاً افزایش یافته است. اگر مصرف منابع پایین است اما سایت کند است، ارتقا کمکی نمی‌کند و باید سراغ کد، دیتابیس یا شبکه بروید.

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

چک‌لیست خلاصه

• ttfb را با curl از بیرون اندازه بگیرید و با یک فایل ثابت مقایسه کنید.
• منابع سرور (CPU، رم، دیسک) را در زمان کندی بررسی کنید، نه در زمان آرامش.
• لاگ کوئری‌های کند و لاگ PHP-FPM را فعال و مرور کنید.
• درخواست‌های خارجی کد را پیدا و حذف کنید.
• تصاویر و فایل‌های متنی را فشرده کنید.
• کش سمت سرور و CDN را درست پیکربندی کنید.
• فقط بعد از همهٔ این‌ها، تصمیم به ارتقای سرور بگیرید.

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

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