WooCommerce Magazasini Hizlandirma Rehberi

Bir WooCommerce magazasi, sıradan bir tanıtım sitesi gibi davranmaz. Kurumsal bir "hakkımızda" sayfası herkese aynı HTML'i gösterir; onu bir kez üretip önbelleğe alırsınız ve saatlerce dokunmazsınız. Oysa bir e-ticaret sitesinde her ziyaretçinin sepeti, oturumu ve hesap bilgisi farklıdır. Sunucu, sayfanın büyük kısmını her istekte yeniden PHP ile üretmek, veritabanını sorgulamak ve oturumu takip etmek zorunda kalır. Magaza büyüdükçe, ürün sayısı arttıkça ve eşzamanlı ziyaretçi trafiği yükseldikçe bu maliyet katlanarak büyür.

Bu rehberde, yoğun bir WooCommerce magazasini hızlandırmanın somut ve sıralı adımlarını anlatıyorum. Yaklaşımımız tek bir sihirli eklenti değil; katmanlı bir mimari. Önce hangi sayfaların önbelleğe alınıp hangilerinin istisna tutulması gerektiğini netleştireceğiz, ardından object cache ile veritabanı yükünü düşürecek, şişen tabloları temizleyecek, gereksiz AJAX çağrılarını kısacak ve son olarak görselleri ile modern sipariş depolama mimarisini (HPOS) ele alacağız. Henüz bir magaza kurmadıysanız, önce WooCommerce baslangic rehberimize göz atmanızı, genel WordPress hızı içinse WordPress hiz optimizasyonu yazımızı okumanızı öneririm.

WooCommerce Neden Statik Sitelerden Agir?#

Klasik bir WordPress sayfası ile bir WooCommerce sayfası arasındaki fark, "durağan" ile "dinamik" arasındaki farktır. Statik bir sayfada içerik ziyaretçiye göre değişmez; bu yüzden tam sayfa önbellek (full page cache) kusursuz çalışır: ilk ziyaretçi sayfayı üretir, sonraki binlerce ziyaretçi hazır HTML'i alır ve PHP hiç çalışmaz.

WooCommerce ise oturum tabanlıdır. Sepete ürün ekleyen ziyaretçiye üst köşede "2 ürün — 349,90 TL" yazması gerekir. Giriş yapan müşteriye "Merhaba Ahmet" yazması, ödeme sayfasında kayıtlı adreslerin görünmesi gerekir. Bu içerik kişiye özeldir. WooCommerce bunu takip etmek için her ziyaretçiye bir oturum çerezi (woocommerce_cart_hash, wp_woocommerce_session_*) atar ve bu çerezi taşıyan istekleri önbellekten geçirmemeye çalışır.

Sorunun kaynağı da tam olarak burasıdır. Yanlış yapılandırılmış bir önbellek katmanı ya herkese aynı sepeti gösterir (felaket), ya da güvenli tarafta kalmak için hiçbir şeyi önbelleğe almaz (yavaş). Doğru kurulum bu ikisi arasındaki dengedir: mağaza vitrini, kategori ve ürün sayfaları önbelleğe alınır; sepet, ödeme ve hesabım sayfaları istisna tutulur. Aşağıdaki tablo bu ayrımı özetliyor.

Onbellek Istisnalari: Sepet, Odeme ve Hesabim Sayfalari#

İlk ve en kritik adım, dinamik sayfaları önbellekten muaf tutmaktır. Bunu iki yerde yapmanız gerekir: sunucu seviyesinde (Nginx/Apache) ve varsa önbellek eklentisinde. İkisini birlikte yapmak, bir katman gözden kaçırsa bile diğerinin yakalamasını sağlar.

Nginx tarafında FastCGI cache veya proxy cache kullanıyorsanız, WooCommerce'in standart URL'lerini ve oturum çerezlerini bypass koşuluna eklemelisiniz. Örnek bir yapılandırma şöyle görünür:

# WooCommerce dinamik sayfalarini onbellekten haric tut
set $skip_cache 0;

if ($request_uri ~* "/(sepet|odeme|hesabim|cart|checkout|my-account)") {
    set $skip_cache 1;
}

# Sepet dolu veya giris yapilmis oturum cerezi varsa bypass
if ($http_cookie ~* "woocommerce_items_in_cart|woocommerce_cart_hash|wp_woocommerce_session_|wordpress_logged_in") {
    set $skip_cache 1;
}

location ~ \.php$ {
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache     $skip_cache;
    fastcgi_cache        WORDPRESS;
    fastcgi_cache_valid  200 60m;
}

Buradaki mantık iki yönlüdür: hem URL'e göre (mağazanızda Türkçe kalıcı bağlantı kullanıyorsanız sepet, odeme, hesabim gibi slug'ları eklemeyi unutmayın) hem de çereze göre filtreleme yaparsınız. Ziyaretçi sepetine ilk ürünü ekler eklemez woocommerce_items_in_cart çerezi oluşur ve o andan itibaren tüm sayfalar dinamik moda geçer, böylece üst köşedeki sepet göstergesi hep güncel kalır.

Eğer LiteSpeed ya da paylaşımlı bir hosting ortamındaysanız, çoğu WordPress önbellek eklentisi (LiteSpeed Cache, WP Rocket vb.) WooCommerce'i otomatik tanır ve bu sayfaları listeye ekler. Yine de eklentinin "Cache Exclude URIs" ayarını açıp /sepet/, /odeme/, /hesabim/ yollarının orada olduğunu gözle doğrulayın. Yanlış yapılandırmanın en belirgin belirtisi, bir müşterinin başka birinin sepetini görmesidir; bu tür bir raporla karşılaşırsanız ilk bakacağınız yer önbellek istisnalarıdır.

Redis Object Cache ile Veritabani Yukunu Azaltma#

Tam sayfa önbellek sadece anonim ziyaretçileri hızlandırır. Peki giriş yapmış müşteri, sepet ve ödeme sayfaları? İşte burada devreye "object cache" girer. Object cache, WordPress'in tekrar tekrar çalıştırdığı veritabanı sorgularının sonuçlarını bellekte (RAM) tutar. Aynı ürünün fiyatını, aynı ayarı, aynı kategori ağacını her istekte MySQL'e sormak yerine, ilk seferde belleğe alıp sonraki isteklerde oradan okur.

WooCommerce özellikle object cache'ten fayda görür çünkü tek bir ürün sayfası bile arka planda onlarca get_option, wc_get_product ve meta sorgusu çalıştırır. Redis, bu iş için endüstri standardıdır. Sunucuda Redis kuruluysa, redis PHP eklentisini yükleyip WordPress tarafında Redis Object Cache eklentisini etkinleştirmeniz yeterlidir:

# Sunucuda Redis kurulumu (Ubuntu/Debian ornegi)
sudo apt update && sudo apt install redis-server php-redis
sudo systemctl enable --now redis-server

# WordPress dizininde WP-CLI ile Redis eklentisini kur ve etkinlestir
wp plugin install redis-cache --activate
wp redis enable

wp-config.php dosyasına bağlantı ayarlarını ve mağazaya özel bir önek eklemek iyi bir alışkanlıktır. Aynı sunucuda birden fazla WordPress varsa bu önek, sitelerin birbirinin önbelleğini ezmesini engeller:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'magaza1:' );
define( 'WP_REDIS_MAXTTL', 86400 );

Redis'in çalıştığını doğrulamak için wp redis status komutunu kullanabilir, canlı isabet oranını da redis-cli info stats çıktısındaki keyspace_hits ve keyspace_misses değerlerinden takip edebilirsiniz. İsabet oranınız yüzde 90'ın üzerindeyse object cache işini iyi yapıyor demektir. Kendi sunucunuzu yönetmek istemiyorsanız, Redis'in hazır geldiği bir WordPress hosting paketi ya da tam kontrol için bir VDS sunucu tercih edebilirsiniz.

Gecici Verileri (Transient) ve Veritabanini Temizleme#

Zamanla WooCommerce veritabanı sessizce şişer. Bunun başlıca üç kaynağı vardır: süresi dolmuş "transient" (geçici) kayıtları, çöp kutusundaki eski siparişler ve terk edilmiş sepet oturumları. Bu birikinti hem yedek boyutunu büyütür hem de wp_options gibi sık okunan tabloları yavaşlatır.

Transient'ler WordPress'in geçici verileri sakladığı mekanizmadır; kur bilgisi, kargo hesapları, geçici API yanıtları burada tutulur. Süreleri dolduğunda otomatik silinmeleri beklenir ama pratikte binlerce eski kayıt wp_options içinde birikir. WP-CLI ile bunları güvenle temizleyebilirsiniz:

# Suresi dolmus tum transient kayitlarini sil
wp transient delete --expired

# WooCommerce'e ozel gecici verileri temizle
wp db query "DELETE FROM wp_options WHERE option_name LIKE '_transient_wc_%';"
wp db query "DELETE FROM wp_options WHERE option_name LIKE '_transient_timeout_wc_%';"

Çöp kutusundaki eski siparişler ve otomatik taslak revizyonlar da yer kaplar. Aşağıdaki SQL, 30 günden eski çöp siparişlerini ve fazla revizyonları hedefler. Bu tür sorguları çalıştırmadan önce mutlaka tam bir yedek alın; geri dönüşü olmayan işlemlerdir:

-- Once mutlaka yedek alin
-- Cop kutusundaki 30 gunden eski siparisler
DELETE p, pm FROM wp_posts p
LEFT JOIN wp_postmeta pm ON p.ID = pm.post_id
WHERE p.post_type = 'shop_order'
  AND p.post_status = 'trash'
  AND p.post_modified < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Yazi revizyonlarini temizle
DELETE FROM wp_posts WHERE post_type = 'revision';

Temizlik sonrası tabloları optimize etmeyi de unutmayın; wp db optimize komutu MySQL'e boşalan alanı geri kazandırır. Bu bakımı ayda bir manuel yapabilir ya da bir cron görevi ile otomatikleştirebilirsiniz. Ancak SQL ile elle silmekten çekiniyorsanız, WP-CLI komutları çok daha güvenlidir çünkü WooCommerce'in kendi mantığını devreye sokar. Bu tür kritik işlemler öncesinde düzenli, otomatik yedekleme çözümünüzün çalıştığından emin olun.

Cart Fragments AJAX Yukunu Kontrol Altina Alma#

WooCommerce'in en sinsi performans sorunlarından biri "cart fragments" özelliğidir. Bu özellik, sepet göstergesinin (üst köşedeki "2 ürün" yazısı) sayfa yenilenmeden güncellenmesini sağlar. Bunun için her sayfa yüklemesinde admin-ajax.php dosyasına bir AJAX çağrısı gönderir. Sorun şu ki bu çağrı wc-ajax=get_refreshed_fragments isteği, önbelleklenemez ve her ziyaretçide, her sayfada tetiklenir. Trafik arttıkça admin-ajax.php sunucunun en çok çalışan noktası haline gelir.

Eğer temanız sepet sayısını gerçek zamanlı güncellemek zorunda değilse ya da bunu kabul edilebilir buluyorsanız, cart fragments'i ana sayfa gibi anonim sayfalarda devre dışı bırakmak ciddi bir kazanç sağlar. Aşağıdaki kod, sepet boşken script'i tamamen kaldırır ve müşteri sepete ürün ekleyene kadar bu ek yükü ortadan kaldırır:

// functions.php veya kucuk bir eklenti icine
add_action( 'wp_enqueue_scripts', function () {
    // Sepet ve odeme sayfalarinda dokunma
    if ( is_cart() || is_checkout() ) {
        return;
    }
    // Sepet bossa fragment script'ini kaldir
    if ( WC()->cart && WC()->cart->is_empty() ) {
        wp_dequeue_script( 'wc-cart-fragments' );
    }
}, 20 );

Bu değişikliği yaptıktan sonra tarayıcının "Network" sekmesini açıp ana sayfayı yenileyin; get_refreshed_fragments isteğinin artık yapılmadığını görmelisiniz. Sepete bir ürün eklediğinizde ise özelliğin geri devreye girdiğini doğrulayın. Bu ince ayar özellikle mobil trafiği yoğun mağazalarda, sunucu yükünü belirgin şekilde düşürür ve algılanan sayfa hızını artırır.

Gorsel Optimizasyonu ve Teslimat#

E-ticaret sitelerinde sayfa ağırlığının büyük bölümü görsellerden gelir. Ürün fotoğrafları, kategori küçük resimleri, galeri görselleri hızlıca megabaytlara ulaşır. Görsel optimizasyonu üç ayaktan oluşur: doğru boyut, modern format ve tembel yükleme (lazy loading).

Modern formatlar burada en büyük kazancı sağlar. Aynı kalitede WebP, JPEG'e göre yüzde 25-35, AVIF ise yüzde 50'ye varan oranda daha küçüktür. Görsellerinizi toplu olarak WebP'ye çevirmek için sunucuda cwebp aracını kullanabilirsiniz:

# Bir klasordeki tum JPEG'leri WebP'ye cevir
for f in wp-content/uploads/**/*.jpg; do
    cwebp -q 82 "$f" -o "${f%.jpg}.webp"
done

Aşağıdaki tablo, tipik bir 1200 piksellik ürün fotoğrafının format bazında yaklaşık boyutlarını gösterir. Aradaki fark, özellikle onlarca ürünün listelendiği kategori sayfalarında toplam sayfa boyutuna doğrudan yansır.

İkinci ayak doğru boyuttur: 3000 pikselik bir fotoğrafı 300 pikselik bir küçük resim alanında göstermek saf israftır. WooCommerce'in görsel boyutu ayarlarını (Görünüm > Özelleştir > WooCommerce > Ürün Görselleri) mağazanızın gerçek yerleşimine göre ayarlayın ve wp media regenerate ile küçük resimleri yeniden üretin. Üçüncü ayak ise tembel yüklemedir; WordPress bunu artık yerleşik olarak loading="lazy" ile yapar, yani ekranın altındaki görseller ancak kullanıcı kaydırınca yüklenir. Yüksek trafikli mağazalarda görselleri bir CDN üzerinden dağıtmak da ilk bayt süresini ve coğrafi gecikmeyi ciddi biçimde düşürür.

HPOS (High-Performance Order Storage) Gecisi#

WooCommerce yıllarca siparişleri, blog yazıları gibi wp_posts ve wp_postmeta tablolarında sakladı. Bu, az sayıda siparişte sorun değildi; ancak on binlerce siparişe ulaşan bir mağazada bu tablolar devasa büyür ve her sipariş sorgusu yavaşlar çünkü aynı tablo hem yazıları hem ürünleri hem siparişleri barındırır. HPOS (High-Performance Order Storage), siparişler için ayrı ve amaca özel tablolar kullanan modern depolama mimarisidir.

HPOS ile siparişler wp_wc_orders, wp_wc_order_addresses ve wp_wc_orders_meta gibi özelleşmiş tablolara taşınır. Bu tablolar sadece siparişleri tuttuğu ve doğru indekslerle tasarlandığı için, admin panelindeki sipariş listesi ve raporlar belirgin biçimde hızlanır. Özellikle "Siparişler" ekranının açılması saniyeler sürüyorsa, HPOS geçişi en etkili çözümlerden biridir.

Geçişi WooCommerce 8.2 ve sonrası için WooCommerce > Ayarlar > Gelişmiş > Özellikler menüsünden açabilir ya da WP-CLI ile yönetebilirsiniz. Geçiş öncesi mutlaka tam yedek alın ve önce bir hazırlık (staging) ortamında deneyin, çünkü eski veya uyumsuz bazı eklentiler henüz HPOS uyumlu olmayabilir:

# HPOS uyumlulugunu ve durumunu kontrol et
wp wc hpos status

# Mevcut siparisleri yeni tablolara senkronize et
wp wc hpos sync

# Senkronizasyon tamamlaninca HPOS'u yetkili depo yap
wp option update woocommerce_custom_orders_table_enabled yes

Geçiş sırasında WooCommerce, bir süre hem eski hem yeni tabloları senkron tutar; böylece bir sorun çıkarsa geri dönebilirsiniz. Tüm siparişler taşındığından ve eklentileriniz sorunsuz çalıştığından emin olduktan sonra senkronizasyonu kapatıp yalnızca yeni tabloları kullanmaya geçebilirsiniz. Büyük mağazalarda bu tek değişiklik, admin panelinin genel akıcılığını hissedilir ölçüde iyileştirir.

Sıkça Sorulan Sorular#

WooCommerce sitem neden statik siteme gore cok daha yavas?#

Çünkü WooCommerce sayfaları kişiye özeldir ve büyük ölçüde önbelleğe alınamaz. Her ziyaretçinin sepeti, oturumu ve hesap bilgisi farklı olduğundan sunucu sayfanın önemli bir kısmını her istekte PHP ile yeniden üretir ve veritabanını sorgular. Statik bir sitede ise aynı HTML herkese servis edildiği için PHP neredeyse hiç çalışmaz. Bu yüzden WooCommerce'te object cache, doğru önbellek istisnaları ve güçlü bir sunucu çok daha kritiktir.

Sepet ve odeme sayfalarini onbelleklersem ne olur?#

Bu, e-ticarette yapılabilecek en tehlikeli hatalardan biridir. Bu sayfalar önbelleğe alınırsa bir müşteri, başka bir ziyaretçinin sepetini, adresini ve hatta hesap bilgilerini görebilir. Bu hem ciddi bir gizlilik ihlali hem de sipariş karışıklıklarına yol açan bir hatadır. Sepet, ödeme ve hesabım sayfaları her zaman hem sunucu hem eklenti seviyesinde önbellekten muaf tutulmalıdır.

Redis object cache olmadan WooCommerce yeterince hizli olur mu?#

Küçük ve düşük trafikli bir mağaza için Redis olmadan da kabul edilebilir hızlar alabilirsiniz. Ancak ürün sayısı ve eşzamanlı ziyaretçi arttıkça, object cache olmadan veritabanı hızla darboğaz haline gelir. Redis, tekrar eden sorguların sonuçlarını bellekte tuttuğu için giriş yapmış müşteri ve sepet-ödeme sayfalarını hızlandırır; bu sayfalar tam sayfa önbellekten faydalanamadığı için object cache pratikte tek hızlandırma katmanınızdır.

HPOS gecisini hemen yapmali miyim?#

Öncelikle bir hazırlık ortamında test etmenizi öneririm. HPOS, özellikle on binlerce siparişi olan mağazalarda admin panelini belirgin biçimde hızlandırır, ancak eski veya bakımsız bazı eklentiler henüz tam uyumlu olmayabilir. wp wc hpos status komutuyla uyumluluğu kontrol edin, tam yedek alın ve önce senkronizasyon modunda çalıştırın. Her şey sorunsuzsa yeni tablolara tam geçiş yapabilirsiniz.

Cart fragments'i kapatmak sepetimi bozar mi?#

Doğru yapılırsa bozmaz. Yukarıdaki yöntem, sepet fragment script'ini yalnızca sepet boşken ve sepet/ödeme sayfaları dışındayken kaldırır. Müşteri sepete ürün eklediği anda özellik yeniden devreye girer, dolayısıyla alışveriş akışı etkilenmez. Kazanç, boş sepetle gezen anonim ziyaretçilerin her sayfada gereksiz bir AJAX isteği tetiklememesidir; bu da özellikle yoğun trafikte sunucu yükünü düşürür.

Gorsel optimizasyonu icin mutlaka bir eklenti gerekir mi?#

Hayır, zorunlu değildir. Görselleri sunucuda cwebp gibi araçlarla toplu dönüştürüp WordPress'in yerleşik tembel yükleme özelliğinden yararlanabilirsiniz. Ancak sürekli yeni ürün ekleyen bir mağazada, her yüklenen görseli otomatik WebP'ye çevirip doğru boyutlarda üreten bir eklenti işinizi kolaylaştırır. Önemli olan üç ilkedir: doğru boyut, modern format ve ekran dışındaki görselleri geciktirmek.

Kapanış#

WooCommerce performansı tek bir ayarla değil, katmanlı bir yaklaşımla kazanılır. Doğru önbellek istisnalarıyla başlar, Redis object cache ile veritabanı yükünü düşürür, düzenli temizlikle tabloları hafif tutar, gereksiz AJAX ve ağır görselleri kısar ve HPOS ile sipariş yönetimini modern altyapıya taşırsınız. Bu adımların her biri tek başına fark yaratır; birlikte uygulandığında ise hem ziyaretçi deneyimi hem de dönüşüm oranınız belirgin biçimde iyileşir. Unutmayın, e-ticarette her ek saniye doğrudan terk edilen sepet demektir.

Bu optimizasyonların çoğu, altında güçlü ve doğru yapılandırılmış bir sunucu olduğunda gerçek değerini gösterir. Redis'in hazır geldiği, WooCommerce'e göre ayarlanmış WordPress hosting paketlerimiz küçük ve orta ölçekli mağazalar için ideal bir başlangıçtır; yüksek trafikli mağazalar içinse tam kaynak kontrolü sunan VDS ve sanal sunucu çözümlerimize göz atabilirsiniz. Kurulum ve ince ayarları bize bırakmak isterseniz sunucu yönetimi hizmetimiz, güvenli geçişler için yedekleme çözümlerimiz ve mağazanızı taşımak için site taşıma ekibimiz yanınızda. Hangi paketin size uygun olduğundan emin değilseniz, uzman ekibimiz ihtiyacınıza en uygun altyapıyı belirlemek için sizinle memnuniyetle iletişime geçer.