اگر فروشگاه ووکامرس کند شده، اولین سؤال این نیست که «کدام افزونه Cache نصب کنیم؟»؛ باید مشخص شود کدام مسیر، برای کدام کاربر و از چه زمانی کند است. صفحه محصول عمومی، جست‌وجو، مدیریت سفارش، سبد و Checkout رفتار یکسانی ندارند. ممکن است صفحات عمومی از cache سریع باشند اما ذخیره محصول یا ثبت سفارش به‌دلیل Query، API یا صف PHP چند ثانیه منتظر بماند.
پاسخ سریع: یک سناریوی کند را با URL، نقش کاربر، زمان و status code ثبت کنید. زمان دریافت HTML را از بارگذاری تصویر و JavaScript جدا کنید، سپس PHP، Queryهای دیتابیس، درخواست خارجی، Action Scheduler و محدودیت منابع را در همان بازه بررسی کنید. تغییر هم‌زمان قالب، cache و سرور علت را پنهان می‌کند.
ابتدا دامنه کندی را مشخص کنید
| مسیر کند | فرضیه‌های محتمل | شاهد مناسب |
|---|---|---|
| محصول و دسته عمومی | cache miss، فیلتر، تصویر، script | DevTools، header cache، Query profile |
| جست‌وجو و فیلتر | meta query، index، داده زیاد | Slow log و execution plan |
| wp-admin سفارش‌ها | افزونه گزارش، API، جدول بزرگ | Query Monitor و PHP trace |
| سبد و Checkout | session، shipping، tax، payment API | Network، log ووکامرس و درگاه |
| کل سایت در ساعات مشخص | cron، backup، bot، کمبود CPU/RAM | timeline منابع و access log |
Backend را از Frontend جدا کنید
اگر document دیر می‌رسد، TTFB و backend را بررسی کنید. اگر HTML سریع است ولی صفحه دیر قابل استفاده می‌شود، waterfall، تصاویر، فونت، third-party script و Long Task مهم‌اند. بهینه‌سازی تصویر Query کند Checkout را حل نمی‌کند؛ افزایش PHP worker نیز JavaScript سنگین مرورگر را اصلاح نمی‌کند.
Cache در ووکامرس مرز دارد
صفحات عمومی محصول و دسته می‌توانند page cache شوند، اما سبد، حساب کاربری و Checkout معمولاً شخصی و dynamic هستند. cache عمومی اشتباه ممکن است قیمت، موجودی یا سبد کاربر دیگری را نشان دهد. cookie، زبان، ارز و وضعیت ورود باید در policy لحاظ شوند. نصب چند افزونه cache هم‌زمان purge و bypass را غیرقابل‌پیش‌بینی می‌کند.
افزونه یا قالب کند را چگونه پیدا کنیم؟
روی clone هم‌نسخه و با داده مشابه، Query Monitor یا profiler را فقط برای کاربر مدیر فعال کنید. component، caller، HTTP call و Queryهای تکراری را ثبت کنید. سپس مؤلفه مظنون را کنترل‌شده غیرفعال و همان سناریو را تکرار کنید. روی production افزونه پرداخت، ارسال یا موجودی را بدون maintenance plan خاموش نکنید.
دیتابیس؛ حجم تنها معیار نیست
فروشگاه طبیعی است که سفارش، item، meta و lookup زیادی داشته باشد. مشکل زمانی است که Query پرتکرار scan گسترده، sort پرهزینه یا lock ایجاد کند. Slow Queryهای وردپرس را با شواهد پیدا کنید. index حدسی یا حذف postmeta می‌تواند write را کند و داده سفارش را خراب کند.
Action Scheduler و کارهای پس‌زمینه
پردازش ایمیل، webhook، sync، subscription و افزونه‌های متعدد می‌تواند در صف اجرا شود. تعداد زیاد pending یا failed را با hook، سن قدیمی‌ترین job و علت retry تحلیل کنید. حذف صف فقط عدد را پایین می‌آورد و ممکن است عملیات تجاری را از بین ببرد. backlog اغلب نشانه consumer کند، fatal error یا cron نامطمئن است.
API خارجی و درگاه پرداخت
محاسبه ارسال، مالیات، ضدتقلب، پیامک، ERP و درگاه می‌توانند Checkout یا مدیریت سفارش را منتظر بگذارند. DevTools و log درخواست خروجی، DNS، connect time، timeout و response status را بررسی کنید. verification TLS یا کنترل امنیتی را برای کاهش زمان خاموش نکنید؛ timeout، retry و fallback باید متناسب با idempotency عملیات طراحی شوند.
منابع سرور را در همان بازه ببینید
uptime
free -h
df -h
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | headاین فرمان‌ها وضعیت را می‌خوانند. snapshot کوتاه کافی نیست؛ نمودار CPU، available memory، swap، I/O، PHP queue و MySQL connections را با ترافیک تطبیق دهید. مصرف CPU وردپرس باید به process و request واقعی نسبت داده شود.
ترتیب اصلاح از کم‌ریسک تا پیشرفته
- backup قابل restore و baseline بسازید.
- افزونه‌ها، قالب و PHP را به نسخه پشتیبانی‌شده و آزموده‌شده برسانید.
- job شکست‌خورده، تماس خارجی کند و خطای PHP را اصلاح کنید.
- Query تکراری یا N+1 را در کد مالک رفع کنید.
- cache صفحات عمومی و object cache را با hit rate معتبر تنظیم کنید.
- ظرفیت PHP و دیتابیس را پس از اندازه‌گیری workload اصلاح کنید.
- تغییر schema یا معماری را روی clone و با rollback انجام دهید.
معیار آزمون فروشگاه
- صفحه محصول و دسته با cache سرد و گرم
- جست‌وجو و فیلتر با داده واقعی
- افزودن و حذف کالا از سبد
- Checkout مهمان و کاربر واردشده
- پرداخت آزمایشی و callback کنترل‌شده
- ایمیل، webhook، موجودی و وضعیت سفارش
- ذخیره محصول و مشاهده سفارش در مدیریت
پیش از تست پرداخت از محیط sandbox یا مبلغ و روش کنترل‌شده استفاده کنید و از ایجاد سفارش واقعی ناخواسته جلوگیری کنید.
اشتباه‌های رایج
- نصب چند افزونه بهینه‌سازی روی سایت کند
- cache کردن سبد و Checkout
- حذف سفارش یا meta برای کوچک کردن دیتابیس
- افزایش worker بدون بودجه RAM
- خاموش کردن WAF یا TLS verification
- تست فقط صفحه اصلی و نادیده گرفتن مسیر خرید
- پاک کردن صف Action Scheduler بدون شناخت hook
چگونه از بازگشت کندی جلوگیری کنیم؟
برای صفحه محصول، جست‌وجو و Checkout baseline و alert جدا داشته باشید. deploymentها را با version و timestamp ثبت کنید؛ نرخ خطا، queue age، PHP saturation و latency درگاه را مانیتور کنید. backup و restore را دوره‌ای بیازمایید و افزونه بدون مالک یا هم‌پوشان را وارد مسیر خرید نکنید.
چه زمانی کمک تخصصی لازم است؟
اگر فروشگاه عمومی سریع است اما خرید یا مدیریت سفارش کند است، آزمون بیشتر روی production ممکن است فروش را مختل کند. سرویس پشتیبانی فروشگاه ووکامرس می‌تواند request، Query، صف و API خارجی را در یک timeline تحلیل و اصلاح قابل بازگشت طراحی کند.
پرسش‌های متداول
آیا تعداد زیاد محصول علت قطعی کندی است؟
خیر؛ مدل داده، Query، index، فیلتر و cache تعیین‌کننده‌اند. فروشگاه بزرگ با Query مناسب می‌تواند پایدار باشد.
آیا Redis ووکامرس را سریع می‌کند؟
در workload تکراری ممکن است، اما تماس خارجی، Query بد یا PHP اشباع را خودکار حل نمی‌کند.
آیا تعویض هاست اولین راه‌حل است؟
فقط پس از اثبات محدودیت منابع یا زیرساخت. bottleneck نرم‌افزاری روی سرور بزرگ‌تر نیز باقی می‌ماند.