WooCommerce Sepet ve Ödeme Sayfası Neden Yavaş?

Sepet ve ödeme sayfası yavaşsa önce hangi isteğin yavaş olduğunu ayırın: sayfanın HTML'i mi geç geliyor, yoksa sayfa açıldıktan sonra arka planda giden istekler mi? Klasik ödemede ?wc-ajax=update_order_review, blok tabanlı ödemede /wp-json/wc/store/v1/ istekleri, adres ya da kargo seçimi her değiştiğinde kargo ücretini, vergiyi ve kuponları baştan hesaplar. Gecikme çoğunlukla bu hesaba eklenen dış servislerden (canlı kargo API'si, ödeme altyapısı, dolandırıcılık kontrolü), temizlenmeyen oturum tablosundan ya da dolan PHP işçilerinden gelir. Ağ sekmesiyle ölçün, en yavaş isteğe odaklanın ve her değişikliği hazırlık kopyasında test siparişiyle doğrulayın.

Yavaş olan sayfa mı, ardından giden istek mi?

Ödeme sayfasının yavaş hissettirmesinin iki ayrı biçimi var. Birinde ekran beyaz kalır, HTML geç gelir. Ötekinde sayfa çabuk açılır ama sipariş özetinin üstünde dönen bir yükleme simgesi kalır, kargo seçenekleri birkaç saniye sonra belirir. İkinci durumda suçlu sayfanın kendisi değil, ardından gönderilen AJAX ya da REST isteğidir ve çözüm de ona göre değişir.

Ağ sekmesinde ölçüm

1. Gizli pencerede mağazayı açın ve sepete bir ürün ekleyin. Boş sepetle ödeme sayfası ölçülmez, WooCommerce sizi sepete geri gönderir.
2. F12 ile geliştirici araçlarını açın, Network (Ağ) sekmesine geçin ve "Disable cache" kutusunu işaretleyin.
3. /sepet/ ve /odeme/ sayfalarını sırayla yenileyin. Önce Doc filtresiyle sayfanın kendisine, sonra Fetch/XHR filtresiyle arka plan isteklerine bakın.
4. Her isteğe tıklayıp Timing sekmesinde sunucunun ilk baytı göndermesine kadar beklenen süreyi okuyun. Chrome sürümüne göre bu satır "Waiting for server response" ya da "Waiting (TTFB)" adıyla görünür.
5. Ödeme sayfasında il, posta kodu veya kargo yöntemini değiştirin ve yeni beliren isteklerin süresini not edin.

Listede göreceğiniz isteklerin çoğu aşağıdakilerden biridir. Hangisinin sizi beklettiğini bilmek, aramayı daraltır.

Sayfanın HTML'i hızlı geliyor da update_order_review saniyeler sürüyorsa sunucunun genel hızından şüphelenmeyin. O isteğin içinde çalışan bir hesaba ya da dışarıya yapılan bir çağrıya bakıyorsunuz demektir.

Aynı isteği komut satırında tekrarlamak

Tarayıcıdaki ölçüm eklentiler, ağ ve önbellek yüzünden dalgalanır. İsteği birkaç kez komut satırından tekrarlamak daha temiz bir tablo verir. Ağ sekmesinde isteğe sağ tıklayıp Copy → Copy as cURL seçin. Kopyalanan komut sepet oturumunuzun çerezini de taşır, sonuna yalnız ölçüm seçeneklerini eklemeniz yeterli:

curl 'https://ornek.com.tr/odeme/' \
  -H 'cookie: (tarayıcıdan kopyalanan çerezler)' \
  -o /dev/null -s \
  -w 'tls: %{time_appconnect}  ilk_bayt: %{time_starttransfer}  toplam: %{time_total}\n'

time_starttransfer ilk baytın geldiği andır. Bundan time_appconnect değerini çıkarırsanız kabaca sunucunun yanıtı hazırlamak için harcadığı süre kalır. Komutu beş kez çalıştırıp ortadaki değeri not edin, tek ölçüme güvenmeyin. Bir uyarı: ?wc-ajax=checkout isteğini asla bu yolla tekrarlamayın, her tekrar yeni bir sipariş denemesidir. update_order_review ise yalnız aynı adres bilgisini yeniden gönderir.

İsteğin içine bakmak

Süreyi bulduktan sonra sıra nedene gelir. Yönetici olarak oturum açtığınızda Query Monitor, ödeme sayfasının kaç sorgu çalıştırdığını, hangi eklentinin ne kadar süre harcadığını ve dışarıya hangi HTTP isteklerini attığını gösterir. jQuery ile yapılan AJAX isteklerinin özetini de yanıt başlıklarına ekler. Hangi eklentinin süreyi tükettiğini Query Monitor'ün bileşen ve HTTP API panelleriyle adım adım ayırabilirsiniz.

Sepet parçaları betiği her sayfada çalışıyor mu?

Eski sürümlerde her sayfada çalışan bir betikle başlayalım. wc-cart-fragments betiği mini sepeti güncel tutmak için get_refreshed_fragments isteğini gönderir ve bu istek sayfa önbelleğine takılmadan PHP'ye kadar iner. WooCommerce 7.8'den itibaren betik her sayfada varsayılan olarak yüklenmiyor; yalnız sepet bileşeni (Cart widget) bir görünümde çizildiğinde ekleniyor.

Güncel bir mağazada bu isteği hâlâ her ürün ve kategori sayfasında görüyorsanız betiği biri yüklüyordur. Storefront gibi bazı temalar sepet bileşenini şablona gömer. Başka bir eklenti betiği bağımlılık olarak kaydetmiş ya da kodda açıkça yüklemiş de olabilir. Query Monitor'ün Scripts panelinde wc-cart-fragments satırına ve onu bağımlılık olarak çağıranlara bakarak kaynağı bulursunuz.

WooCommerce'in kendi önerisi, cart fragments API'sini kullanmayan Mini Sepet (Mini-Cart) bloğuna geçmek. Klasik temada bu bir tema değişikliğidir, hazırlık kopyasında deneyin. Betiği tamamen kapatan kod parçaları da dolaşıyor. Bunları kullanırsanız sepete ekledikten sonra üst menüdeki sayacın güncellenip güncellenmediğini mutlaka test edin, çünkü işi o sayaç görüyordu. Resmî gerekçe ve seçenekler WooCommerce geliştirici blogundaki cart fragments yazısında anlatılıyor.

Bu arada sepet ve ödeme sayfalarının önbelleği atlaması beklenen davranıştır. Asıl kontrol edilmesi gereken, ürün ve kategori sayfalarının gerçekten önbellekten gelip gelmediğidir. Bunu yanıt başlıklarındaki HIT ve MISS değerlerinden okuyabilirsiniz.

Ödeme adımına eklenen dış servisler

Diyelim ki update_order_review isteği üç dört saniye sürüyor ve Query Monitor'ün HTTP API Calls panelinde aynı istekte iki dış çağrı görünüyor. Sunucunuz o sürenin büyük kısmında hesap yapmıyor, karşı tarafın yanıtını bekliyordur. WordPress'in HTTP API'sinde varsayılan zaman aşımı 5 saniyedir. Eklentiler bu değeri kendi ayarlarıyla değiştirebilir, yani yanıt vermeyen bir servis ödeme adımını uzun süre kilitleyebilir.

Canlı kargo ücreti

Kargo firmasının API'sinden fiyat çeken eklentiler adres değiştikçe dışarı çıkar. WooCommerce hesaplanan ücretleri, sepet içeriği ve teslimat adresi değişmedikçe oturumda saklar ve aynı soruyu tekrar sormaz. Bu önbelleği atlayan bir ayar var: WooCommerce → Ayarlar → Gönderim → Gönderim seçenekleri altındaki Hata ayıklama modu. Kurulum sırasında açılıp unutulduysa ücretler her istekte yeniden hesaplanır ve yavaşlığı tek başına açıklayabilir. Eklentinin kendi ayarlarında zaman aşımı ve servis yanıt vermezse sabit ücrete düşme seçeneği varsa ikisini de kullanın, gerçekten gönderim yaptığınız firmalar dışındakileri kapatın.

Ödeme altyapısı

Burada iki ayrı maliyet var. Biri tarayıcıda yüklenen betikler: kart formu çerçevesi, 3D Secure ekranı, cüzdan düğmeleri. Öteki, sipariş düğmesine basıldıktan sonra sunucunuzun ödeme kuruluşuna yaptığı çağrı. Kuruluşun yanıt süresi sizin elinizde değil, ama bekleyişin ne kadarının ona ait olduğunu ölçebilirsiniz. Eklentinin ayarlarından hata ayıklama günlüğünü açın, WooCommerce → Durum → Günlükler ekranında isteğin gidiş ve yanıt zaman damgalarını karşılaştırın. Günlükler kişisel veri içerebilir, işiniz bitince kapatın. Etkin ama kullanılmayan ödeme yöntemleri de sayfaya betik yükler, onları devre dışı bırakmak ucuz bir kazançtır.

Dolandırıcılık kontrolü, adres tamamlama ve benzerleri

Bu tür eklentiler ödeme doğrulama ve sipariş oluşturma kancalarına bağlanır. Adres tamamlama servisleri tarayıcı tarafında çalıştığı için çoğu zaman sunucuyu değil ziyaretçinin ekranını yavaşlatır. Dolandırıcılık puanlaması ise genellikle sipariş anında sunucudan dış servise gider. Hangisinin ne kadar eklediğini görmenin en güvenilir yolu hazırlık kopyasında tek tek kapatıp aynı ölçümü tekrarlamaktır. Bazı eklentiler kontrolü siparişten sonra arka planda yapabiliyor, ayarlarında böyle bir seçenek olup olmadığına bakın.

Sipariş e-postaları da aynı hesaba yazılır. WooCommerce varsayılan olarak e-postayı, sipariş durumunu değiştiren isteğin içinde gönderir. Yavaş yanıt veren bir SMTP sunucusu da sipariş düğmesinden sonraki bekleyişe doğrudan eklenir. Güncel sürümlerde bu gönderimi Action Scheduler'a devreden bir seçenek var, ama ayarı değiştirmeden önce e-postaların gönderim kaydını tutup teslimi doğrulamak iyi bir başlangıçtır.

Vergi, kupon ve fiyat kuralları

Adres değiştiğinde yeniden çalışan hesap yalnız kargodan ibaret değildir. Toplamlar her hesaplandığında vergi oranları, kupon kısıtları ve varsa dinamik fiyat ya da toplu indirim eklentilerinin kuralları da devreye girer. Sepetteki her kalem için onlarca kural tarayan bir indirim eklentisi, kalabalık sepetlerde fark edilir bir süre ekleyebilir. Kupon uygulamak ayrıca ?wc-ajax=apply_coupon isteğini tetikler. Bu isteğin süresi sepette kupon yokken ölçtüğünüz update_order_review süresinden belirgin biçimde uzunsa, şüpheliniz kupon tarafındaki kurallardır.

Kontrol yolu yine aynı: Query Monitor'de bileşene göre sorgu süresine bakın, ardından hazırlık kopyasında kural eklentisini kapatıp ölçün. Kalabalık sepetle test etmeyi unutmayın. Tek ürünlü sepette görünmeyen bir yavaşlık, yirmi kalemli bir kampanya sepetinde ortaya çıkabilir.

Oturum tablosu ve sipariş depolaması

Temizlenmeyen oturumlar

Her ziyaretçinin sepeti veritabanındaki woocommerce_sessions tablosunda tutulur (önekiyle birlikte genellikle wp_woocommerce_sessions). WooCommerce 10.1 ile oturum açmış kullanıcıların oturumları da yalnız bu tabloda saklanmaya başladı. Varsayılan ömür misafirlerde 2, oturum açmış kullanıcılarda 7 gün. Filtrelerle uzatılsa bile 30 günü geçemiyor. Aynı sürümle WooCommerce'in zamanlanmış görevleri Action Scheduler'a taşındı, süresi dolan oturumları silen iş de onlardan biri.

Oturumlar anahtar üzerinden okunduğu için tablonun büyümesi her sepet isteğini tek başına yavaşlatmaz. Asıl zararı dolaylıdır: milyonlarca satır veritabanı belleğini, yedekleri ve temizlik sorgularını ağırlaştırır. Sepete ürün ekleyen botlar da her ziyarette yeni satır yazar. Durumu phpMyAdmin'de ya da wp db query ile görebilirsiniz (tablo önekiniz farklıysa düzeltin):

SELECT COUNT(*) AS toplam,
       SUM(session_expiry < UNIX_TIMESTAMP()) AS suresi_dolmus
FROM wp_woocommerce_sessions;

suresi_dolmus sütunu birkaç günde bir sıfıra yakın değere inmiyorsa temizlik işi çalışmıyordur. Bu durumda sorun oturumlarda değil zamanlanmış görevlerdedir ve tabloyu elle boşaltmak kalıcı çözüm olmaz, önce Action Scheduler'da biriken bekleyen işlemlerin nedenini çözmek gerekir. WooCommerce → Durum → Araçlar ekranındaki Müşteri oturumlarını temizle düğmesi süresi dolmuş satırları değil tüm oturumları siler. O an alışveriş yapan herkesin sepeti boşalır, yoğun saatte kullanmayın.

HPOS mu, eski depolama mı?

"Sipariş ver" isteği sipariş kaydını yazar. Eski depolamada sipariş wp_posts ve wp_postmeta tablolarına dağılır. Yüksek performanslı sipariş depolama (HPOS) ise siparişleri kendi tablolarında tutar: wc_orders, wc_order_addresses, wc_order_operational_data, wc_orders_meta. WooCommerce 8.2'den beri yeni kurulumlarda varsayılan olarak açık, daha eski mağazaların elle geçmesi gerekiyor.

Hangisini kullandığınızı WooCommerce → Ayarlar → Gelişmiş → Özellikler ekranındaki Sipariş verisi depolama seçeneğinde görürsünüz. Uyumluluk modu açıksa siparişler iki depo arasında eşitlenir, sunucuya erişiminiz varsa wp wc hpos status eşitleme bekleyen sipariş sayısını gösterir. Beklentiyi doğru kuralım: HPOS sepet sayfasını hızlandırmaz. Etkisi sipariş oluşturma adımında ve yönetim panelindeki sipariş ekranlarında görülür. Geçişi yedek alıp, eklentilerinizin HPOS uyumluluğunu hazırlık kopyasında doğruladıktan sonra ve kampanya dönemi dışında yapın. Ayrıntılar WooCommerce'in HPOS belgesinde.

Blok tabanlı ödeme ile kısa kodlu ödeme

WooCommerce 8.3'ten itibaren yeni kurulan mağazalarda sepet ve ödeme sayfaları bloklarla geliyor. Eski mağazalar kendiliğinden geçmiyor, [woocommerce_cart] ve [woocommerce_checkout] kısa kodlarıyla çalışmaya devam ediyor. Hangisini kullandığınızı ağ sekmesi söyler: wc-ajax=update_order_review görüyorsanız klasik ödemedesiniz, /wc/store/v1/ istekleri görüyorsanız blok ödemede.

Hangisinin daha hızlı olduğuna dair genel bir hüküm vermeyeceğiz. Sonuç temaya, ödeme eklentilerine ve ödeme sayfasına alan ekleyen eklentilere bağlı. İşin pratiğinde karşılaşılan sorun çoğu zaman hız değil uyumluluktur: blok ödemeyle uyumsuz olduğunu bildiren bir eklentinin alanları blok ödemede görünmeyebilir. Geçiş ya da geri dönüş düşünüyorsanız sepet ve ödeme sayfasını birlikte değiştirin, ikisi birlikte çalışacak şekilde tasarlanmış. Adımlar WooCommerce'in sepet ve ödeme blokları belgesinde yer alıyor.

Sunucu tarafı: nesne önbelleği ve PHP işçileri

Sepet ve ödeme isteklerinin her biri PHP ve veritabanından geçer. Bu sayfaların neden sayfa önbelleğine giremediğini WooCommerce için hosting gereksinimleri yazısında açıkladık. Burada iki şey fark yaratır.

Birincisi kalıcı nesne önbelleği. Ürün nesneleri, seçenekler ve oturum verisi gibi sık okunan kayıtları istekler arasında bellekte tutar ve tam da sayfa önbelleğinin çalışmadığı bu isteklerde işe yarar. Query Monitor'ün genel bakış panelinde kalıcı bir nesne önbelleği kullanılıp kullanılmadığını ve isabet oranını görürsünüz. Kurulum mantığını ve kazancın nasıl ölçüleceğini Redis object cache rehberinde bulabilirsiniz.

İkincisi PHP işçileri. Bir işçi, dış servisten yanıt beklerken de meşgul kalır. Varsayımsal senaryo: eşzamanlı işlem (entry process) sınırı 20 olan bir paylaşımlı hesap düşünün. Kargo API'si yüzünden update_order_review 3 saniye sürüyor. Kampanya saatinde aynı anda adres giren müşteriler bu 20 yuvayı doldurur ve hesap saniyede kabaca 6–7 ödeme isteğinden fazlasını karşılayamaz. Aynı istek 0,5 saniyeye inerse aynı sınır saniyede 40 civarı isteği kaldırır. Hesap kabadır ama mesajı nettir: bekleme süresini kısaltmak, sınırı yükseltmekle aynı işi görür. CloudLinux kullanan cPanel sunucularında sınır dolduğunda ziyaretçi 508 hatası görür, 508 Resource Limit Reached hatasının hangi limitten kaynaklandığını panelin kaynak kullanım ekranından bulabilirsiniz. Kendi sunucunuzda aynı rolü PHP-FPM havuzundaki pm.max_children değeri oynar.

Belirtiden çözüme hızlı eşleştirme

Değişiklikleri hazırlık kopyasında deneyin

Canlı mağazada eklenti kapatıp açmak, o sırada ödeme yapan müşteriyi doğrudan etkiler. Panelinizdeki hazırlık (staging) aracıyla ya da ayrı bir alt alan adına aldığınız kopyada çalışın. Kopya farklı bir sunucudaysa mutlak süreler canlıyla aynı çıkmaz, değişiklik öncesi ve sonrasını kendi içinde karşılaştırın.

1. Ödeme yöntemlerini test kipine (sandbox) alın. Gerçek kartla deneme yapmayın.
2. Kopyadaki sipariş e-postalarının gerçek müşterilere, entegrasyonların (ERP, pazaryeri, kargo) canlı sistemlere gitmesini kapatın.
3. Değişiklikten önce yavaş isteği beş kez ölçüp ortanca değeri yazın.
4. Tek bir değişiklik yapın, aynı ölçümü aynı sepet ve adresle tekrarlayın.
5. Test siparişini baştan sona verin: sepete ekleme, adres, kargo, kupon, ödeme, teşekkür sayfası, yönetimdeki sipariş kaydı ve e-posta.

Geri alma için yolu baştan bilin. Bir eklenti yönetim panelini açılmaz hâle getirirse wp-content/plugins altındaki klasörünün adını değiştirmek onu devre dışı bırakır. Blok ödemeye geçtiyseniz sayfa düzenleyicide bloğu yeniden klasik kısa koda dönüştürebilirsiniz. Veritabanında satır silecekseniz önce yedek alın. HPOS geçişinde uyumluluk modu açık kaldığı sürece iki depo eşit tutulur, geri dönüş planınızı buna göre kurun.

Düzeldiğini nasıl anlarsınız?

Hissiyatla değil, ilk ölçümün aynısıyla. Aynı sepet içeriği, aynı teslimat adresi, aynı saat aralığı ve beş tekrarın ortancası. Yavaş olan istek beklenen ölçüde kısaldıysa ve test siparişi baştan sona sorunsuz tamamlandıysa canlıya alın. Ardından ilk yoğun saatte kaynak kullanım ekranına bakın, sınıra dayanma sıklığı azalmış olmalı. Oturum tablosundaki süresi dolmuş satır sayısını birkaç gün sonra tekrar sayın.

Kampanya yaklaşıyorsa tek kullanıcıyla yapılan ölçüm yetmez. Ödeme adımını kampanya öncesi yük testiyle kademeli olarak zorlamak, eşzamanlı müşteri sayısı arttığında sürelerin nasıl değiştiğini gösterir.

Optimizasyon yetmediğinde ve destek isterken

Dış çağrıları kısalttınız, oturum temizliği çalışıyor, nesne önbelleği devrede, ama ödeme istekleri yoğun saatte hâlâ kuyruğa giriyor. Bu noktada sorun kapasitedir. Netx'te WordPress hosting paketleri cPanel sunucularında LiteSpeed ve LSCache ile çalışır. Katalog sayfaları önbellekten gelirken sepet ve ödemenin ihtiyacı PHP işçisi ve bellektir. Bu ihtiyaç paylaşımlı paketi aşıyorsa VDS tarafında paketteki vCore ve RAM size ayrılmıştır, PHP havuzunu ve nesne önbelleğini kendi iş yükünüze göre boyutlandırırsınız. Geçiş zamanını sezgiyle değil e-ticarette VDS'e geçişi gösteren ölçülebilir sinyallerle belirleyin.

Netx müşteri panelinden destek talebi açacaksanız şu bilgiler teşhisi hızlandırır:

• Yavaş sayfanın adresi ve yavaş isteğin adı (ör. update_order_review)
• Yavaşlığın gözlendiği tarih ve saat, saat dilimiyle birlikte
• Beş tekrarlı ölçüm sonuçlarınız
• Query Monitor'de öne çıkan bileşen ya da dış HTTP çağrısı
• WooCommerce → Durum → Sistem durumu ekranından alınan sistem raporu
• Hazırlık kopyasında denediğiniz değişiklikler ve sonuçları