Checkout ممکن است در باز شدن اولیه، بعد از تغییر استان و روش ارسال، یا فقط هنگام فشردن دکمه ثبت سفارش کند باشد. این سه مرحله requestهای متفاوتی دارند. اگر زمان دقیق و request کند را جدا نکنید، ممکن است تصویر و CSS را بهینه کنید در حالی که یک Ajax برای محاسبه ارسال یا API درگاه چند ثانیه منتظر است.
پاسخ سریع: در DevTools تب Network، document و requestهای Ajax/Fetch را جدا ثبت کنید. status، مدت و response را با log ووکامرس، PHP و درخواست‌های خارجی در همان timestamp تطبیق دهید. Checkout را page cache نکنید و قبل از تغییر درگاه یا session، backup و پرداخت کنترل‌شده داشته باشید.
کندی در کدام مرحله رخ می‌دهد؟
- بارگذاری صفحه: template، asset، cart/session و Queryهای اولیه.
- به‌روزرسانی Checkout: محاسبه shipping، tax، coupon و total.
- ثبت سفارش: validation، ایجاد سفارش، رزرو موجودی و انتخاب پرداخت.
- انتقال به درگاه: ساخت درخواست API، DNS/TLS و دریافت redirect.
- بازگشت پرداخت: callback/webhook و تغییر وضعیت سفارش.
هر مرحله را با یک شناسه سفارش یا زمان دقیق دنبال کنید و داده کارت یا secret را در log قرار ندهید.
تشخیص با Browser DevTools
Preserve log را فعال و یک خرید کنترل‌شده اجرا کنید. requestهای طولانی، waterfall و payload خطا را بررسی کنید. اگر request در حالت Pending است، منتظر شبکه یا server است؛ اگر پاسخ سریع آمده ولی رابط دیر آزاد می‌شود، JavaScript و Long Task را بررسی کنید. پاسخ ممکن است پیام خطای کاربردی داشته باشد حتی اگر status برابر 200 باشد.
محاسبه ارسال و مالیات
افزونه حمل‌ونقل ممکن است با تغییر آدرس چند API را فراخوانی کند. debounce نامناسب یا hook تکراری باعث درخواست‌های پشت‌سرهم می‌شود. latency، timeout و تعداد فراخوانی هر provider را اندازه بگیرید. cache نتیجه باید بر اساس مبدا، مقصد، وزن و شرایط معتبر باشد؛ نرخ ارسال کاربر دیگری را reuse نکنید.
Session و Cart Fragment
cookie، session storage و درخواست‌های fragment برای سبد لازم‌اند، ولی تداخل domain/HTTPS، cache عمومی یا storage کند می‌تواند رفتار ناپایدار بسازد. با نشست ناشناس تازه و سپس کاربر واردشده تست کنید. خاموش کردن session یا fragment صرفاً برای بهتر شدن نمره، ممکن است سبد و قیمت را خراب کند.
درگاه و سرویس‌های خارجی
در زمان ثبت سفارش ممکن است درگاه، ضدتقلب، پیامک، CRM یا webhook فراخوانی شود. اگر عملیات synchronous است، کندی آن مستقیماً تجربه کاربر را متاثر می‌کند. connect و read timeout، retry و idempotency را بررسی کنید. retry کور ثبت تراکنش می‌تواند درخواست یا سفارش تکراری بسازد.
Query و Lock دیتابیس
ایجاد سفارش چند write و خواندن موجودی دارد. Query گزارش یا job سنگین هم‌زمان ممکن است lock یا I/O ایجاد کند. slow log و transactionهای طولانی را در همان بازه ببینید. حذف meta سفارش یا تغییر index روی production راه تشخیص نیست؛ ابتدا clone و backup داشته باشید.
PHP-FPM و صف درخواست
Checkout page cache را دور می‌زند و worker واقعی لازم دارد. اگر همه workerها مشغول باشند، request حتی پیش از اجرای وردپرس منتظر می‌ماند. وضعیت queue و پیام رسیدن به سقف را بررسی کنید. راهنمای PHP-FPM برای وردپرس نشان می‌دهد چرا worker بیشتر بدون RAM کافی خطرناک است.
تداخل افزونه را امن بررسی کنید
در staging با نسخه و داده مشابه، قالب پیش‌فرض و فقط افزونه‌های ضروری ووکامرس/درگاه را مبنا قرار دهید؛ سپس افزونه‌ها را مرحله‌ای اضافه کنید. نتیجه هر مرحله را با request یکسان ثبت کنید. غیرفعال کردن درگاه یا shipping فعال روی production بدون اطلاع کاربر می‌تواند سفارش واقعی را ناقص کند.
یک مسیر اصلاح مرحله‌ای
- backup، baseline و پرداخت آزمایشی بسازید.
- request کند و component مالک آن را شناسایی کنید.
- خطای PHP، retry و hook تکراری را رفع کنید.
- فراخوانی خارجی غیرضروری را از مسیر synchronous خارج کنید.
- Query و index را بر اساس plan اصلاح کنید.
- ظرفیت PHP و دیتابیس را با load واقعی تنظیم کنید.
- تغییر را با smoke test سفارش و callback منتشر کنید.
Checkout را Cache نکنید
HTML عمومی Checkout ممکن است nonce، session، روش ارسال و اطلاعات کاربر را اشتباه کند. bypass باید تمام مسیرهای وابسته و cookieهای ووکامرس را پوشش دهد. object cache نیز نیازمند invalidation و جداسازی درست است. «سریع‌تر شدن» با نمایش total قدیمی نتیجه قابل قبول نیست.
معیارهای موفقیت
- زمان document و هر Ajax مهم
- p95 زمان ثبت سفارش
- نرخ خطای validation و gateway
- تعداد سفارش Pending یا Failed غیرعادی
- PHP queue و latency دیتابیس
- درستی total، shipping، tax و coupon
- دریافت callback و ایمیل سفارش
اشتباه‌های رایج
- page cache کردن Checkout
- افزایش timeout بدون یافتن سرویس کند
- فشردن چندباره دکمه پرداخت هنگام Pending
- تست با session قدیمی و افزونه مرورگر
- خاموش کردن SSL verification
- restore دیتابیس قدیمی و از دست دادن سفارش‌های تازه
تفاوت کندی با گیرکردن ثبت سفارش
اگر request سرانجام با پاسخ صحیح تمام می‌شود، مسئله latency است. اگر spinner باقی می‌ماند، request تکرار می‌شود یا سفارش بدون redirect ساخته شده، مسیر گیرکردن Checkout هنگام ثبت سفارش را دنبال کنید. ابتدا بررسی کنید سفارش یا تراکنش واقعاً ایجاد شده تا دوباره پرداخت نکنید.
چه زمانی کمک تخصصی لازم است؟
اگر تأخیر فقط هنگام پرداخت واقعی رخ می‌دهد یا تغییرات آزمایشی سفارش‌های ناقص می‌سازد، ادامه آزمون روی production پرریسک است. پشتیبانی فروشگاه ووکامرس می‌تواند trace درخواست، log درگاه و وضعیت سفارش را بدون حذف شواهد بررسی کند.
پرسش‌های متداول
آیا CDN باعث سریع شدن Checkout می‌شود؟
assetهای static ممکن است سریع‌تر شوند، اما پردازش dynamic و API پرداخت همچنان در origin انجام می‌شود.
چرا Checkout فقط برای مهمان کند است؟
ساخت session، validation و مسیرهای مخصوص مهمان را با کاربر واردشده مقایسه کنید.
چرا با تغییر استان صفحه مکث می‌کند؟
معمولاً request محاسبه shipping/tax اجرا می‌شود؛ تعداد فراخوانی و latency provider را بررسی کنید.