WooCommerce İçin Hosting Seçimi: Performans ve Kaynak Rehberi

WooCommerce için hosting seçiminde belirleyici ölçüt, önbelleklenemeyen sayfaların yüküdür. Sepet, ödeme ve üyelik sayfaları her ziyaretçi için farklı içerik ürettiğinden önbellekten sunulamaz; her istek PHP ve MySQL çalıştırır. Bu nedenle WooCommerce mağazası; ayrılmış CPU, en az 2-4 GB RAM, NVMe disk, PHP 8.x ve Redis object cache desteği olan bir altyapı ister. Statik bloglar için yeterli olan paketler burada tıkanır.

Türkiye’de e-ticarete başlayanların büyük bölümü ilk mağazasını WooCommerce ile kuruyor: WordPress zaten biliniyor, eklenti ekosistemi devasa, aylık komisyon yerine kendi altyapınıza sahip oluyorsunuz. Ama WooCommerce teknik olarak bir WordPress eklentisidir; yani mağazanız, aslında blog yayınlamak için tasarlanmış bir sistemin üzerine kurulmuştur. Bu mimari doğru altyapıda çok iyi çalışır, yanlış altyapıda ise en kritik anda (ödeme adımında) çöker.

Bu rehber, genel bir e-ticaret hosting listesi değil. WooCommerce’e özgü kaynak davranışını, mağazanızı gerçekte neyin yavaşlattığını ve hangi ölçekte hangi sunucunun gerektiğini anlatıyor.

WooCommerce Neden Normal Bir WordPress Sitesinden Ağırdır?

Sıradan bir WordPress blogunda bir ziyaretçi sayfayı açtığında, iyi yapılandırılmış bir sistemde sunucu neredeyse hiç çalışmaz. Sayfa daha önce üretilip önbelleğe alınmıştır; sunucu hazır HTML dosyasını gönderir ve işi biter. Yüz ziyaretçi de gelse bin ziyaretçi de gelse maliyet aynıdır.

WooCommerce’te bu denklem bozulur. Mağazanızda dört tür sayfa vardır ve bunların davranışı birbirinden tamamen farklıdır:

• Ana sayfa, kategori ve ürün sayfaları: Önbelleğe alınabilir. Bunlar mağazanın kolay kısmıdır.
• Sepet sayfası: Her ziyaretçinin sepeti farklıdır, önbelleğe alınamaz.
• Ödeme (checkout) sayfası: Kişiye özeldir, kargo ve vergi hesaplaması yapar, ödeme sağlayıcısıyla konuşur. Kesinlikle önbelleğe alınamaz.
• Hesabım ve sipariş takibi: Oturum açmış kullanıcıya özeldir, önbelleğe alınamaz.

Buradaki kritik nokta şudur: mağazanızın kapasitesini ana sayfanın hızı değil, ödeme sayfasının yükü belirler. Bir kampanya duyurusu yaptığınızda ve aynı anda 200 kişi sepete gidip ödeme adımına geçtiğinde, sunucunuz 200 ayrı PHP işlemini eş zamanlı çalıştırmak ve her biri için veritabanına yüzlerce sorgu göndermek zorunda kalır. Paylaşımlı bir pakette PHP işlem sayısı ve eş zamanlı bağlantı limitleri buna izin vermiyorsa, ziyaretçiler ödeme ekranında zaman aşımı hatası görür. Yani trafiği kaçırmazsınız, doğrudan satışı kaçırırsınız.

WooCommerce’te Kaynak Tüketiminin Gerçek Kaynakları

1. Veritabanı: Otomatik Yüklenen Seçenekler ve Sipariş Tablosu

WooCommerce ürün, varyasyon ve sipariş verisini geleneksel olarak WordPress’in yazı ve yazı-meta tablolarında tutar. Tek bir üründe onlarca meta satırı olabilir; 3.000 ürünlü bir katalogda meta tablosu yüz binlerce satıra ulaşır. Buna geçici veriler, terk edilmiş sepet oturumları ve eklentilerin biriktirdiği kayıtlar eklendiğinde veritabanı şişer ve her sorgu yavaşlar.

Sinsi bir başka sorun otomatik yüklenen seçeneklerdir: WordPress her sayfa yükünde bu satırların tamamını belleğe okur. Kötü yazılmış bir eklenti buraya megabaytlarca veri yazarsa, her sayfa aynı veriyi tekrar tekrar okur. WooCommerce’in yeni sürümleriyle gelen ayrı sipariş tablosu (HPOS) bu yükü ciddi biçimde azaltır; eski yapıdaysanız eklenti uyumluluğunu kontrol edip geçmek en kârlı adımlardan biridir.

2. WP-Cron ve Action Scheduler

WordPress’in zamanlayıcısı gerçek bir sistem görevi değildir. Sayfa ziyaretleriyle tetiklenir; yani bir ziyaretçi sitenize girdiğinde, sırada bekleyen görev varsa o ziyaretçinin isteği bu görevi çalıştırmak için kullanılır. WooCommerce ise bu kuyruğu sürekli doldurur: sipariş durumu güncellemeleri, stok senkronizasyonu, e-posta gönderimleri, abonelik yenilemeleri ve Action Scheduler üzerinden yürüyen onlarca arka plan işi.

Sonuç, mağaza sahiplerinin en çok şikâyet ettiği o açıklanamayan yavaşlıktır: site normalde hızlıdır ama bazen bir sayfa 8 saniyede açılır, çünkü o talihsiz ziyaretçi kuyrukta bekleyen görevleri de sırtlamıştır. Çözüm basittir: WP-Cron’u devre dışı bırakıp sunucu tarafında dakikalık gerçek bir cron görevi tanımlamak.

3. admin-ajax.php

Sunucu erişim kayıtlarına baktığınızda en çok çağrılan dosyanın admin-ajax.php olduğunu görüyorsanız yalnız değilsiniz. Bu dosya, eklentilerin tarayıcıdan sunucuya arka planda istek atmak için kullandığı klasik kapıdır. Canlı sepet parçacıkları, ziyaretçi sayaçları, geri sayım sayaçları ve sohbet eklentileri birkaç saniyede bir bu kapıyı çalar. Her çağrı, önbelleği tamamen atlayan ve WordPress’i baştan yükleyen tam bir PHP isteğidir. Sitenizde aynı anda 50 kişi varsa ve her biri 5 saniyede bir istek atıyorsa, saniyede 10 istek yalnızca bu parçacıklar için harcanır.

4. Eklenti Şişmesi

WooCommerce mağazalarında eklenti sayısı sinsi biçimde artar: kargo, muhasebe, pazaryeri aktarımı, kupon, varyasyon galerisi, sayfa üreticisi, form. Her biri kendi CSS ve JavaScript dosyasını yükler, kimisi ana ürün sorgusuna filtre ekler, kimisi her açılışta dış bir servise bağlanmaya çalışır. Sorun eklenti sayısı değil, her sayfada çalışan kalitesiz eklentidir. Ölçmeden karar vermeyin: bir sorgu izleme eklentisi hangi eklentinin kaç sorgu ve kaç milisaniye tükettiğini gösterir.

Ürün Sayısı ve Trafiğe Göre Kaynak Önerisi

Aşağıdaki tablo, Türkiye’deki tipik WooCommerce mağazalarının davranışına dayanan pratik bir başlangıç haritasıdır. Kesin bir formül değildir; eklenti yükünüz ağırsa bir üst basamağı düşünün.

Mağaza Ölçeği	Tipik Profil	RAM	CPU	Önerilen Tür
Küçük katalog	50-300 ürün, günde 200-800 ziyaretçi, günde birkaç sipariş	1-2 GB	1-2 çekirdek (paylaşımlı havuz)	LiteSpeed ve NVMe tabanlı WordPress hosting
Orta ölçek	300-3.000 ürün, günde 2.000-8.000 ziyaretçi, günde onlarca sipariş, kargo ve muhasebe entegrasyonu	4-8 GB	2-4 ayrılmış çekirdek	Bulut sunucu (yönetimli kurulum)
Yüksek trafik	3.000+ ürün, kampanya günlerinde eş zamanlı yüzlerce sepet, pazaryeri senkronizasyonu, B2B fiyat listeleri	16 GB ve üzeri	6-8+ ayrılmış çekirdek	Yüksek kaynaklı bulut sunucu veya VDS / fiziksel sunucu; veritabanı ayrı sunucuda

Ürün sayısı tek başına yanıltıcıdır: 10.000 ürünlü ama günde 100 ziyaretçi alan bir toptancı kataloğu, 200 ürünlü ama kampanyayla anlık binlerce kişiyi ödeme sayfasına yollayan bir mağazadan daha az kaynak ister. Ürün sayısı veritabanı boyutunu, eş zamanlı ziyaretçi ise CPU ve RAM ihtiyacını belirler.

WooCommerce’i Yavaşlatan Sebepler ve Çözümleri

Belirti / Sebep	Neden Olur?	Çözüm
Ödeme sayfası çok yavaş	Önbelleğe alınamaz; her istekte PHP ve veritabanı çalışır	Ayrılmış CPU, Redis object cache, PHP 8.x, kargo eklentilerinin dış servis çağrılarını sınırlama
Site bazen rastgele 5-10 saniye takılıyor	WP-Cron görevleri ziyaretçi isteğinin üstüne biniyor	WP-Cron’u kapatıp sunucu tarafında dakikalık gerçek cron tanımlama
Erişim kayıtlarında admin-ajax.php seli	Canlı sepet parçacığı, sayaç ve sohbet eklentileri sürekli istek atıyor	Gereksiz parçacıkları kapatma, sepet parçacığını yalnızca gereken sayfada çalıştırma
Yönetim paneli sürünüyor	Şişmiş sipariş ve meta tabloları, otomatik yüklenen seçenekler	Veritabanı temizliği, HPOS sipariş tablosuna geçiş, Action Scheduler kayıtlarını budama
Yüksek CPU, sık sık kaynak limiti uyarısı	Bot taramaları ve kategori filtrelerinin ürettiği önbelleklenemeyen sorgular	Katmanlı filtre sayfalarını dizine kapatma, bot trafiğini sınırlama, kaynak yükseltme
Ürün görselleri sayfayı ağırlaştırıyor	Orijinal boyutta yüklenen büyük JPEG dosyaları	WebP dönüşümü, doğru boyutta üretim, geç yükleme (lazy load)
Sipariş e-postaları müşteriye ulaşmıyor	Web sunucusundan doğrudan gönderim, SPF ve DKIM eksikliği	Siparişleri gerçek bir e-posta altyapısı üzerinden SMTP ile gönderme

WooCommerce Performans Kontrol Listesi

Aşağıdaki adımları sırayla uygulayın. Çoğu mağaza, sunucu yükseltmesine hiç gerek kalmadan bu listeyle belirgin bir hız kazanır; kazanmıyorsa kaynak sorunu gerçektir ve yükseltme kararı artık tahmine değil ölçüme dayanır.

1. PHP sürümünü güncelleyin. Kontrol panelindeki PHP sürüm seçicisinden PHP 8.1 ve üzerine geçin. PHP 7.4’ten 8.x’e geçiş, tek satır kod değiştirmeden istek başına işlem süresini belirgin biçimde düşürür. Geçmeden önce mutlaka yedek alın ve eklenti uyumluluğunu bir deneme ortamında test edin.
2. Redis object cache’i etkinleştirin. Sunucuda Redis’i açın, WordPress tarafında object cache eklentisini kurun ve bağlantıyı doğrulayın. Tekrar eden ürün ve seçenek sorguları artık bellekten karşılanır; yönetim paneli ve ödeme adımı gözle görülür şekilde hızlanır.
3. LiteSpeed Cache’i WooCommerce için doğru kurun. Sayfa önbelleğini açın, tarayıcı önbelleğini etkinleştirin, CSS ve JavaScript birleştirme ayarlarını tek tek test ederek açın. LSCache’in WooCommerce ile uyumlu çalışan sepet parçacığı desteği vardır; bunu açık bırakın.
4. Sepet, ödeme ve hesabım sayfalarını önbellekten hariç tutun. Bu sayfaların yollarını önbellek eklentisinin hariç tutulanlar listesine ekleyin ve oturum açmış kullanıcılar için önbelleklemeyi kapatın. Bu adımı atlamak, bir müşterinin sepetinin başka bir müşteriye görünmesine yol açabilir.
5. WP-Cron’u gerçek cron’a çevirin. Yapılandırma dosyasında WP-Cron’u devre dışı bırakın ve kontrol panelinden dakikada bir çalışan bir cron görevi tanımlayın. Ardından Action Scheduler kuyruğunda birikmiş, tamamlanmış ve başarısız kayıtları temizleyin.
6. Veritabanını temizleyin. Yazı revizyonlarını, çöp kutusundaki ürünleri, süresi dolmuş geçici verileri, terk edilmiş sepet oturumlarını ve kaldırılmış eklentilerden kalan seçenekleri silin. Ardından otomatik yüklenen seçeneklerin toplam boyutunu ölçün; 1 MB’ı aşıyorsa şişkinliğin kaynağını bulun.
7. Görselleri optimize edin. Ürün fotoğraflarını yüklemeden önce doğru boyuta getirin, WebP formatına dönüştürün ve ilk ekranın altındaki görsellerde geç yüklemeyi açın. Katalog sayfalarında 20 ürünün her birinin 800 KB’lık görsel taşıması, tek başına sayfayı 16 MB yapar.
8. Eklentileri denetleyin. Bir sorgu izleme eklentisiyle sayfa başına sorgu sayısını ve en yavaş eklentileri ölçün. Kullanılmayanları kapatmakla yetinmeyin, tamamen silin; pasif eklenti bile güncelleme kontrolüyle yük üretir.
9. Sipariş e-postalarını SMTP’ye taşıyın. WooCommerce’in varsayılan gönderimi yerine kimlik doğrulamalı SMTP kullanın; SPF ve DKIM kayıtlarını tanımlayın. Sipariş onayı spam klasörüne düşen mağaza, satışını iade taleplerine çevirir.
10. Ölçün ve tekrar edin. Her değişiklikten sonra sunucu cevap süresini ve ödeme sayfasının açılma süresini kaydedin. Ölçmediğiniz iyileştirme, yaptığınızı sandığınız iyileştirmedir.

Ödeme Güvenliği: PCI Sorumluluğu Kimde?

WooCommerce mağazası kuran herkesin kafasını karıştıran konulardan biri kart verisi güvenliğidir. Netleştirelim: PCI DSS uyumluluğu, kart verisini işleyen ve saklayan tarafın sorumluluğudur. Türkiye’de yaygın kullanım, ödeme kuruluşlarının ya da bankaların sanal POS sayfalarına yönlendirme veya güvenli bir çerçeve içinde gömme şeklindedir. Bu modelde müşterinin kart numarası hiçbir zaman sizin sunucunuza düşmez; doğrudan ödeme kuruluşuna gider. Dolayısıyla bir hosting sağlayıcısının “PCI sertifikalıyız” demesi de, sizin mağazanız için PCI yükümlülüğü üstlendiği anlamına gelmez.

Size düşen sorumluluk daha somuttur: tüm site trafiğini SSL sertifikası ile şifrelemek, WordPress ile eklentileri güncel tutmak, güçlü parola ve iki adımlı doğrulama kullanmak, düzenli yedek almak. Bir mağazanın hacklenme sebebi neredeyse hiçbir zaman ödeme altyapısı değildir; güncellenmemiş bir eklenti ya da zayıf bir yönetici parolasıdır.

WooCommerce İçin Altyapıda Nelere Bakmalı?

Paket karşılaştırırken disk alanı ve “sınırsız trafik” gibi başlıkların ötesine geçin. WooCommerce özelinde şunlar belirleyicidir:

• LiteSpeed ve LSCache: Sunucu düzeyinde çalışan önbellek, PHP’yi hiç uyandırmadan sayfayı sunar. WooCommerce için hazır kural setleriyle sepet parçacığını bozmadan çalışır.
• Redis object cache: Sunucuda hazır olması, mağazanın en büyük performans kazancını kutudan çıkar çıkmaz almanızı sağlar.
• NVMe depolama: Veritabanı ağırlıklı bir uygulamada disk gecikmesi doğrudan sipariş süresine yansır.
• CloudLinux kaynak izolasyonu: Paylaşımlı bir sunucuda komşu bir sitenin ani yükünün sizin ödeme sayfanızı etkilememesini sağlar; ayrıca kendi kaynak kullanımınızı kontrol panelinden görebilirsiniz.
• PHP sürüm seçici: Yeni sürüme geçişi ve gerektiğinde geri dönüşü tek tıkla yapabilmek, canlı mağazada risk almadan test etmek demektir.
• Günlük yedekleme ve ücretsiz SSL: Sipariş verisi geri alınamaz; bir eklenti güncellemesinin bozduğu mağazayı dünkü yedekten geri döndürebilmek pazarlık konusu değildir.
• Büyüme yolu: Mağazanız beklediğinizden hızlı büyürse, aynı sağlayıcı içinde kaynaklarınızı kesintisiz artırabilmek taşınma stresinden kurtarır.
• Uptime ve destek: E-ticarette kesinti, doğrudan kayıp cirodur. %99.9 çalışma süresi taahhüdü ve 7/24 ulaşılabilen bir teknik ekip, kampanya gecesinde en kıymetli özelliktir.

Kısaca: WooCommerce mağazanız için doğru hosting paketi, bugünkü trafiğinizi değil, en yoğun kampanya saatinizdeki eş zamanlı ödeme yükünüzü kaldırabilen pakettir. Fiyat farkı genellikle tek bir kaçırılmış kampanyanın cirosundan azdır.

Sıkça Sorulan Sorular

WooCommerce için paylaşımlı hosting yeterli mi?

Katalogu 200-300 ürünü geçmeyen, günde birkaç yüz ziyaretçi alan ve aynı anda onlarca kişinin sepette olmadığı mağazalar için iyi yapılandırılmış bir paylaşımlı hosting fazlasıyla yeterlidir. Burada belirleyici olan paketin adı değil, altındaki teknolojidir: LiteSpeed, NVMe disk, PHP 8.x, Redis object cache ve CloudLinux kaynak izolasyonu varsa paylaşımlı bir paket şaşırtıcı derecede iyi çalışır. Kampanya günlerinde kilitlenme yaşamaya başladığınızda bulut sunucuya geçme vakti gelmiş demektir.

WooCommerce ne kadar RAM ister?

WooCommerce’in kendisi görece hafiftir; RAM’i asıl tüketen eklentiler, arka plan görevleri ve eş zamanlı ziyaretçi sayısıdır. Küçük bir mağaza 1-2 GB ile idare eder. Orta ölçekli, birkaç bin ürünlü ve düzenli sipariş alan bir mağaza için 4 GB rahat bir başlangıçtır. Yüksek trafikli, kampanya yapan mağazalarda 8-16 GB ve ayrılmış çekirdek gerekir; çünkü ödeme sayfaları önbelleğe alınamadığı için her istek PHP ve veritabanını çalıştırır.

Sepet ve ödeme sayfaları neden önbelleğe alınamıyor?

Sepet, ödeme ve hesabım sayfaları her kullanıcı için farklı içerik gösterir. Bir ziyaretçinin sepetini önbelleğe alıp başka bir ziyaretçiye sunmak, yanlış ürünlerin ve hatta yanlış adres bilgilerinin görünmesi demektir. Bu yüzden bu sayfalar önbellek dışında tutulur ve her açılışta sunucuda PHP çalışır, veritabanına sorgu gider. Mağazanın gerçek kapasitesini de tam olarak bu önbelleklenemeyen istekler belirler.

WP-Cron WooCommerce’i neden yavaşlatır?

WordPress’in yerleşik zamanlayıcısı gerçek bir sistem görevi değildir; sayfa ziyaretleriyle tetiklenir. WooCommerce ise stok senkronizasyonu, sipariş durumu güncellemeleri, e-posta gönderimi ve Action Scheduler görevleriyle bu kuyruğu sürekli doldurur. Trafik yoğunken bazı ziyaretçiler kendi sayfa yüklemeleri sırasında bu görevleri de sırtlanır ve sayfa saniyelerce bekler. Doğru çözüm WP-Cron’u devre dışı bırakıp sunucu tarafında dakikalık gerçek bir cron görevi tanımlamaktır.

admin-ajax.php yükü nasıl azaltılır?

Önce hangi eklentinin admin-ajax.php’yi çağırdığını bulmak gerekir; tarayıcının ağ sekmesinde istek gövdesindeki action parametresi bunu açıkça gösterir. Suçlu genellikle canlı sepet parçacıkları, ziyaretçi sayaçları, stok sayaçları veya sohbet eklentileridir. Gereksiz olanları kapatmak, WooCommerce’in sepet parçacığını sayfa yenilemesiz güncelleme özelliğini yalnızca gerçekten gerektiği yerde açık bırakmak ve eklentileri modern REST uçlarını kullanan sürümlerle değiştirmek yükü belirgin şekilde düşürür.

Redis object cache WooCommerce’te fark yaratır mı?

Evet, çoğu mağazada en büyük tek kazancı sağlayan iyileşme budur. WooCommerce ürün, varyasyon ve sipariş verilerini çok sayıda meta kaydında tutar; her sayfa yükünde yüzlerce tekrar eden sorgu üretilir. Redis object cache bu sorguların sonuçlarını bellekte tutar ve veritabanına gitmeden döndürür. Özellikle önbelleklenemeyen sepet ve ödeme sayfalarında yönetici panelinin ve ödeme adımlarının hissedilir biçimde hızlandığını görürsünüz.

Mağazam büyürse sunucumu değiştirmem gerekir mi?

Aynı sağlayıcı içinde büyüyebiliyorsanız hayır, sadece paketi yükseltirsiniz. Alastyr’da paylaşımlı hostingten bulut sunucuya ya da fiziksel sunucuya geçiş, veri taşınarak kesintisiz biçimde yapılır. Önemli olan büyüme anını doğru okumaktır: sürekli yüksek CPU, kampanya saatlerinde uzayan ödeme süreleri ve artan zaman aşımı hataları görüyorsanız kaynak artırma zamanı gelmiştir.

WooCommerce mağazamın PCI uyumluluğundan ben mi sorumluyum?

Kart verisini kendi sunucunuzda saklamıyorsanız, PCI DSS yükümlülüğünün büyük kısmı kartı işleyen ödeme kuruluşundadır. Türkiye’de yaygın kullanım iyzico, PayTR, Param gibi sağlayıcıların ya da bankaların sanal POS sayfalarına yönlendirme veya iframe ile gömme şeklindedir; bu modelde kart numarası hiçbir zaman sizin sunucunuza düşmez. Size düşen sorumluluk sitenizi güncel tutmak, güçlü parola ve iki adımlı doğrulama kullanmak ve tüm site trafiğini SSL ile şifrelemektir.

Çok fazla eklenti WooCommerce’i gerçekten yavaşlatır mı?

Eklenti sayısından çok eklentinin kalitesi ve nerede çalıştığı önemlidir. Yalnızca yönetim panelinde çalışan bir eklenti ziyaretçiyi etkilemezken, her sayfada kendi CSS ve JavaScript dosyalarını yükleyen, ana sorguya filtre ekleyen veya sürekli arka plan görevi kuyruğa atan tek bir eklenti tüm mağazayı dizlerinin üstüne çökertebilir. Eklentileri tek tek devre dışı bırakıp sayfa üretim süresini ölçmek, sorunlu olanı bulmanın en kestirme yoludur.