اگر سایت قبلاً سریع بوده و حالا باز شدن صفحه محصول یا نوشته چند ثانیه طول می‌کشد، اولین سؤال «کدام افزونه Cache نصب کنم؟» نیست. باید مشخص شود زمان در مرورگر، شبکه، تولید HTML، دیتابیس یا سرویس ثالث مصرف می‌شود. بدون این تفکیک ممکن است تصاویر را فشرده کنید، در حالی که PHP پنج ثانیه منتظر query است.
پاسخ سریع: یک URL ثابت را در حالت ناشناس چند بار اندازه بگیرید، TTFB را از زمان دانلود منابع جدا کنید و همان صفحه را در حالت cache hit و miss مقایسه کنید. سپس لاگ‌ها، queryها و منابع CPU/RAM/disk را دقیقاً در زمان کندی بررسی کنید. فقط یک عامل را در هر مرحله تغییر دهید.
کندی دقیقاً کجا دیده می‌شود؟
- همه صفحات یا فقط یک نوع صفحه مثل محصول و جستجو؟
- فقط کاربران واردشده یا بازدیدکنندگان ناشناس؟
- همیشه یا فقط ساعت پرترافیک و هنگام اجرای cron؟
- HTML دیر می‌رسد یا صفحه بعد از دریافت HTML دیر کامل می‌شود؟
- فقط موبایل/یک ISP یا از چند شبکه و location؟
- پیشخوان هم کند است یا فقط سایت عمومی؟
یک اندازه‌گیری منفرد از لپ‌تاپ شما نتیجه قطعی نیست. URL، زمان، وضعیت login، cache status و location آزمون را ثبت کنید تا مقایسه معتبر باشد.
TTFB بالا یا رندر کند مرورگر؟
در DevTools تب Network، درخواست document را ببینید. اگر انتظار برای پاسخ اولیه طولانی است، مسیر CDN، وب‌سرور، PHP و دیتابیس مطرح می‌شود. اگر HTML سریع رسیده ولی Largest Contentful Paint یا تعامل دیر است، تصویر، فونت، CSS، JavaScript و third-party scriptها را بررسی کنید. این دو مشکل ممکن است هم‌زمان باشند، اما ابزار و راه‌حل یکسان ندارند.
عبارت TTFB کل زمان backend خالص نیست؛ DNS، اتصال، TLS، شبکه و cache لبه نیز در آن سهم دارند. برای نزدیک شدن به origin، headerهای timing و log درخواست را با timestamp تطبیق دهید. دور زدن CDN باید فقط به‌صورت کنترل‌شده و بدون افشای origin انجام شود.
علت‌های رایج کندی وردپرس
- افزونه یا قالب: query زیاد، API کند، پردازش تکراری یا asset سنگین.
- دیتابیس: query بدون index، autoload حجیم، جدول‌های بزرگ یا lock.
- PHP: worker اشباع، نسخه/extension ناسازگار، opcode cache یا کد پرمصرف.
- منابع میزبان: CPU throttling، RAM ناکافی، swap یا storage کند.
- Cache نامناسب: hit rate پایین، bypass ناخواسته یا purge مداوم.
- شبکه و سرویس ثالث: DNS، CDN، فونت، تبلیغات، analytics یا API خارجی.
- jobهای پس‌زمینه: wp-cron، backup، scan امنیتی، import و صف ووکامرس.
فرایند تشخیص کم‌ریسک
- قبل از تغییر baseline بگیرید: چند URL، TTFB، حجم و تعداد request.
- زمان کندی را با access log، PHP-FPM و MySQL تطبیق دهید.
- صفحه cacheable و dynamic را جدا مقایسه کنید.
- Site Health و خطاهای PHP را بررسی کنید، اما امتیاز ابزار را جای نتیجه واقعی نگذارید.
- در staging، افزونه یا قابلیت مظنون را isolate کنید.
- بعد از هر تغییر همان workload را تکرار و نتیجه را ثبت کنید.
اگر فقط wp-admin کند است، تصویر hero یا lazy-load احتمالاً علت اصلی نیست. مسیر اختصاصی تشخیص کندی پیشخوان وردپرس را دنبال کنید.
بررسی افزونه و قالب بدون خراب کردن production
غیرفعال کردن همه افزونه‌ها روی سایت زنده ممکن است checkout، فرم و jobها را متوقف کند. clone یا staging با داده پاک‌سازی‌شده بسازید، سناریوی کند را بازتولید کنید و افزونه‌ها را گروهی و سپس تکی isolate کنید. Query Monitor در محیط کنترل‌شده می‌تواند hook، query و HTTP call را نشان دهد؛ فعال ماندن ابزار profiler سنگین روی production مناسب نیست.
اگر کندی بعد از update شروع شده، نسخه‌های قبل و بعد و cache warm بودن را مقایسه کنید. rollback بدون backup و بدون توجه به migration دیتابیس خطر دارد. برای خطاهای پس از update، لاگ و مسیر بازگشت رسمی افزونه را بررسی کنید.
دیتابیس چه زمانی مظنون است؟
صفحات جستجو، فیلتر، حساب کاربری و گزارش‌ها معمولاً queryهای dynamic بیشتری دارند. تعداد query به تنهایی معیار کافی نیست؛ یک query کند می‌تواند از صد query کوچک بدتر باشد. slow query log، plan، rowهای بررسی‌شده و فراوانی اجرا را کنار هم ببینید. قبل از حذف transient، revision یا جدول، backup و نقش داده را مشخص کنید.
پیام‌های MySQL یا lock را با راهنمای تشخیص خطاهای MySQL وردپرس بررسی کنید. optimize کورکورانه درمان هر نوع کندی نیست و هنگام کمبود disk می‌تواند ریسک ایجاد کند.
CPU، RAM و disk را هم‌زمان ببینید
CPU بالا ممکن است معلول ترافیک، bot، PHP loop یا query باشد. RAM آزاد کم روی Linux به‌تنهایی بد نیست چون cache سیستم مفید است؛ swap شدید، OOM و restart سرویس مهم‌ترند. storage با latency بالا نیز PHP و دیتابیس را منتظر می‌گذارد، حتی اگر درصد CPU پایین باشد.
uptime
top
free -h
df -hاین فرمان‌ها read-only هستند، اما snapshot یک لحظه را نشان می‌دهند. خروجی را در زمان مشکل بگیرید و اطلاعات فرایندها یا مسیرهای حساس را پیش از اشتراک پاک کنید. برای CPU وردپرس، راهنمای مصرف بالای CPU جزئیات بیشتری دارد.
از راه‌حل ساده تا پیشرفته
بهبودهای کم‌ریسک
تصاویر را متناسب با محل نمایش تولید کنید، assetهای بلااستفاده را کاهش دهید، افزونه‌های واقعاً غیرضروری را پس از بررسی حذف و cache موجود را درست پیکربندی کنید. قبل و بعد هر تغییر اندازه بگیرید.
اصلاح backend
query یا API کند را اصلاح کنید، cronهای سنگین را زمان‌بندی و batch کنید و hit rate cache را بالا ببرید. object cache فقط برای workload مناسب و با invalidation درست مفید است.
اصلاح زیرساخت
workerهای PHP، timeout و منابع را بر اساس concurrency واقعی تنظیم کنید. ارتقا به VPS وقتی مفید است که محدودیت هاست اثبات شده و تیم توان مدیریت امنیت، backup و مانیتورینگ آن را داشته باشد.
اشتباه‌های رایج
- نصب هم‌زمان چند افزونه cache و minify
- قضاوت فقط بر اساس یک نمره آزمایشگاهی
- پاک کردن دیتابیس بدون backup و شناخت داده
- افزایش بی‌حساب PHP worker و memory limit
- بهینه‌سازی frontend برای مشکل backend
- نادیده گرفتن کاربران واردشده و checkout در تست cache
چه زمانی بررسی حرفه‌ای ارزش دارد؟
اگر زمان پاسخ متناوب است، فقط زیر بار رخ می‌دهد یا چند لایه CDN، PHP و دیتابیس درگیرند، تغییرات حدسی می‌تواند قطعی بسازد. سرویس افزایش سرعت وردپرس می‌تواند bottleneck را اندازه‌گیری کند و اصلاح را با معیار قبل و بعد پیش ببرد.
پرسش‌های متداول
آیا افزونه Cache سایت کند را سریع می‌کند؟
برای صفحات cacheable ممکن است، اما query کند، wp-admin، checkout و API خراب را الزاماً حل نمی‌کند.
آیا تعداد زیاد افزونه همیشه علت است؟
خیر. کیفیت و رفتار افزونه مهم‌تر از تعداد خام است؛ یک افزونه می‌تواند bottleneck اصلی باشد.
آیا نمره ۱۰۰ هدف مناسبی است؟
تجربه واقعی کاربر و مسیرهای تجاری مهم‌ترند. نمره ابزار یک سیگنال است، نه قرارداد عملکرد.