افزایش سرعت ووکامرس با یک افزونه Cache یا نمره سبز یک ابزار تمام نمی‌شود. صفحه محصول عمومی، جست‌وجو، سبد، Checkout و مدیریت سفارش مسیرهای متفاوتی دارند. ممکن است دسته محصولات از CDN سریع باشد اما افزودن به سبد یا محاسبه ارسال چند ثانیه طول بکشد. برنامه درست از سناریوی واقعی خرید و یک baseline قابل تکرار آغاز می‌شود.
خلاصه عملی: سه مسیر «مشاهده محصول»، «جست‌وجو/فیلتر» و «خرید تا پرداخت» را جدا اندازه بگیرید. زمان backend را از asset مرورگر تفکیک کنید، سپس خطای PHP، Query کند، API خارجی و اشباع منابع را اصلاح کنید. بعد از آن cache، تصویر و ظرفیت را بهینه کنید و درستی قیمت، موجودی و سفارش را معیار پذیرش نگه دارید.
قبل از تغییر، خط مبنا بسازید
برای هر سناریو URL، نوع کاربر، محصول، وضعیت cache، زمان و نسخه deployment را ثبت کنید. یک بار cache سرد و چند بار cache گرم را اندازه بگیرید. میانگین تنها کافی نیست؛ تأخیرهای بدتر و نرخ خطا را نیز ببینید. آزمایش از یک اینترنت یا یک حساب مدیر نماینده همه مشتریان نیست.
| سناریو | شاخص فنی | کنترل صحت |
|---|---|---|
| محصول/دسته | TTFB، LCP و requestها | قیمت و موجودی تازه |
| جست‌وجو/فیلتر | زمان Query و پاسخ | نتایج و facet صحیح |
| سبد | Ajax و session latency | اقلام هر کاربر جدا |
| Checkout | update، ثبت سفارش و gateway | جمع، ارسال و وضعیت سفارش |
| مدیریت | ذخیره محصول/سفارش | sync و داده کامل |
آزمایشگاه را با تجربه کاربر اشتباه نگیرید
ابزارهای آزمایشگاهی برای تکرارپذیری مفیدند، اما مکان تست، سرعت شبکه، توان دستگاه و cache نتیجه را تغییر می‌دهد. داده واقعی کاربران را با حفظ حریم خصوصی به تفکیک نوع صفحه و device بررسی کنید. یک عدد کلی برای کل دامنه نمی‌گوید Checkout مشتری داخل ایران یا فهرست محصولات روی موبایل چگونه عمل می‌کند.
برای مقایسه releaseها، سناریو و شرایط ثابت نگه دارید و timestamp deployment را روی نمودار ثبت کنید. اگر بهبود median با افزایش خطا یا بدتر شدن p95 همراه است، نتیجه قابل قبول نیست. حجم نمونه کم را به ادعای قطعی تبدیل نکنید.
Frontend یا Backend؟
اگر document اصلی دیر می‌رسد، TTFB، PHP، دیتابیس و شبکه origin را بررسی کنید. اگر HTML سریع است ولی صفحه دیر قابل استفاده می‌شود، waterfall، تصویر، فونت، JavaScript و third-partyها مهم‌اند. فشرده‌سازی تصویر، Query کند Checkout را حل نمی‌کند؛ ارتقای CPU نیز اسکریپت سنگین مرورگر را اصلاح نمی‌کند.
تصاویر محصول را متناسب تحویل دهید
ابعاد فایل باید نزدیک محل نمایش باشد و variantهای responsive درست تولید شوند. فرمت مناسب، compression کنترل‌شده و lazy loading برای تصاویر پایین صفحه مفید است. تصویر اصلی بالای صفحه را بی‌دلیل دیر بارگذاری نکنید. حذف گروهی thumbnailها بدون بررسی reference و فرایند بازتولید می‌تواند صفحات قدیمی و variationها را خراب کند.
JavaScript و افزونه‌های ظاهری
اسلایدر، چت، نقشه حرارتی، pixel تبلیغاتی، quick view و فیلتر پویا می‌توانند main thread و شبکه را شلوغ کنند. در DevTools درخواست، حجم، زمان و Long Task را به مالک آن نسبت دهید. delay یا combine کور ممکن است ترتیب dependency، consent یا افزودن به سبد را خراب کند. هر تغییر را با سناریوی خرید smoke test کنید.
Page Cache با مرزهای ووکامرس
صفحه‌های عمومی و غیرشخصی کاندید page cache هستند؛ Cart، Checkout و My Account معمولاً نیستند. زبان، ارز، موقعیت، وضعیت ورود و cookie ووکامرس باید در policy دیده شوند. cache اشتباه ممکن است قیمت یا سبد کاربر دیگری را نشان دهد. hit/miss و headerها را اندازه بگیرید، نه اینکه فقط بعد از purge موقتاً نتیجه بگیرید.
Object Cache و Redis
object cache می‌تواند خواندن داده تکراری را کم کند، اما باید hit rate، eviction، memory و invalidation پایش شود. تماس خارجی کند، Query بد یا PHP اشباع با نصب Redis ناپدید نمی‌شود. برای تصمیم دقیق، کاربرد Redis در ووکامرس و راهنمای تصمیم‌گیری مرتبط را بر اساس workload بخوانید.
Query و دیتابیس
Query Monitor در محیط کنترل‌شده و slow query log می‌توانند Query پرتکرار، caller و زمان را نشان دهند. اندازه دیتابیس به‌تنهایی علت نیست؛ scan، join، sort، lock و N+1 مهم‌ترند. index حدسی یا حذف postmeta روی production خطر از دست رفتن داده و کند شدن write را دارد. plan قبل و بعد را روی clone با داده نزدیک آزمایش کنید.
در کاتالوگ بزرگ، variation، attribute، lookup و فیلتر ترکیبی مهم‌اند. راهنمای کندی ووکامرس با محصولات زیاد مسیرهای import و فیلتر را جدا بررسی می‌کند.
پاک‌سازی با حذف داده فرق دارد
revision، transient، session، log و job هرکدام چرخه عمر متفاوت دارند. ابتدا حجم، نرخ رشد، مالک جدول و سیاست retention را مشخص کنید. پاک‌سازی گروهی سفارش، item یا metadata برای کوچک شدن دیتابیس می‌تواند گزارش مالی و ارتباط محصولات را خراب کند. backup باید restore-test شده باشد و حذف آزمایشی ابتدا روی clone انجام شود.
پس از نگهداری دیتابیس، فقط اندازه فایل را معیار نگیرید؛ زمان Query، I/O و lock را دوباره بسنجید. کوچک شدن جدول بدون تغییر execution plan ممکن است هیچ اثر محسوسی بر مسیر خرید نداشته باشد.
PHP-FPM و ظرفیت واقعی
درخواست dynamic به worker نیاز دارد. اگر همه workerها مشغول باشند، Checkout پیش از اجرای کد منتظر می‌ماند. صف، سقف worker، مدت request و مصرف حافظه هر process را بسنجید. افزایش worker بدون RAM کافی می‌تواند swap یا OOM ایجاد کند. نسخه PHP باید توسط نسخه وردپرس، ووکامرس و افزونه‌ها پشتیبانی شود و روی staging آزموده شود.
APIهای خارجی را در مسیر خرید پیدا کنید
درگاه، حمل‌ونقل، مالیات، ضدتقلب، CRM، پیامک و ERP ممکن است synchronous اجرا شوند. DNS، connect time، TLS، timeout و پاسخ هر provider را ثبت کنید. خاموش کردن TLS verification یا validation برای سرعت قابل قبول نیست. عملیات غیرضروری را در صورت امکان و با تضمین idempotency به صف منتقل کنید.
Cron، Action Scheduler و کارهای پس‌زمینه
backup، import، تولید گزارش و jobهای failed می‌توانند منابع مشترک را در ساعات فروش مصرف کنند. تعداد pending به‌تنهایی کافی نیست؛ سن قدیمی‌ترین job، hook، زمان اجرا و علت retry را ببینید. حذف صف مشکل producer یا consumer را حل نمی‌کند و ممکن است ایمیل یا sync لازم را از بین ببرد.
هاست و سرور چه زمانی گلوگاه است؟
CPU saturation، available memory پایین، I/O latency، PHP queue و محدودیت دیتابیس را در همان زمان کندی بررسی کنید. اگر منابع سقف دارند و کد/Query غیرعادی برطرف شده، ارتقای ظرفیت یا معماری منطقی است. فقط مقایسه نام پلن یا تعداد core نتیجه دقیقی نمی‌دهد؛ کیفیت storage، محدودیت process و noisy neighbor نیز مهم‌اند.
ترتیب پیشنهادی اصلاح
- backup قابل restore، staging و baseline بسازید.
- خطاهای PHP، request شکست‌خورده و افزونه ناسازگار را رفع کنید.
- API کند، hook تکراری و job backlog را اصلاح کنید.
- Query پرتکرار و N+1 را در کد مالک برطرف کنید.
- تصاویر، asset و third-partyها را هدفمند سبک کنید.
- page/object cache را با bypass و invalidation درست پیاده کنید.
- PHP، MySQL و ظرفیت را بر پایه اندازه‌گیری تنظیم کنید.
- آزمون end-to-end و مانیتور پس از انتشار انجام دهید.
Performance Budget برای جلوگیری از بازگشت کندی
برای تعداد request، حجم JavaScript و تصویر، TTFB و زمان ثبت سفارش بودجه قابل اندازه‌گیری تعریف کنید. deployment، نصب افزونه و تغییر tagهای تبلیغاتی باید با همان سناریوها سنجیده شوند. alert روی p95، خطای Checkout، PHP queue و latency درگاه از گزارشی که ماهی یک بار دستی دیده شود مفیدتر است.
آزمون بار بدون آسیب به فروشگاه
Load test را مستقیم با ساخت سفارش و پرداخت واقعی روی production اجرا نکنید. محیطی با داده ناشناس و ظرفیت مشابه بسازید، مسیرهای read و write را جدا کنید و از نرخ کم شروع کنید. هدف فقط requests per second نیست؛ خطا، صف PHP، دیتابیس، موجودی و cleanup داده آزمایشی را هم کنترل کنید.
پس از ظرفیت‌سنجی، سقف امن و رفتار degradation را مشخص کنید. محدودسازی bot، صف‌بندی عملیات غیرضروری و پیام مناسب هنگام فشار، از افزایش نامحدود منابع قابل اتکاتر است. هر نتیجه باید نسخه کد و پیکربندی آزموده‌شده را همراه داشته باشد.
اشتباه‌های رایج
- نصب چند افزونه cache و optimization هم‌زمان
- cache کردن Cart و Checkout
- حذف سفارش، session یا metadata برای کوچک‌سازی
- افزایش worker و timeout بدون ظرفیت‌سنجی
- سنجش فقط صفحه اصلی و نمره آزمایشگاه
- خاموش کردن WAF یا TLS برای کاهش زمان
- انتشار تغییر بدون آزمون پرداخت و موجودی
چه زمانی کمک تخصصی لازم است؟
اگر صفحات عمومی سریع‌اند اما فیلتر، Checkout یا مدیریت سفارش کند است، علت در مسیر dynamic پنهان می‌ماند. سرویس افزایش سرعت وردپرس می‌تواند browser، PHP، Query، cache و منابع را در یک timeline اندازه بگیرد و اصلاح را با معیار پذیرش و rollback اجرا کند.
پرسش‌های متداول
اولین افزونه پیشنهادی برای سرعت ووکامرس چیست؟
بدون تشخیص نمی‌توان نسخه عمومی داد. ابتدا گلوگاه و مرز cache را مشخص کنید؛ افزونه باید یک نیاز اثبات‌شده را حل کند.
آیا CDN باعث سریع شدن Checkout می‌شود؟
assetهای static را نزدیک‌تر تحویل می‌دهد، اما پردازش dynamic، session، Query و API در origin باقی می‌ماند.
سرعت موبایل چرا کمتر است؟
توان CPU، شبکه، layout و JavaScript روی موبایل محدودتر است. waterfall و Long Task را روی device واقعی بررسی کنید.
چقدر بهبود کافی است؟
هدف باید بر اساس baseline، تجربه خرید و نرخ خطا تعریف شود؛ عدد بدون سناریو یا percentile قابل اتکا نیست.