WooCommerce Hız Optimizasyonu: Yavaş E-Ticaret Sitesini Hızlandırma

WooCommerce’i yavaşlatan şey çoğu zaman kötü kod değil, yapısıdır. Bir blog sitesinin aksine WooCommerce kişiselleştirilmiş ve durum taşıyan bir uygulamadır. Bu da onu doğası gereği daha ağır kılar.

Bu rehberde önce WooCommerce’in neden yavaş olduğunu yapısal sebepleriyle açıklıyorum. Ardından cart fragments’tan önbelleğe, görselden veritabanına ve hostinge kadar her katmanı ölçülebilir çözümlerle ele alıyorum. Amacım genel tavsiye değil; mağazanızda hangi katmanın yavaşlattığını bulup düzeltebileceğiniz somut bir yol haritası vermek.

WordPress hızının temel katmanlarını (Core Web Vitals, önbellekleme, görsel, hosting) daha geniş çerçevede ele aldığım WordPress site hızı ana rehberi bu yazının üst başlığıdır. Buradaki her teknik, o rehberdeki genel prensiplerin WooCommerce’e özel uygulamasıdır.

Hız, e-ticaret SEO’sunun beş katmanından yalnızca biridir. Teknik altyapı, kategori ve ürün sayfaları ile yapısal verinin hangi sırayla ele alınacağını e-ticaret SEO ana rehberinde topladım.

WooCommerce Neden Yavaştır? Yapısal Sebepler

WooCommerce’i bir blog temasıyla kıyaslamak hatalıdır. Blog sayfası statiktir: içerik değişmez, herkese aynı HTML gösterilir, tam sayfa önbellek sorunsuz çalışır. E-ticaret sitesi ise doğası gereği kişiselleştirilmiş ve durum taşıyan bir uygulamadır.

Oturum Yönetimi

WooCommerce her ziyaretçi için woocommerce_sessions tablosunda bir oturum kaydı tutar. Ziyaretçi sepete ürün eklemese bile birçok yapılandırmada oturum başlatılır. Bu, veritabanına yazma işlemi demektir ve yazma işlemleri önbelleklenemez. Trafik arttığında bu tablo hızla şişer.

Meta Tabanlı Veri Modeli

Bir ürünün fiyatı, stoğu, SKU’su, ağırlığı, boyutları ve indirim tarihi hepsi wp_postmeta tablosunda ayrı satırlar olarak durur. 1.000 ürünlü bir mağazada bu tablo kolaylıkla 80.000 satırın üzerine çıkar.

“Fiyata göre sırala” veya “stokta olanlar” filtresi çalıştığında MySQL bu tablo üzerinde çoklu JOIN yapar. İndeksleme zayıfsa sorgu süresi saniyelerle ölçülür.

Varyasyonlu Ürünler

Her varyasyon ayrı bir post kaydıdır. 6 renk çarpı 5 beden, yani 30 varyasyon demek, tek ürün için 31 post kaydı ve yüzlerce meta satırı demektir. Ürün sayfası açıldığında WooCommerce tüm varyasyonların fiyat, stok ve görsel bilgisini JSON olarak sayfaya gömer. Varyasyon sayısı yüksek ürünlerde bu JSON tek başına yüzlerce kilobayt olabilir.

Eklenti Çokluğu

Kargo entegrasyonu, sanal POS, e-fatura, XML ürün aktarımı, terk edilen sepet, popup, chat, stok bildirimi. Tipik bir Türkiye mağazasında 30 ile 45 arası aktif eklenti görüyorum. Sorun eklenti sayısı değil, her eklentinin her sayfada çalışmasıdır. E-fatura eklentisinin ana sayfada CSS yüklemesi için hiçbir neden yoktur ama varsayılan davranış budur.

Admin-ajax Yükü

Stok kontrolü, sepet güncelleme, mini sepet yenileme, canlı arama hepsi admin-ajax.php üzerinden geçer. Bu dosya WordPress çekirdeğini tam olarak yükler. Yani basit bir “sepette kaç ürün var” sorusunun cevabı için tüm WordPress ve tüm eklentiler belleğe alınır.

Bu yapısal gerçekleri kabul etmeden yapılan optimizasyon, semptom tedavisidir. Doğru kurgu, sağlam bir SEO uyumlu e-ticaret altyapısı ile başlar. Sonradan eklenen önbellek katmanı yapısal hatayı kapatmaz.

Hızınızı Ölçün: Hangi Sayfalar Test Edilmeli

En sık gördüğüm hata, ana sayfada PageSpeed 92 puan alıp “sitem hızlı” demektir. Ana sayfa genellikle bir mağazanın en az kritik sayfasıdır. Dönüşüm ana sayfada olmaz; kategori ve ürün sayfasında başlar, sepet ve ödemede biter.

Her mağazada en az beş sayfa tipini ayrı ayrı ölçüyorum:

Ölçüm yaparken saha verisi ile laboratuvar verisi ayrımını net tutun. Bu iki veri tipini karıştırmak, WooCommerce hız optimizasyonunda gördüğüm en yaygın hatadır. Konuyu Core Web Vitals nedir rehberinde ayrıntılı açıkladım.

Ayrıca ölçümü mobil modda ve oturum açmadan yapın. Yönetici olarak giriş yaptığınızda WordPress admin bar yükler, önbellek eklentileri devre dışı kalır ve sonuç tamamen yanıltıcı olur. Sepet sayfasını ölçerken sepette en az 3 ürün bulundurun; boş sepet ölçümü anlamsızdır.

Cart Fragments Sorunu ve Çözümü

WooCommerce’in en bilinen performans sorunu wc-cart-fragments.js dosyasıdır. Mantığı şudur: sayfa önbellekten servis edilse bile mini sepetin güncel görünmesi gerekir. Bu yüzden WooCommerce, sayfa yüklendikten sonra admin-ajax.php?wc-ajax=get_refreshed_fragments çağrısı yapar ve sepet HTML parçalarını taze olarak çeker.

Sorun, bu çağrının her sayfada, her ziyaretçi için çalışmasıdır. Blog yazısını okuyan, iletişim sayfasına bakan, hakkımızda sayfasını açan herkes için de çalışır. Ve admin-ajax.php önbelleklenemez; her çağrı tam bir WordPress önyüklemesi tetikler.

Paylaşımlı hostingde bu çağrının 800 ms ile 2 saniye arasında sürdüğünü sık görüyorum. Sayfa görsel olarak hazır olsa bile tarayıcı hâlâ meşguldür; bu doğrudan INP ve etkileşim gecikmesi olarak geri döner.

Çözüm 1: Sepet Boşken Fragments’ı Kapatın

En güvenli ve en etkili yaklaşım budur. Sepette ürün yoksa güncellenecek bir şey de yoktur.

/**
 * Sepet boşsa cart fragments script'ini kaldır.
 * child theme functions.php veya site-specific eklentiye eklenir.
 */
add_action( 'wp_enqueue_scripts', 'bd_woo_fragments_kontrol', 99 );
function bd_woo_fragments_kontrol() {

    if ( is_admin() ) {
        return;
    }

    if ( ! function_exists( 'WC' ) || is_null( WC()->cart ) ) {
        return;
    }

    // Sepet, ödeme ve hesabım sayfalarında ASLA kaldırma
    if ( is_cart() || is_checkout() || is_account_page() ) {
        return;
    }

    // Sepette ürün varsa kaldırma; mini sepet güncel kalmalı
    if ( WC()->cart->get_cart_contents_count() > 0 ) {
        return;
    }

    wp_dequeue_script( 'wc-cart-fragments' );
}

Bu kod, ziyaretçilerin büyük çoğunluğu için (sepeti boş olanlar) fazladan AJAX çağrısını ortadan kaldırır ama sepete ürün ekleyen kullanıcı için mini sepeti bozmaz.

Çözüm 2: Fragments’ı Geciktirin

Tamamen kaldırmak istemiyorsanız, çağrıyı ilk etkileşime kadar erteleyebilirsiniz. Script’e defer özelliği ekleyerek kritik yükleme yolundan çıkarabilirsiniz:

add_filter( 'script_loader_tag', 'bd_fragments_defer', 10, 3 );
function bd_fragments_defer( $tag, $handle, $src ) {
    if ( 'wc-cart-fragments' === $handle ) {
        return str_replace( ' src', ' defer src', $tag );
    }
    return $tag;
}

Yapmayın: Bazı rehberler wc-cart-fragments‘ı koşulsuz olarak tüm sitede kaldırmayı önerir. Bunu yaparsanız kullanıcı sepete ürün ekler, mini sepette sayı güncellenmez ve kullanıcı ürünün eklenmediğini sanır. Bu, hız kazancından çok daha pahalıya mal olan bir dönüşüm kaybıdır.

Önbellekleme Stratejisi: Neyi Önbelleğe Alırsınız, Neyi Asla Almazsınız

WooCommerce’te yanlış önbellek yapılandırması, yavaşlıktan daha tehlikelidir. Sepet sayfasını tam sayfa önbelleğe alırsanız, A kullanıcısının sepeti B kullanıcısına gösterilir. Bu bir performans sorunu değil, veri sızıntısı ve sipariş hatasıdır.

Uygulamada dikkat edilecek en kritik nokta, çerez bazlı bypass kuralıdır. woocommerce_items_in_cart veya woocommerce_cart_hash çerezlerinden biri varsa o istek önbellekten servis edilmemelidir. Ciddi önbellek eklentileri ve sunucu tarafı önbellekler bu kuralı destekler; yapılandırmada aktif olduğunu doğrulayın.

Nesne önbelleği (object cache) ayrı bir katmandır ve WooCommerce için en yüksek getirili tek müdahale genelde budur. Redis veya Memcached ile kurulan nesne önbelleği, tekrarlanan veritabanı sorgularının sonucunu bellekte tutar. Sepet ve ödeme sayfaları tam sayfa önbelleğe alınamaz ama nesne önbelleğinden fazlasıyla faydalanır. Hangi önbellek eklentisinin hangi sunucuya uygun olduğunu önbellek eklentileri karşılaştırmasında ayrıntılı ele aldım.

Ürün Görselleri Optimizasyonu

E-ticaret sitelerinde toplam sayfa ağırlığının çoğu görsellerdir ve LCP öğesi neredeyse her zaman bir ürün görselidir. Bu yüzden görsel optimizasyonu, WooCommerce’te en yüksek getirili işlerden biridir.

Kaynak boyutunu kontrol edin. En sık gördüğüm hata, tedarikçiden gelen 3000×3000 piksel, 4 MB’lık ürün görsellerinin doğrudan yüklenmesidir. Yükleme öncesi maksimum 1600 piksel kenar ve 200 ile 300 KB arası hedefleyin.

Modern format kullanın. Aynı görsel kalitesinde WebP, JPEG’e kıyasla belirgin şekilde küçüktür. Dönüşümü sunucu tarafında yapan bir eklenti veya CDN kullanın. Görsel formatları, lazy loading ve LCP önceliklendirmesinin tüm detaylarını görsel optimizasyonu: WebP ve AVIF rehberinde ele aldım.

Doğru boyutları tanımlayın. Kategori sayfasında 300 piksel genişlikte gösterilen bir görselin 800 piksel yüklenmesi saf israftır. WooCommerce’in katalog, tekil ürün ve galeri küçük resmi boyutlarını tema ihtiyacına göre sabitleyin.

Varyasyon görselleri özel bir sorundur. 30 varyasyonlu bir üründe WooCommerce tüm varyasyonların görsel URL’lerini ve boyut bilgilerini JSON olarak sayfaya gömer; bu JSON 200 KB’ı aşabilir. Çözüm: varyasyon sayısını gerçekten gerekli olanla sınırlamak ve çok varyasyonlu ürünlerde varyasyon verisini AJAX ile talep üzerine yükleyen bir yaklaşıma geçmek.

Veritabanı Optimizasyonu

WooCommerce veritabanı zamanla kendiliğinden şişer. Bakımı yapılmayan iki yıllık bir mağazada wp_options ve wp_postmeta tablolarının yüzlerce megabayta çıktığını görüyorum.

Transient Birikimi

Transient’ler geçici verilerdir ve wp_options tablosunda durur. Süresi dolan transient’ler otomatik silinmez; hiç okunmayan binlerce süresi geçmiş kayıt tabloda birikir. WP-CLI erişiminiz varsa temizlik tek satırdır:

wp transient delete --expired
wp wc tool run clear_transients   # WooCommerce'e özel transient'ler

Autoload Sorunu

wp_options tablosundaki autoload = yes işaretli kayıtlar her sayfa yüklemesinde belleğe alınır. Sağlıklı bir sitede bu toplam 1 MB’ın altında olmalıdır. Kaldırılan eklentilerden kalan büyük ayar dizileri bu değeri 5 ile 10 MB’a çıkarabilir; bu, her istekte ödenen sabit bir vergidir.

-- En ağır autoload kayıtlarını bulun
SELECT option_name, LENGTH(option_value) AS boyut
FROM wp_options
WHERE autoload = 'yes'
ORDER BY boyut DESC
LIMIT 25;

Sipariş Tabloları (HPOS)

WooCommerce artık siparişleri wp_posts yerine kendi özel tablolarında saklayabilir. Bu özelliğin adı High-Performance Order Storage (HPOS). Sipariş hacmi yüksek mağazalarda bu, yönetim panelindeki sipariş listesini ve raporları belirgin şekilde hızlandırır çünkü sorgular artık post/postmeta JOIN’lerinden geçmez. Geçiş öncesi tüm eklentilerin HPOS uyumluluğunu doğrulayın ve mutlaka yedek alın.

Her veritabanı müdahalesinden önce tam yedek alın ve mümkünse önce test ortamında deneyin. Geri alınamayan tek katman veritabanıdır.

Eklenti Denetimi: Hangileri Ağır, Nasıl Ölçülür

“Hangi eklenti yavaşlatıyor?” sorusunun cevabı tahminle değil ölçümle bulunur. Bunun için kullandığım araç Query Monitor‘dür.

Query Monitor’ü kurup yönetici olarak siteyi gezdiğinizde şunları görürsünüz: toplam veritabanı sorgu sayısı ve süresi, sorguların eklenti bazında dağılımı, en yavaş tekil sorgular, PHP bellek kullanımı ve sayfaya yüklenen tüm CSS/JS dosyaları.

Referans değerler: sağlıklı bir WooCommerce ürün sayfası 60 ile 120 sorgu aralığındadır. 300 sorguyu geçen bir sayfa, kaynağı ne olursa olsun sorunludur. 500’ü geçiyorsa eklenti çakışması veya kötü yazılmış bir döngü vardır.

Denetim yöntemi şu: eklentileri test ortamında tek tek devre dışı bırakıp her adımda kategori ve ürün sayfasını ölçün. Bir eklenti 40 sorgu ve 300 ms getiriyorsa, sağladığı iş değeriyle bu maliyeti karşılaştırın. “Üç eklentinin işini yapan tek eklenti” tercihi neredeyse her zaman doğrudur.

Hosting ve Altyapı

Yazılım tarafında ne yaparsanız yapın, sunucu yetersizse tavana çarparsınız. WooCommerce’in önbelleklenemeyen sayfaları doğrudan PHP ve MySQL performansına bağlıdır.

PHP sürümü ve OPcache. Güncel PHP sürümleri, eskilere göre istek başına belirgin şekilde daha az bellek ve CPU kullanır. Desteklenen en güncel sürümde çalışın ve OPcache’in aktif olduğunu Site Sağlığı ekranından doğrulayın. PHP bellek limitini WooCommerce için en az 256 MB’a çıkarın; ağır eklenti setlerinde 512 MB gerekebilir.

Nesne önbelleği. WooCommerce için en yüksek getirili altyapı yatırımı budur. Redis kurulumundan sonra sepet ve ödeme gibi tam sayfa önbelleğe alınamayan sayfalarda bile TTFB’nin yarıya indiğini düzenli olarak ölçüyorum.

Gerçek cron. WordPress’in varsayılan wp-cron.php mekanizması sayfa ziyaretleriyle tetiklenir. Bir ziyaretçi sayfayı açtığında zamanlanmış görev de çalışabilir ve o kullanıcı beklemeyi yaşar. Sunucu tarafında gerçek bir cron tanımlayıp wp-config.php içinde DISABLE_WP_CRON sabitini true yapın.

Paylaşımlı hosting sınırı. Aylık birkaç yüz siparişi geçen bir mağazada paylaşımlı hosting artık uygun değildir. Sorun genelde tepe trafikte ortaya çıkar: kampanya saatinde site erişilemez hale gelir. Bu ölçekte VPS veya yönetilen WooCommerce hosting gerekir. Hosting maliyetini altyapı yatırımının parçası olarak görün; paket ve fiyatlar sayfasında bu kalemleri ayrıştırıyorum.

Ölçülebilir Hedefler

“Site hızlandı” ifadesi ölçülebilir değildir. Her projede baştan hedef koyup sonuçları bu tabloya göre raporluyorum:

Ölçüm disiplini: her müdahaleden önce ve sonra aynı koşullarda ölçün. Aynı sayfa, aynı cihaz profili, aynı bağlantı hızı, oturum kapalı. Tek seferde birden fazla değişiklik yaparsanız hangisinin işe yaradığını asla bilemezsiniz. Değişiklikleri teker teker uygulayın, teker teker ölçün, kaydedin.

Sıkça Sorulan Sorular

Bu yazıları da okumak isteyebilirsiniz ...

Sağlık Turizmi Web Sitesi: Yetki, Hasta Akışı ve Ülke Stratejisi

Diş Kliniği Web Sitesi: Yerel Görünürlük ve Randevu Kurulumu

Estetik Klinik Web Sitesi: Galeri, İşlem Sayfaları ve Güven Kurulumu

Saç Ekimi Kliniği Web Sitesi: Çok Dilli ve Mevzuata Uygun Kurulum

Yazar Hakkında

Barış Dayak

2014'ten bu yana web tasarım, WordPress ve SEO & AI görünürlük alanlarında 500'den fazla işletmeye hizmet veriyorum.