Kısa cevap: WordPress’i hızlandırmak eklenti yarışı değil, katman tuning‘idir: doğru PHP-FPM havuz modu, agresif ama doğru OPcache, dinamik veriyi RAM’de tutan Redis object cache ve önbelleklenebilir trafiği PHP’ye hiç uğratmayan FastCGI cache. Hepsinin ortak hedefi tek metrik: TTFB. Ama altın kural şu — ölçmeden ayar yapma; her sitenin darboğazı farklıdır.
“Sitem yavaş” şikayetinin çözümü çoğu zaman yeni bir önbellek eklentisi değil, sunucunun PHP ve veritabanı katmanını doğru kurmaktır. Web sunucusu seçimini başka bir yazıda ele aldık; burada işin asıl belirleyici kısmına iniyoruz: PHP-FPM, OPcache ve Redis. Hepsi doğrulanmış, ölçülebilir kazanımlar.
Performans nerede kazanılır?
Bir WordPress isteğinin ömrü kabaca şu katmanlardan geçer: web sunucusu → PHP-FPM → PHP yorumlama (OPcache) → veritabanı sorguları (Redis) → yanıt. Önbellekli bir sayfada istek bu zincire hiç girmez; önbelleksiz dinamik bir sayfada ise her katman gecikmeye eklenir. Strateji bu yüzden ikili: önbelleklenebilen trafiği zincirden çıkar, çıkamayan dinamik trafiği her katmanda hızlandır.
PHP-FPM: doğru havuz modunu seçmek
PHP-FPM, PHP işçilerini (worker) yöneten katmandır ve üç modu vardır. Yanlış mod ya RAM israfı ya da yoğun trafikte 503 hatası demektir:
| Mod | Davranış | Ne zaman |
|---|---|---|
dynamic |
Trafiğe göre min/max arası ölçeklenir | Çoğu WordPress sitesi için doğru varsayılan |
static |
Tüm işçiler hep açık; spawn gecikmesi yok ama RAM kalıcı dolu | Tek, yüksek ve sürekli trafikli site (özel sunucu) |
ondemand |
Sıfır işçiyle başlar, istek gelince açılır; boştayken kapanır | Az ziyaretçili / çok sayıda site (RAM tasarrufu) — ilk istekte ~50-100ms gecikme |
En kritik ayar pm.max_children‘dır: sunucunun aynı anda kaç PHP isteği işleyebileceğini belirler. Resmî dokümana göre kabaca şöyle hesaplanır:
# Ortalama bir PHP işçisinin RAM kullanımını ölç:
ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1; n++ } END { printf "Ortalama: %d MBn", sum/n/1024 }'
# max_children = (PHP'ye ayrılabilir RAM) / (ortalama işçi boyutu)
# Örnek: 4GB RAM'in ~2.5GB'ı PHP'ye, işçi ~60MB ise → ~40
# Çok yüksek → bellek taşması (OOM); çok düşük → 503 hatasıHer siteye ayrı bir PHP-FPM havuzu (ve mümkünse ayrı Linux kullanıcısı) vermek, bir sitenin diğerinin kaynağını tüketmesini ve ele geçmiş bir sitenin komşuya sıçramasını engeller. Virtualmin bunu domain başına otomatik yapar; ayrıntı için sunucu sıkılaştırma rehberimize bakın.
OPcache: en ucuz büyük kazanç
OPcache, PHP’nin derlenmiş bytecode’unu bellekte tutar; böylece her istekte dosyaları yeniden derlemez. Üretimde mutlaka açık olmalıdır ve ağır tema/eklenti yüklerinde kazanç belirgindir. Makul üretim ayarları:
opcache.enable=1
opcache.memory_consumption=256 ; ağır siteler için 256-512MB
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=200000 ; çok eklentili siteler için yüksek tut
opcache.validate_timestamps=1
opcache.revalidate_freq=60 ; 60sn boyunca dosya kontrolünü atla
opcache.save_comments=1 ; bazı eklentiler docblock'a güvenirrevalidate_freq=60 performans için iyidir ama kod güncellemesinden sonra OPcache 60 saniyeye kadar eski kodu çalıştırabilir. Bir deploy yaptıysanız OPcache’i elle temizleyin (ör. PHP-FPM reload) — yoksa “değişikliğim neden görünmüyor?” tuzağına düşersiniz.
Redis: dinamik içeriğin gizli silahı
Tam sayfa önbelleği oturum açmış kullanıcılarda ve sepet/ödeme gibi kişiye özel sayfalarda çalışmaz. İşte Redis tam burada devreye girer. Redis Object Cache, WordPress’in tekrar tekrar yaptığı veritabanı sorgularının sonucunu RAM’de tutar; diske/SSD’ye gitmek yerine bellekten yanıtlar ve TTFB’yi düşürür.
Özellikle WooCommerce ve üyelik siteleri için neredeyse vazgeçilmezdir: bu siteler sayfa önbelleğine güvenemez (içerik kullanıcıya göre değişir), ama Redis altta yatan ürün/ayar sorgularını hızlandırır. Kurulum zinciri: Redis servisi → PHP redis eklentisi → Redis Object Cache eklentisi.
İki ölçülmüş sınır var: (1) önbellek isabet oranınız (hit ratio) %60’ın altındaysa Redis kazandığından çok depolama/tahliye için harcar — ek yük faydadan büyük olur. (2) wp_options autoload veriniz 2MB’ı aşıyorsa Redis “şişkinliği” önbelleğe alıp sorunu büyütür. Yani önce autoload temizliği, sonra Redis. Küçük, statik bir blogda Redis çoğu zaman gereksizdir.
PHP oturumlarını da dosya yerine Redis’e almak, oturum yoğun sitelerde ek bir hızlanma sağlar:
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?auth=GUCLU_PAROLA"FastCGI cache: önbelleklenebilir trafiği PHP’den kurtar
Son katman, anonim ziyaretçilere giden sayfaları sunucu seviyesinde önbelleğe almaktır. Doğru kurulduğunda istek PHP’ye ve veritabanına hiç uğramaz; TTFB milisaniyelere iner. Ancak en kritik kural: önbellek varsayılan kapalı olmalı ve tüm CMS oturum çerezleri atlanmalıdır — yoksa giriş yapmış kullanıcıya başkasının sayfası gösterilir. Bu tuzağı sıkılaştırma rehberinde CMS çerez tablosuyla ayrıntılı ele aldık; web sunucusu kıyası için nginx mi LiteSpeed mi yazısına bakın.
Ölçmeden ayar yapma
Bu yazıdaki her değer bir başlangıç noktasıdır, kesin reçete değil. Doğru yaklaşım: bir değişiklik yap, TTFB ve gerçek kaynak kullanımını ölç, sonra bir sonrakine geç. pm.max_children‘ı körlemesine yükseltmek OOM’a, OPcache’i deploy sonrası temizlememek hayalet hatalara, gereksiz Redis ek yüke yol açar. Performans bir kerelik ayar değil, ölçüm döngüsüdür.
DKS pratikte ne yapıyor?
Bir siteyi hızlandırırken sırayla gidiyoruz: önce darboğazı ölçüyoruz (PHP mi, DB mi, render mı), sonra katmanı ona göre kuruyoruz — havuz modu RAM’e göre, OPcache agresif ama deploy-temizlemeli, Redis yalnız işe yarayacağı yerde, FastCGI cache çerez-bypass’ı tam yapılmış halde. Performans optimizasyonu tarafında yaptığımız iş tam da bu ölçüm-tuning döngüsü. Çünkü en hızlı sunucu, en çok eklenti kurulan değil; darboğazı doğru teşhis edilendir.
Sıkça sorulan sorular
PHP-FPM’de static mi dynamic mi kullanmalıyım?
Çoğu WordPress sitesi için doğru varsayılan dynamic’tir; trafiğe göre ölçeklenir. static yalnız tek ve sürekli yüksek trafikli sitelerde, RAM’i kalıcı ayırabildiğinizde mantıklıdır. Az ziyaretçili veya çok sayıda site barındıran sunucuda ondemand RAM tasarrufu sağlar ama ilk istekte küçük bir gecikme ekler.
OPcache memory_consumption ne olmalı?
Üretimde en az 128MB, ağır tema/eklenti yüklü sitelerde 256-512MB önerilir. max_accelerated_files’ı da çok eklentili sitelerde yüksek tutun. Önemli not: kod güncellemesinden sonra OPcache’i temizleyin, yoksa eski kod 60 saniyeye kadar çalışmaya devam edebilir.
Redis object cache her WordPress sitesine gerekir mi?
Hayır. Redis, WooCommerce ve üyelik gibi dinamik, sorgu-yoğun sitelerde vazgeçilmezdir. Ancak önbellek isabet oranı %60’ın altındaysa veya wp_options autoload verisi 2MB’ı aşıyorsa fayda yerine ek yük getirir. Küçük statik bir blogda çoğu zaman gereksizdir.
Redis ile FastCGI cache aynı şey mi?
Hayır, farklı katmanlardır. FastCGI cache tam sayfayı önbelleğe alır ve anonim ziyaretçide isteği PHP’ye hiç uğratmaz. Redis ise veritabanı sorgu sonuçlarını önbelleğe alır ve sayfa-önbelleklenemeyen dinamik içeriği hızlandırır. İkisi birbirini tamamlar.
Performansın en önemli metriği hangisi?
TTFB (Time To First Byte) sunucu tarafı hızın en iyi göstergesidir ve LCP üzerinden Core Web Vitals’ı doğrudan etkiler. Ama tek bir ayara değil, ölçüm döngüsüne güvenin: değiştir, TTFB’yi ve kaynak kullanımını ölç, sonra ilerle.
WordPress siteniz yavaşsa darboğaz PHP’de mi, veritabanında mı, önbellekte mi? Bir performans denetimi isteyin; TTFB’nizi ölçüp katman katman somut bir hızlandırma planı çıkaralım.
