سریع بودن صفحه اصلی و محصولات در کنار Checkout کند تناقض نیست. صفحات عمومی اغلب از page cache یا CDN پاسخ می‌گیرند، اما Checkout باید session، سبد، آدرس، ارسال، مالیات، تخفیف و پرداخت را برای همان کاربر پردازش کند. این مسیر dynamic مستقیماً به PHP، دیتابیس و سرویس‌های خارجی وابسته است و نمره خوب صفحه اصلی آن را اندازه نمی‌گیرد.
پاسخ سریع: در DevTools مشخص کنید تأخیر هنگام باز شدن صفحه، درخواست به‌روزرسانی Checkout، ثبت سفارش یا انتقال به درگاه است. request کند را با PHP/WooCommerce log، Query و تماس خارجی همان timestamp تطبیق دهید. Checkout را page cache نکنید و افزایش timeout را جای یافتن سرویس کند نگذارید.
چرا Page Cache تفاوت را پنهان می‌کند؟
صفحه محصول cacheشده ممکن است بدون اجرای کامل وردپرس تحویل شود، درحالی‌که Checkout برای هر request worker واقعی مصرف می‌کند. یک تست ناشناس از صفحه اصلی ظرفیت dynamic سرور را ثابت نمی‌کند. cache header، cookie و زمان origin را در هر دو مسیر مقایسه کنید.
کندی در کدام لحظه رخ می‌دهد؟
| لحظه | نامزدهای اصلی | شاهد |
|---|---|---|
| باز شدن اولیه | PHP، template، session و Query | TTFB و profiler |
| تغییر استان/آدرس | Ajax، shipping و tax | Network waterfall |
| انتخاب روش ارسال | محاسبه مجدد و API provider | request count و external log |
| ثبت سفارش | validation، write، موجودی و hook | Ajax response و PHP log |
| انتقال به درگاه | API، DNS، TLS و timeout | gateway log و request ID |
DevTools را روی یک خرید کنترل‌شده استفاده کنید
Preserve log را فعال کنید و document، XHR/Fetch و redirectها را جدا ببینید. status، duration، initiator و response غیرحساس را ثبت کنید. اگر request دیر تمام می‌شود، backend یا شبکه مطرح است؛ اگر پاسخ سریع است ولی spinner باقی می‌ماند، JavaScript و handler رابط را بررسی کنید. چندبار روی پرداخت کلیک نکنید.
زمان مرورگر و زمان سرور را جدا کنید
در Network، queueing، DNS، connect، TLS، waiting و download اجزای متفاوت‌اند. TTFB بالا می‌تواند انتظار proxy/PHP یا شبکه باشد؛ server timing و log upstream به تفکیک کمک می‌کند. اگر server در ۲۰۰ میلی‌ثانیه پاسخ داده ولی مرورگر چند ثانیه منتظر handler است، افزایش PHP worker مسیر اشتباهی است.
برعکس، اگر JavaScript سریع request را می‌فرستد و پاسخ دیر است، flame chart مرورگر علت backend را نشان نمی‌دهد. request ID یا timestamp مشترک بسازید تا trace مرورگر، Nginx، PHP و درگاه به هم متصل شوند.
درخواست‌های تکراری Update Checkout
تغییر آدرس و روش ارسال می‌تواند محاسبه total را آغاز کند. اسکریپت یا hook نامناسب ممکن است loop بسازد و چند request پشت‌سرهم بفرستد. تعداد، initiator و payload غیرحساس را مقایسه کنید. debounce کور ممکن است total را stale کند؛ منبع event تکراری باید اصلاح شود.
حمل‌ونقل و مالیات
provider ارسال ممکن است برای هر تغییر فیلد API خارجی را صدا بزند. connect/read time، timeout، تعداد فراخوانی و fallback را ثبت کنید. cache نرخ ارسال باید بر اساس مبدا، مقصد، وزن و شرایط معتبر باشد؛ reuse نادرست می‌تواند قیمت اشتباه نشان دهد. validation TLS را برای چند صد میلی‌ثانیه کمتر خاموش نکنید.
درگاه و سرویس‌های جانبی
هنگام ثبت سفارش، درگاه، ضدتقلب، پیامک، CRM یا ERP ممکن است synchronous اجرا شوند. یک provider کند کل پاسخ را نگه می‌دارد. request ID، DNS، TLS و status را بررسی کنید. timeout لزوماً شکست قطعی تراکنش نیست؛ قبل از retry وضعیت قبلی را inquiry کنید تا پرداخت تکراری ساخته نشود.
Session و ذخیره سبد
Checkout به session پایدار نیاز دارد. cookie با domain/HTTPS نادرست، storage کند، eviction یا چند node ناسازگار می‌تواند زمان و خطا ایجاد کند. با مهمان و عضو، مرورگر تازه و hostname نهایی تست کنید. مقدار cookie را ثبت یا منتشر نکنید. خالی کردن همه sessionها خرید کاربران فعال را مختل می‌کند.
شخصی‌سازی قیمت و قوانین تجاری
قیمت نقش کاربر، تخفیف عمده، محدودیت خرید، امتیاز وفاداری و موجودی چند انبار معمولاً در Checkout دوباره ارزیابی می‌شوند. اگر هر rule برای هر line item Query یا API جدا اجرا کند، صفحه محصول cacheشده سریع ولی سبد بزرگ کند می‌شود. زمان را به rule و تعداد آیتم نسبت دهید و محاسبات مشترک را batch کنید.
برای سرعت، validation قیمت یا موجودی را حذف نکنید. cache نتیجه باید کل ورودی مؤثر—کاربر، محصول، تعداد و زمان اعتبار—را پوشش دهد و پس از تغییر invalidate شود.
Query و Lock هنگام ساخت سفارش
محاسبه قیمت، coupon، موجودی و ایجاد order چند خواندن و نوشتن دارد. گزارش سنگین، import موجودی یا transaction طولانی می‌تواند lock و I/O بسازد. slow log و Query Monitor کنترل‌شده را در همان بازه ببینید. index و حذف metadata را فقط با backup، plan و clone آزمایش کنید.
PHP-FPM و صف Worker
وقتی صفحات عمومی cache هستند، کمبود worker تا ورود به Checkout دیده نمی‌شود. active/idle worker، queue، رسیدن به سقف و memory هر process را پایش کنید. افزایش worker بدون RAM کافی OOM یا swap می‌سازد. مدت request را به component نسبت دهید و سپس ظرفیت را تنظیم کنید.
Action Scheduler و Hookهای سفارش
برخی عملیات باید پس‌زمینه باشند، اما plugin ممکن است قبل از پاسخ کار سنگین انجام دهد یا صف backlog منابع را مصرف کند. hook، زمان و exception را بررسی کنید. انتقال عملیات مالی به async بدون طراحی idempotency و وضعیت میانی خطرناک است؛ مرز تراکنش و تجربه مشتری باید روشن باشد.
تفاوت روش‌های پرداخت و ارسال را مقایسه کنید
با یک سبد و آدرس ثابت، روش‌ها را در محیط آزمایشی معتبر مقایسه کنید. اگر فقط یک درگاه کند است، Query عمومی ووکامرس احتمال کمتری دارد. اگر همه روش‌ها پیش از انتخاب درگاه کندند، محاسبه total، session یا PHP مهم‌تر است. روش پرداخت آفلاین می‌تواند baseline ساخت سفارش باشد، اما رفتار callback درگاه آنلاین را پوشش نمی‌دهد.
افزونه فعال production را برای تست مشتریان خاموش نکنید. staging یا maintenance plan داشته باشید و مطمئن شوید آزمون، ایمیل، موجودی یا fulfillment واقعی ایجاد نمی‌کند.
Checkout را Cache نکنید
HTML Checkout شامل داده وابسته به کاربر، nonce، total و روش‌هاست. cache عمومی شاید ظاهراً سریع شود اما سبد، قیمت یا امنیت را خراب کند. bypass باید مسیرها و cookieهای لازم را پوشش دهد. Object cache با page cache فرق دارد و فقط با invalidation و جداسازی درست قابل استفاده است.
مقایسه‌ای که علت را آشکار می‌کند
- صفحه محصول cache سرد و گرم را ثبت کنید.
- Checkout را با یک محصول ساده و آدرس ثابت باز کنید.
- هر Ajax را از document جدا زمان بگیرید.
- ارسال و درگاه را در محیط کنترل‌شده مقایسه کنید.
- PHP، Query و external call را در همان timeline قرار دهید.
- فقط یک مؤلفه را تغییر و سناریو را تکرار کنید.
ترتیب اصلاح
- خطای PHP/JavaScript و request تکراری را رفع کنید.
- API کند و timeout/retry را اصلاح کنید.
- Query و hook پرتکرار را در مالک اصلی تغییر دهید.
- صف PHP و دیتابیس را پس از اندازه‌گیری تنظیم کنید.
- cache صفحات عمومی را حفظ و bypass Checkout را تأیید کنید.
- پرداخت، callback، ایمیل و موجودی را end-to-end تست کنید.
معیار موفقیت
- p50/p95 باز شدن و update Checkout
- زمان POST ثبت سفارش و انتقال درگاه
- نرخ 4xx/5xx و timeout
- PHP queue و Query time
- درستی total، shipping، coupon و tax
- یک سفارش و یک تراکنش برای هر تلاش معتبر
اشتباه‌های رایج
- مقایسه Checkout با صفحه اصلی cacheشده
- page cache کردن Checkout
- افزایش timeout و worker بدون تشخیص
- فشردن چندباره دکمه پرداخت
- خاموش کردن TLS یا WAF
- غیرفعال کردن درگاه روی production وسط خرید
- تست سرعت بدون کنترل صحت سفارش
راهنمای مرتبط
اگر request سرانجام پاسخ می‌دهد ولی دیر است، راهنمای کندی Checkout ووکامرس جزئیات بیشتری دارد. اگر spinner باقی می‌ماند یا سفارش بدون redirect ساخته می‌شود، گیرکردن ثبت سفارش را دنبال کنید.
چه زمانی کمک تخصصی لازم است؟
اگر کندی فقط با پرداخت واقعی، ترافیک هم‌زمان یا یک روش ارسال رخ می‌دهد، آزمون production می‌تواند سفارش ناقص بسازد. پشتیبانی فروشگاه ووکامرس می‌تواند Network، PHP، Query و API خارجی را با شناسه سفارش در یک trace بررسی کند.
پرسش‌های متداول
آیا CDN برای Checkout مفید است؟
برای assetهای static بله، اما پردازش dynamic و APIها در origin باقی می‌مانند و HTML شخصی نباید عمومی cache شود.
چرا فقط با انتخاب یک استان کند می‌شود؟
روش‌های ارسال/مالیات و API مربوط به همان مقصد را از نظر تعداد و latency بررسی کنید.
Redis مشکل را حل می‌کند؟
فقط اگر خواندن تکراری دیتابیس سهم مهمی داشته باشد؛ latency درگاه یا loop Ajax را حل نمی‌کند.
چرا مدیر سایت کندی را نمی‌بیند؟
آدرس، روش ارسال، cache، session یا نقش کاربر متفاوت است. سناریوی مشتری را با داده کنترل‌شده بازسازی کنید.