WordPress Backend Performansı: TTFB’yi Düşürün

Ön yüzünüzü optimize ettiniz. Önbellek eklediniz, görselleri sıkıştırdınız, CDN kurdunuz.

Peki siteniz neden hâlâ yavaş?

WordPress Hızı İçin Ön Yüz Optimizasyonu Neden Yetmez?

Çoğu WordPress performans rehberi ön yüz optimizasyonuna odaklanır: önbellek, görsel sıkıştırma, minify, CDN. Bunların hepsi geçerlidir ve yapmalısınız.

Ama kimsenin konuşmadığı şey şu: backend performansı.

Desen: Sitenin PageSpeed skoru 95+. Görseller optimize, önbellek açık. Kullanıcı yine de “yavaş” diyor.

Suçlu genelde TTFB’dir (Time to First Byte); sunucunuzun yanıt vermeye başlaması. Sunucunuz her sayfayı kurmak için 2 saniye harcıyorsa, hiçbir ön yüz optimizasyonu bunu kurtarmaz.

Hangi Backend Sorununa Sahipsiniz?

Dört belirti, dört farklı neden. Gördüğünüze uyanla başlayın, sayfanın geri kalanını atlayın.

1. Admin yavaş ama ön yüz iyi. Bu bir önbellek sorunu değildir ve asla olmayacaktır. admin-ajax, Heartbeat, admin_init çağrıları veya autoload‘dur.
2. Önbelleğin sunması gereken sayfalarda TTFB yüksek. Önbellek cevap veremeden önce bir şey çalışıyor. Genelde yavaş sorgu veya nesne önbelleğine sığmayan bir autoload seti. Önce yavaş sorguları bulun, sonra autoload boyutuna bakın.
3. Host “autoloaded data” işaretledi. Harekete geçmeden önce kendiniz ölçün; bazı paneller WordPress 6.6+ sürümünde eksik sayar.
4. Nedeni biliyorsunuz ve otomatik çözüm istiyorsunuz. Autoload seçeneklerini kategorize edip güvenli olanları geri alınabilir şekilde kapatan bir yaklaşım kullanın.

Ön Yüz ve Backend Performansı Farkı

Ön Yüz (genelde çözülmüş):

• Görsel optimizasyonu
• CSS/JS minify
• Tarayıcı önbelleği
• CDN dağıtımı
• Lazy loading

Backend (sık ihmal edilen):

• Yavaş veritabanı sorguları
• wp_options autoload şişkinliği
• Eksik index’ler
• N+1 sorgu sorunları
• Nesne önbelleği ıskaları

Önbellek eklentileri ön yüz dağıtımını çözer. Önbelleğe bir şey gönderilmeden önce gerçekleşen PHP işleme ve veritabanı sorgularına dokunmazlar.

WordPress TTFB Kıyasları: Rakamlarınızı Bilin

TTFB’nizi kontrol edin: Chrome DevTools → Network → İlk istek → “Waiting (TTFB)”.

TTFB’niz 500 ms’yi aşıyorsa, başka bir şeye dokunmadan önce backend’e odaklanın. Yanlış sorunu düzeltiyorsunuz.

Yaygın WordPress Backend Performans Sorunları

1. Autoload Şişkinliği

Her WordPress isteği şu sorguyu çalıştırır:

SELECT option_name, option_value FROM wp_options WHERE autoload IN ('yes', 'on')

2 MB autoload verisi varsa, bu her sayfa görüntülemesinde veritabanından PHP’ye taşınan 2 MB demektir. Toplamınızı kontrol edin:

SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes', 'on');

1 MB üstü mü? Sorununuz var. Genelde kapatılmış eklentilerden kalan veridir.

2. Yavaş Veritabanı Sorguları

500 ms süren tek bir sorgu tüm sayfayı geciktirir. Yaygın kaynaklar:

1. Index’siz meta sorguları (özellikle WooCommerce ürünleri)
2. post_content üzerinde LIKE sorguları
3. wp_postmeta üzerinde çoklu JOIN’ler
4. Karmaşık WHERE’li COUNT sorguları

3. Eksik Nesne Önbelleği

Redis veya Memcached olmadan WordPress her istekte her şeyi veritabanından yeniden kurar. Nesne önbelleği, veritabanı yoğun sitelerde TTFB’yi %50+ düşürebilir.

4. N+1 Sorgu Sorunları

20 yazı yükleyip her yazının meta verisi için ayrı sorgu çalıştırmak, 2 yerine 21 sorgu eder. Eklentiler ve temalar bunu sık sık istemeden yapar.

WordPress Backend Performans Sorunları Nasıl Teşhis Edilir?

Aşağıdaki adımların çoğu tek bir şeyi elle ölçer. İlk adım hepsini tek geçişte ölçer; oradan başlayın ve sıralı liste gerisini belirlesin.

1. Tüm kurulumu tarayın. OPcache, nesne önbelleği drop-in’i, Redis sağlığı, önbellek kontrolü, optimize edici çakışmaları ve veritabanı şişkinliğini tek geçişte, en kötü önce sıralayarak inceleyin.
2. TTFB’yi ölçün. Chrome DevTools veya WebPageTest. Hızlıysa ön yüze odaklanın. Yavaşsa devam edin.
3. Autoload boyutunu kontrol edin. Yukarıdaki SQL’i çalıştırın. 1 MB üstü hemen aksiyon gerektirir.
4. SAVEQUERIES’i etkinleştirin. wp-config.php’ye geçici olarak define('SAVEQUERIES', true); ekleyin. Yavaş olanlar için $wpdb->queries‘e bakın.
5. Query Monitor kurun. Hangi fonksiyonun hangi sorguyu tetiklediğini gösteren ücretsiz eklenti. Hata ayıklama için şart.
6. Eklentilerde ikili arama yapın. Hepsini kapatın, TTFB’yi ölçün, gruplar hâlinde açarak yavaş olanı bulun.

Tarama ne zaman yanlış ilk adımdır: Tek bir isteği hata ayıklıyorsanız onu doğrudan Query Monitor ile açın. Amaç ön yüzü hızlandırmaksa bu bir önbellek işidir, teşhis değil.

WordPress İçin Hızlı Backend Kazançları

Nesne Önbelleği Ekleyin

Host’unuz Redis veya Memcached sunuyorsa etkinleştirin. Bu tek değişiklik, veritabanı yoğun sitelerde TTFB’yi belirgin düşürebilir.

Eksik Index’i Ekleyin

WordPress’in varsayılan postmeta tablosunda yararlı bir index yoktur. Meta sorgularınız meta_key + meta_value‘yu birlikte süzüyorsa, bileşik bir index tercih edin:

ALTER TABLE wp_postmeta
ADD INDEX wpmt_key_value (meta_key(191), meta_value(32));

Transient’leri Temizleyin

DELETE FROM wp_options WHERE option_name LIKE '%_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

Kullanılmayan Autoload’u Kapatın

Hâlâ autoload’a ayarlı kapatılmış eklenti verisini bulun ve değiştirin:

UPDATE wp_options SET autoload='no' WHERE option_name = 'old_plugin_data';

WordPress Backend Sorunları Neden Geri Gelir?

Backend sorunları görünmezdir. WordPress yavaş sorguları varsayılan olarak yüzeye çıkarmaz. Sitenizde 2 saniye süren sorgular olabilir ve kayıt olmadığı için bunları bilmezsiniz.

Ve tek seferlik bir düzeltme değildir. Performans zamanla şu nedenlerle kötüleşir:

1. Her isteğe bağlanan eklentiler eklersiniz
2. İçerik ve meta veri birikir
3. Daha çok trafik gelir (gizli sorunları açığa çıkarır)
4. Eklenti güncellemeleri regresyon getirir

Periyodik manuel kontroller değil, sürekli izleme gerekir. WordPress yönetici paneliniz zaten yavaşsa, hasar her sayfa yüklemesinde katlanır.

WordPress Backend Performansı SSS