Apache, Nginx ve LiteSpeed: WordPress ve WooCommerce

Doğru Web Sunucusunu Seçmek Neden Bu Kadar Önemli?

WordPress veya WooCommerce projeniz büyüdükçe, yavaş açılan sayfalar, sepet adımında takılan kullanıcılar ve kampanya dönemlerinde CPU’yu %100’e vuran sunucular konuşulmaya başlar. Web sunucusu ve önbellek stratejisi, paylaşımlı hosting, VPS ve dedicated sunucu ortamlarında performansı etkileyebilir. Ancak aynı donanımda elde edilecek kazanç; iş yüküne, mevcut darboğaza ve önbellek isabet oranına bağlıdır.

Google’ın Core Web Vitals metrikleri LCP, INP ve CLS’dir; TTFB ve ilk içerik boyama süresi (FCP) bu kümenin parçası değildir. Web sunucusunun yanıt süresi yükleme performansını etkileyebilir, ancak bu metrikler yalnızca sunucu mimarisiyle açıklanamaz. Yani “hangi hosting paketini aldığınız” kadar, o pakette hangi web sunucusunun nasıl yapılandırıldığı da belirleyici hale gelir. Bu yüzden bu yazıda, özellikle WordPress ve WooCommerce projeleri için Apache mi, Nginx mi, LiteSpeed mi? sorusuna, farklı kullanım senaryoları üzerinden cevap vereceğiz.

Eğer Core Web Vitals tarafında daha derine inmek isterseniz, sunucu konfigürasyonlarının etkisini detaylı anlattığımız Core Web Vitals ve hosting altyapısı rehberimize ve sıkıştırma ayarlarını örnek konfigürasyonlarla paylaştığımız Brotli ve Gzip sıkıştırma ayarları makalemize de göz atmanızı öneririz.

Apache, Nginx ve LiteSpeed’i Kısaca Tanıyalım

Apache: Esneklik ve Uyumluluk Klasiği

Apache, uzun yıllardır Linux hosting dünyasında yaygın kullanılan bir web sunucusu. En büyük avantajı, .htaccess desteği sayesinde sunucu yapılandırmasının izin verdiği dizinlerde yerel kurallar tanımlayabilmeniz ve yaygın bir eklenti/paket ekosistemine sahip olması. Uyumluluk, kullanılan modüllere ve kurallara göre değerlendirilmelidir. Paylaşımlı hosting panellerinde (cPanel, DirectAdmin, Plesk vb.) de kullanılan bir seçenektir.

Avantajları kısaca:

• .htaccess ile site bazlı yönlendirme, güvenlik ve cache kurallarını kolayca yönetebilme
• mod_php, PHP-FPM vb. farklı PHP çalıştırma yöntemleri için yaygın destek
• Uygun ModSecurity sürümüyle WAF kuralları uygulayabilme; kural uyumluluğunu test etme

Yüksek eşzamanlı bağlantı sayılarında, örneğin WooCommerce kampanyalarında, RAM tüketimi kullanılan MPM ve PHP çalıştırma yöntemine bağlıdır; Nginx ve LiteSpeed ile karşılaştırma aynı iş yükü ve önbellek koşullarında yapılmalıdır.

Nginx: Olay Tabanlı Bağlantı Yönetimi ve Reverse Proxy

Nginx, olay tabanlı (event-driven) bir web sunucusu ve reverse proxy olarak kullanılabilir. Worker süreçleri çok sayıda bağlantıyı birlikte yönetir. Statik CSS, JavaScript ve görsel dosyalarının doğrudan sunulması, bu istekler için PHP çalıştırılmasını gerektirmez. Yük kapasitesi; bağlantı sınırları, dosya tanıtıcıları, TLS, bellek ve uygulama davranışıyla birlikte değerlendirilir.

Öne çıkan yanları:

• Bir worker içinde çok sayıda bağlantıyı yönetebilme; kesin kapasiteyi ölçme gereği
• Reverse proxy ve yük dengeleme rolleri için merkezi yapılandırma
• FastCGI cache ile yalnız ortak önbelleğe uygun PHP yanıtlarını saklama; kısa TTL kullanılsa da kişisel yanıtları dışarıda tutma

Dezavantaj olarak, .htaccess desteği yoktur; tüm kurallar ana konfigürasyon dosyalarından yönetilir. Bu da özellikle ajans/çoklu site senaryolarında ilk etapta yönetim alışkanlığı gerektirir.

LiteSpeed Enterprise ve OpenLiteSpeed: Sürümü Ayırın

Burada LiteSpeed adıyla yapılan Apache uyumluluğu karşılaştırması, LiteSpeed Web Server Enterprise içindir. Enterprise, Apache yapılandırmalarıyla uyumluluk hedefleyen lisanslı üründür; her Apache modülünü aynı biçimde çalıştırdığı varsayılmamalıdır. OpenLiteSpeed ayrı, açık kaynaklı seçenektir. Her ikisi de LiteSpeed Cache eklentisi ile sunucu taraflı tam sayfa önbellekleme entegrasyonu sunar. HTTP/3 desteği ise web sunucusunun bir özelliğidir.

Avantajları:

• Enterprise için Apache yapılandırması ve desteklenen .htaccess kurallarıyla uyumluluk; taşınan kuralları test etme gereği
• PHP’yi LSAPI arayüzü ve LSPHP süreçleri üzerinden çalıştırma
• LiteSpeed Cache ile gelişmiş tam sayfa cache, ESI ve object cache entegrasyonları; kullanılabilirlik ve kurulum gereksinimleri seçilen sunucu sürümüne ve altyapıya göre değerlendirilmelidir. OpenLiteSpeed ESI desteklemez. Redis/Memcached nesne önbelleği ayrıca kurulur
• HTTP/2 ve HTTP/3 (QUIC) desteği; gecikme kazancı istemci, ağ ve yapılandırma koşullarına bağlıdır

Enterprise seçiminde lisans maliyetini hesaba katın. Olası donanım tasarrufu ve dönüşüm oranı değişimi ölçülmeden bu maliyetin geri kazanılacağı varsayılmamalıdır. Bu dengeyi nasıl kurabileceğinizi Nginx mi LiteSpeed mi? WooCommerce’de HTTP/3 ve tam sayfa önbellek karşılaştırmasını yaptığımız makalede detaylı anlattık.

HTTP/2, HTTP/3 ve Sürüm Koşulları

Apache 2.4’te HTTP/2 için mod_http2 gerekir. Resmi 2.4 modül listesi yerleşik bir HTTP/3 modülü belgelemiyor; gerekiyorsa desteklenen CDN veya reverse proxy HTTP/3’ü istemci tarafında sonlandırabilir. Bu, Apache origin bağlantısının da HTTP/3 kullandığı anlamına gelmez.

Nginx’te HTTP/2, ilgili modülün derlenmesini gerektirir; http2 on direktifi 1.25.1 ile gelmiştir. ngx_http_v3_module 1.25.0’dan beri vardır, varsayılan derlemeye dahil değildir ve güncel resmi belge tarafından hâlâ deneysel olarak tanımlanır. Uyumlu TLS kütüphanesi, QUIC listener ve UDP erişimi gerekir. HTTP/2 için TLS 1.3 zorunlu değildir; HTTP/3 farklı bir taşıma düzenidir.

LiteSpeed Enterprise HTTP/3 desteğini sunucu düzeyinde sağlar; güvenilen HTTPS sertifikası, etkin QUIC ayarları ve genellikle UDP 443 erişimi kontrol edilir. OpenLiteSpeed’in HTTP/3 desteği de ürünün sürüm ve yapılandırmasına göre doğrulanmalıdır. CDN kullanılıyorsa istemci–CDN ve CDN–origin bağlantılarını ayrı inceleyin. Protokol desteği tek başına daha düşük TTFB, daha iyi dönüşüm veya SEO sırası sağlamaz.

Apache 2.4 modülleri · Nginx HTTP/3 · LiteSpeed HTTP/3

Mimari Farklar: İş Parçacığı, Olay Döngüsü ve LSAPI

Mimariyi karşılaştırırken bağlantı yönetimini, PHP süreçlerini ve önbelleği ayrı değerlendirin. Bir sunucunun önbellekten sunduğu yanıtı, diğerinin PHP ve veritabanıyla yeniden ürettiği yanıtla kıyaslamak web sunucularını tek başına ölçmez.

Apache: Prefork, Worker ve Event MPM Farkı

Apache 2.4, farklı MPM modelleri sunar. Prefork, önceden başlatılan tek iş parçacıklı çocuk süreçler kullanır; yeni bağlantı geldiğinde her defasında yeni süreç yaratılması gerekmez. Worker, her çocuk süreçte birden fazla worker thread kullanır. Event, worker modelini geliştirerek uygun bekleyen keep-alive bağlantılarını listener üzerinden izler; boşta bekleyen her bağlantı için bir worker thread ayırmaz. Aktif PHP isteği ve bazı filtre/bağlantı durumları yine worker kaynaklarını tutabilir.

• Prefork + mod_php düzeninde PHP, Apache çocuk sürecinin içindedir; boş süreçler de bellek kullanabilir. PHP-FPM ise PHP’yi ayrı süreçlerde çalıştırır
• MaxRequestWorkers ve ServerLimit gibi sınırlar eşzamanlı iş ve süreç kapasitesini denetler; süreç sayısı sınırsız büyümez. Sınırlar RAM bütçesine göre belirlenmelidir
• Prefork’ta bir çocuk sürecin çökmesi bütün çocuk süreçlerin otomatik olarak çökmesi demek değildir. İlgili istek başarısız olabilir; ortak bellek baskısı veya bağımlılık hatası daha geniş etki yapabilir

Apache 2.4’te event MPM + PHP-FPM, mod_proxy_fcgi üzerinden kurulabilen bir seçenektir; Nginx ile kaynak kullanımı farkı ise yapılandırmaya ve iş yüküne göre ölçülmelidir. PHP-FPM havuzundaki kapasite ve kuyruk, Apache bağlantı kapasitesinden ayrı sınırlandırılır. MPM ayrıntıları için Apache event MPM belgesine bakın.

Nginx: Olay Döngüsü ve Ayrı PHP Havuzu

Nginx’te her bağlantı için ayrı proses/thread yaratılmaz. Ana süreç yapılandırma ve worker yönetimini üstlenir; worker süreçler istekleri olay döngüsüyle işler. Ancak ağ beklemesinin verimli yönetilmesi PHP, disk veya veritabanı işinin maliyetini ortadan kaldırmaz:

• RAM tüketiminin istek sayısıyla nasıl arttığı, iş yüküne ve yapılandırmaya bağlıdır
• Statik dosya sunumunun CPU maliyeti trafik ve yapılandırma koşullarına bağlıdır
• PHP, ayrı bir PHP-FPM havuzu üzerinden konuşulduğu için, web sunucusu ve PHP süreçleri daha net ayrışır

Bu mimari, özellikle yüksek eşzamanlı istek alan WooCommerce mağazalarında ve haber sitelerinde bağlantı yönetimi açısından avantaj sağlayabilir; PHP ve veritabanı darboğazlarını tek başına çözmez. Nginx’in PHP-FPM ile birlikte nasıl ayarlanması gerektiğini adım adım anlattığımız PHP-FPM ayarları rehberimiz bu noktada işinize yarayacaktır.

LiteSpeed: LSAPI Arayüzü ve LSPHP Süreçleri

LSAPI, web sunucusu ile harici uygulama arasındaki arayüzdür; LSPHP, PHP’nin LiteSpeed SAPI ile çalışan biçimidir. PHP-FPM ise FastCGI süreç yöneticisidir. Bunları yalnız iki iletişim protokolü gibi karşılaştırmak doğru olmaz. LiteSpeed’in Worker, ProcessGroup ve Daemon modları PHP süreçlerinin nasıl başlatılıp paylaşıldığını değiştirir; kullanılabilen mod ve varsayılanlar kuruluma bağlıdır.

Bu yapıyı değerlendirirken:

• PHP isteklerinde daha az bağlam değişimi (context switch) olduğu, karşılaştırmalı ölçüm olmadan varsayılmamalıdır
• WooCommerce gibi ağır sorgulu sayfalarda TTFB kararlılığı, PHP ve veritabanı yüküyle birlikte değerlendirilmelidir
• Çocuk süreç sınırları, idle süresi ve bir çocuğun işleyeceği istek sayısı ayarları seçilen moda göre çalışır. Detached modda LSPHP, web sunucusunun yeniden başlatılmasından bağımsız yaşayabilir; PHP ayar değişikliğinin uygulanması için belgelenen LSPHP yeniden başlatma işlemi gerekir. Bir PHP çökmesinin etkisiz veya anında giderileceği garanti edilemez

Süreç davranışları için LiteSpeed PHP süreç modları belgesini, kurulu sürüm ve panel ayarlarıyla birlikte okuyun.

Sonuç olarak, aynı donanımda bile Apache, Nginx ve LiteSpeed için evrensel bir performans sıralaması verilemez; sonuçlar iş yüküne, kurulum ve önbellek stratejisine bağlıdır.

WordPress ve WooCommerce Performansı

Statik İçerik, Dinamik İçerik ve TTFB

WordPress sitelerinde iki ana içerik tipi vardır:

• Statik içerik: CSS, JS, görseller, fontlar
• Dinamik içerik: PHP ile üretilen HTML (ürün sayfaları, sepet, ödeme, kullanıcı hesabı)

Statik içerikte üç sunucu da uygun ayarlarla iyi performans verebilir. Nginx ve LiteSpeed’in başa baş olduğu veya Apache’nin ağır trafikte daha fazla kaynak tükettiği, aynı koşullarda ölçülmeden söylenemez.

Dinamik içerikte ise tablo biraz daha karmaşıktır:

• Apache: PHP-FPM ile birlikte kullanılabilir; CPU/RAM yükü MPM, PHP havuzu ve uygulama iş yüküne bağlıdır
• Nginx: PHP-FPM + FastCGI cache ile, ortak önbelleğe uygun yanıtlarda PHP yükünü azaltabilir; önbelleğe alınmayan istekler ayrıca değerlendirilmelidir
• LiteSpeed: LSAPI + LiteSpeed Cache ile, önbelleğe uygun yanıtlarda PHP yükünü azaltabilir; WooCommerce TTFB ve yanıt süresinde genel bir üstünlük varsayılmamalıdır

Önbellekleme: Tam Sayfa Cache ve Mikro Önbellek

WordPress performansında web sunucusu seçimi kadar önbellek stratejisi de önemlidir. Değerlendirilebilecek dört yaklaşım:

• LiteSpeed Cache (Enterprise/OpenLiteSpeed): Sunucu taraflı tam sayfa cache; ESI yalnız bunu destekleyen Enterprise gibi ürünlerde, uygun entegrasyonla kullanılabilir. ESI kullanımı, sepet, ödeme ve hesap sayfalarını ortak tam sayfa önbelleğe alma gerekçesi değildir; bu sayfalar dinamik kalmalıdır
• FastCGI Cache (Nginx): Ortak önbelleğe uygun PHP çıktılarını saklayıp sonraki ziyaretçilere sunma; sepet, ödeme, hesap ve oturuma özel API yanıtları hariç tutulmalıdır. Kısa TTL’li mikro önbellekte de bu ayrım korunmalıdır
• Uygulama seviyesinde cache (Apache/Nginx): WP Rocket, W3TC, Cache Enabler vb. eklentiler + Object cache (Redis/Memcached)
• Apache mod_cache: mod_cache_disk veya mod_cache_socache gibi sağlayıcılarla sunucu taraflı HTTP yanıt önbelleği oluşturabilir. Modülün bulunması, her WordPress yanıtının güvenle önbelleklenebileceği anlamına gelmez; yetkilendirme, varyantlar ve temizleme politikası ayrıca tasarlanır.

Nginx FastCGI cache, yanıt verisini dosyalarda; anahtarları ve metaveriyi paylaşımlı bellek bölgesinde tutar. Hem cache okuma hem yazma istisnalarını kurun; uygulamanın kişisel/no-store yanıtlarını veya Set-Cookie başlıklarını sırf isabet oranını artırmak için yok saymayın. Cookie, API ve URL istisnalarını mağazanın gerçek yerelleştirilmiş yollarına ve eklentilerine uyarlayın.

LiteSpeed Cache eklentisinin sayfa önbelleği için etkin LSCache sunucu bileşeni veya QUIC.cloud gerekir. Eklentiyi sıradan Apache/Nginx üzerine kurmak yerel bir LSCache motoru oluşturmaz; önbellek dışı optimizasyon özellikleri ayrı kullanılabilir. Resmi LSCache rehberi ön koşulları ve ESI farkını açıklar.

Bu yaklaşımları nasıl konumlandırmanız gerektiğini, konfigürasyon örnekleriyle birlikte WordPress’te tam sayfa önbellekleme rehberimizde ayrıntılı işledik.

Mikro önbellekleme, örneğin 1–5 saniyelik TTL, aynı uygun içeriğe gelen yinelenen isteklerde PHP/veritabanı yükünü azaltabilir. Bu süre örnektir; doğruluk ve tazelik ihtiyacına göre seçilir. Kısa TTL kişisel içerik sızıntısını engellemez: sepet, ödeme, hesap, oturum cookie’leri taşıyan istekler ve oturuma özel Store API GET yanıtları ortak önbelleğe girmemelidir. Ayrıntılar için Nginx mikro önbellekleme rehberimize bakın.

Object Cache: Redis/Memcached ile Veritabanı Yükünü Azaltmak

WordPress’in nesne önbelleği, tekrar kullanılan verileri ve hesaplama sonuçlarını saklar. Kalıcı Redis/Memcached entegrasyonu, istekler arasında yeniden kullanım sağlayarak bazı veritabanı sorgularını azaltabilir. Etki eklentilerin önbellek kullanımına, isabet oranına, veri temizlemeye ve ağ gecikmesine bağlıdır; tam sayfa önbelleği veya PHP OPcache ile aynı katman değildir.

Ölçümler tekrarlanan sorgu veya nesne üretimi yükünü gösteriyorsa, uyumlu bir kalıcı nesne önbelleğini değerlendirin. Önbellek erişim hatasını, temizlemeyi, bellek sınırını ve çoklu site anahtar ayrımını test edin. Başlangıç için WordPress ve WooCommerce için Redis mi Memcached mi? rehberini kullanabilirsiniz; Redis/Memcached her kurulumda zorunlu değildir.

Kaynak Kullanımı ve Ölçeklenebilirlik

Kaynak planını yalnız günlük ziyaretçi sayısına bağlamayın. Aynı sayıda ziyaretçi, farklı bot trafiği, sepet işlemi, eklenti ve önbellek isabet oranıyla çok farklı yük üretebilir. Aşağıdaki rakamlar kapasite garantisi veya ürün sıralaması değil, ölçüm planı örnekleridir:

• 2 vCPU / 4 GB RAM: Küçük bir deneme kurulumu için toplam web sunucusu, PHP, veritabanı ve işletim sistemi belleğini ölçün. Bu kapasite her küçük site için yeterli kabul edilmez
• 4–8 vCPU / 8–16 GB RAM: Mağazanın önbelleksiz sepet/ödeme trafiğini, PHP worker kuyruğunu ve veritabanı bağlantılarını birlikte sınayın; sunucu adı kararlılık garantisi vermez
• 10.000 eşzamanlı oturum hedefi: Oturum sayısı eşzamanlı HTTP isteği değildir. İstek/saniye, kullanıcı düşünme süresi, bağlantı sayısı, hata oranı ve p95/p99 gecikmeyi açıkça tanımlayın

Önemli bir nokta: Web sunucusu seçimi tek başına yeterli değil. MySQL/MariaDB ayarları, PHP-FPM havuzu, disk tipi (NVMe vs SATA SSD) ve network gecikmesi de bir o kadar kritik. Bu konuları bir arada ele aldığımız WordPress için sunucu tarafı optimizasyon rehberimiz ile WooCommerce kapasite planlama rehberini birlikte okumanızı öneririz.

VPS veya dedicated sunucuda bu ayarları kimin yapacağı da ayrı bir karar noktası. Yönetilen/yönetilmeyen sunucu farkını netleştirmek için Managed VPS mi Unmanaged VPS mi? yazımız faydalı olacaktır.

Güvenlik, .htaccess ve Yönetim Kolaylığı

.htaccess Kullanımı: Ajanslar için Konfor Alanı

.htaccess, özellikle ajans ve freelancer dünyasında bir alışkanlık. Küçük bir kural eklemek için SSH ile sunucuya girmeden, SFTP veya panel dosya yöneticisiyle .htaccess’e satır ekleyip işi çözmek cazip geliyor.

• Apache: AllowOverride/AllowOverrideList izinleri kapsamında desteklenen .htaccess kuralları uygulanır. Dizin araması ve dosya okuma maliyeti olabilir; ana yapılandırmaya erişiminiz varsa kuralları orada merkezileştirebilirsiniz
• LiteSpeed Enterprise: Desteklenen Apache/.htaccess kuralları geçişi kolaylaştırabilir; modül ve direktif eşdeğerliğini sınayın
• OpenLiteSpeed: Auto Load from .htaccess ve rewrite etkinleştirilirse mod_rewrite kuralları yüklenebilir. Desteklenmeyen direktifler yok sayılır; belgelenen düzende kural değişikliklerinden sonra yeniden başlatma gerekir
• Nginx: .htaccess okumaz; kuralları merkezi yapılandırmaya taşıyıp test edin

Nginx’in .htaccess okumaması, her istekte bu dosyaları arama ihtiyacını kaldırır; bu tek başına toplam performans üstünlüğü kanıtı değildir. Apache’de de merkezi yapılandırma tercih edilebilir. Apache .htaccess rehberi ve OpenLiteSpeed rewrite kuralları hangi davranışın gerçekten desteklendiğini açıklar.

WordPress Kalıcı Bağlantıları ve Nginx

Kök dizindeki tek WordPress kurulumu için yaygın front-controller yaklaşımı, location / içinde try_files $uri $uri/ /index.php?$args; kullanmaktır. Dosya veya dizin yoksa istek sorgu parametreleriyle index.php’ye içeriden yönlendirilir; bu bir 301 değildir ve mutlaka rewrite direktifi gerektirmez. PHP handler’ı, gerçek belge kökü, bulunmayan PHP dosyalarının reddi ve uploads altında PHP çalıştırmanın engellenmesi ayrıca yapılandırılmalıdır. Alt dizin ve Multisite kurulumlarının yolları farklıdır; bu tek satırı tam üretim yapılandırması saymayın. WordPress’in Nginx rehberi başlangıç noktasıdır.

WAF, Güvenlik Başlıkları ve Ek Katmanlar

Güvenlik planı web sunucusunun adından daha geniştir: güncellemeler, dosya/sır erişimi, yedeklerin geri yüklenebilirliği ve yönetim arayüzlerinin erişimi temel konulardır. WAF, istek hızı sınırları, HTTP güvenlik başlıkları ve uygun log kaynağıyla fail2ban gibi ek katmanları ihtiyaç ve kurulum desteğine göre değerlendirin.

• Apache’de ModSecurity; Nginx’te uygun ModSecurity bağlayıcısı kullanılabilir. LiteSpeed’in WAF desteği de seçilen ürün/sürüme göre değerlendirilir; aynı CRS kuralının her motorda aynı davranacağını varsaymayın
• WAF’ı önce gözlem ve dar kapsamlı ayarlarla sınayın. WooCommerce REST/Store API, dosya yükleme ve ödeme bildirimleri için yanlış pozitifleri kontrol edin; bütün korumayı kapatmak yerine gerekçeli istisnalar kullanın
• HSTS’yi yalnız HTTPS kapsamı doğrulandıktan sonra, CSP’yi önce raporlama ile değerlendirin. Rate limiting için güvenilen proxy zincirinden gerçek istemci IP’sini doğru belirleyin

Başlıkların kapsamını ve WAF yanlış pozitiflerini yönetmek için HTTP güvenlik başlıkları rehberi ve ModSecurity ve OWASP CRS rehberi yararlı devam kaynaklarıdır. Hiçbir ayar tüm yanlış pozitiflerin veya saldırıların ortadan kalkacağını garanti etmez.

Farklı Senaryolar İçin Apache / Nginx / LiteSpeed Önerileri

1) Küçük Trafikli WordPress Blogları

Yeni bir blogda, örneğin günlük 500–2.000 ziyaretçi hedefinde, önce önbelleklenebilir içerik oranını ve tepe yükü belirleyin. Günlük trafik bir kapasite eşiği değildir. Yönetimi basit tutarak şu seçenekleri karşılaştırabilirsiniz:

• Hosting paketinin desteklediği Apache, Nginx veya LiteSpeed düzeni; uyumlu tek bir tam sayfa önbelleği ve düzenli güncellemeler
• Yönetim yetkili VPS’te Apache + PHP-FPM, Nginx + PHP-FPM veya LiteSpeed + LSPHP; işletme becerisi ve toplam maliyete göre seçim

.htaccess bağımlılığı güçlü ise Apache veya Enterprise geçiş işini azaltabilir; OpenLiteSpeed’in kapsamı ayrıca incelenmelidir. Mevcut sistem hedefleri karşılıyorsa yalnız büyüme beklentisiyle sunucu değiştirmek gerekmez. Ölçülmüş darboğaz oluştuğunda taşıma maliyetini beklenen faydayla kıyaslayın.

2) Orta Ölçekli Kurumsal WordPress Siteleri

Kurumsal, katalog ve çok dilli WordPress sitelerinde; arama, filtreler, dil/para birimi varyantları ve yönetim işleri aynı yükü oluşturmaz. Ziyaret sayısı yerine bu işlerin dağılımını ölçün:

• Apache: event MPM, uygun PHP-FPM ve OPcache ayarlarıyla değerlendirin; kaynak tüketimini peşinen diğerlerinden yüksek saymayın
• Nginx: Merkezi proxy ve önbellek yapılandırmasını yönetebilen ekipler için adaydır
• LiteSpeed: Enterprise veya OpenLiteSpeed’in LSCache entegrasyonunu, lisans ve ESI gereksinimiyle birlikte karşılaştırın; HTTP/3 tek başına hız garantisi değildir

Paylaşımlı hizmet, VPS veya dedicated sunucu kararını ölçülmüş kapasite, erişim yetkisi, yedekleme ve işletme sorumluluğuyla verin. Daha büyük makine ya da farklı sunucu yazılımı, yavaş sorguları ve ağır eklentileri kendiliğinden düzeltmez.

3) Yoğun Trafikli WooCommerce Mağazaları

Kampanya yükünde öncelik, sepet ve ödeme adımlarının doğruluğu ve yanıt süresidir. Evrensel bir gecikme/dönüşüm yüzdesi varsaymadan kendi dönüşüm verinizi ölçün. İki uygulanabilir önbellek yaklaşımı:

• Nginx + FastCGI cache: Uygun anonim HTML için önbellek; giriş, sepet, ödeme, hesap ve kişisel API yanıtları için hem cache okuma hem yazma engeli. API/admin/frontend yollarını ayırmak tek başına doğru politika oluşturmaz
• LiteSpeed + LSCache: WooCommerce entegrasyonu cache uygunluğu ve temizlemeyi koordine eder. Enterprise’daki ESI uygun parçaları ayrı işleyebilir; sepet, ödeme ve hesap sayfaları yine ortak tam sayfa cache dışında kalır. OpenLiteSpeed’de ESI yoktur

Apache de mod_cache veya uygulama önbelleğiyle; gerekçesi varsa ayrı reverse proxy katmanıyla değerlendirilir. Hiçbir ürüne ölçümsüz bir kaynak cezası atamayın. İki bağımsız tarayıcı oturumu ile sepet/veri ayrımını; ürün fiyatı/stok değişiminden sonra önbellek temizlemeyi ve ödeme sağlayıcısının bildirimlerini sınayın. Kapasite planı için yeni web sitesi için CPU, RAM ve trafik nasıl hesaplanır? rehberine bakın.

4) Ajanslar ve Freelancer’lar: Onlarca WordPress Sitesi

Bir ajans olarak tek VPS veya dedicated sunucu üzerinde 20+ WordPress sitesini barındırıyorsanız, önceliğiniz izolasyon, yönetim kolaylığı ve öngörülebilir kaynak kullanımı oluyor.

• Apache veya Enterprise seçerken mevcut .htaccess kurallarını, lisansı ve panel desteğini değerlendirin. OpenLiteSpeed’e geçişte desteklenmeyen kuralların sessizce yok sayılması özellikle kontrol edilmelidir
• Nginx + PHP-FPM ve gerekliyse Redis için merkezi şablonlar, yapılandırma testi ve geri dönüş sürümü tutun
• Farklı müşteriler için kullanıcı/dosya erişimi, sırlar, PHP havuzları ve kaynak sınırlarını planlayın. Aynı host üzerindeki ayrı havuz adları, ayrılmış RAM/CPU veya tam güvenlik izolasyonu sağlamaz

Ajanslar için çoklu site mimarisi kurarken sadece web sunucusunu değil, DNS, SSL ve yedekleme stratejisini de birlikte düşünmek gerekiyor. Bu açıdan ajanslar için hosting mimarisi rehberimiz, panel ve web sunucusu tercihini yaparken size iyi bir çerçeve sunacaktır.

DCHost Hizmeti Seçerken Neleri Doğrulamalısınız?

Web sunucusu seçeneği, lisans ve yönetim yetkisi satın alınacak hizmete göre değişir. DCHost’un güncel ürün sayfasında ve teklifinde şu noktaları doğrulayın:

• Paylaşımlı hosting: Kullanılan sunucu ürünü/sürümü, cache entegrasyonu, kaynak sınırları ve destek kapsamı
• VPS/dedicated: Kurulum ve root yetkisi, panel uyumluluğu, LiteSpeed lisansı ve güncelleme/yedek sorumluluğu
• Özel mimari: Reverse proxy, konteyner veya birden fazla web/veritabanı düğümü gerekiyorsa ağ, izleme, cache temizleme ve arıza senaryosu

Trafik profili, yoğun saat ölçümleri, mevcut .htaccess kuralları, eklenti listesi ve bütçeyle karşılaştırma yapın. Bir ürün ailesinin varlığından belirli yazılımın, lisansın veya yönetim hizmetinin pakete dahil olduğu sonucunu çıkarmayın.

Sonuç ve Yol Haritası

“Apache mi Nginx mi LiteSpeed mi?” sorusunun tek bir cevabı yok; ama WordPress ve WooCommerce için bazı net çizgiler çizebiliriz:

• Uyumluluk önceliği: Apache’yi ve desteklenen kurallar kapsamında LiteSpeed Enterprise’ı değerlendirin
• Merkezi proxy/özel yönlendirme: Nginx, bu yapılandırmayı yönetebilen ekipler için uygun adaydır
• LSCache entegrasyonu: Enterprise ve OpenLiteSpeed arasında lisans, ESI ve .htaccess farklarını gözetin; mağazanın dinamik yanıtlarını ortak cache dışında tutun

Kararı ölçülebilir yapın: aynı PHP ve uygulama sürümü, benzer TLS/sıkıştırma ve donanım koşullarıyla statik dosya, cache HIT, cache MISS ve kişisel sepet/ödeme isteklerini ayrı ölçün. p95/p99 gecikme, hata oranı, istek/saniye, CPU, RAM, PHP kuyruğu ve veritabanı baskısını birlikte kaydedin. Önbellek ısınmasını ve temizleme sonrası yükü de test edin.

Sonraki adım olarak, hem performans hem de ölçeklenebilirlik tarafında daha derine inmek isterseniz, şu makaleleri de okuma listenize ekleyin:

• WordPress için en iyi hosting seçimi: Paylaşımlı, yönetilen ve VPS karşılaştırması
• Paylaşımlı hosting’den VPS’e sorunsuz geçiş rehberi

Geçişten önce yedek ve geri dönüş planı hazırlayın. Mevcut 301’leri, WordPress kalıcı bağlantılarını, sorgu parametrelerini, canonical/hreflang etiketlerini, HTTPS ve yönlendirme döngülerini staging ortamında kontrol edin. Sepet/ödeme, e-posta/webhook ve zamanlanmış işleri doğruladıktan sonra kontrollü trafikle geçin; gerçek kullanıcı ölçümleri kötüleşirse önceden belirlenmiş geri dönüş koşulunu uygulayın.