---
title: "WordPress Backend Performansı: TTFB’yi Düşürün"
url: https://bw.agency/blog/wordpress-backend-performansi/
date: 2026-09-25
modified: 2026-09-25
lang: tr
author: "Tolga Altaş"
description: "WordPress backend performansı yavaşsa ön yüz optimizasyonu yetmez. TTFB'yi ölçün, yavaş sorgu ve autoload şişkinliğini bulup 500 ms altına inin."
categories:
  - "WordPress"
image: https://img.poweredcache.net/bw.agency/wp-content/uploads/2026/09/wordpress-backend-performansi.avif?rs=fit&w=793&h=500&ssl=1
word_count: 842
---

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

## Önemli Noktalar

- TTFB değeri 500 ms üzerindeyse, ön yüz optimizasyonları yerine doğrudan backend performansına odaklanmak gerekir.
- Autoload verisi 1 MB sınırını aştığında, her sayfa yüklemesinde veritabanından PHP'ye gereksiz veri taşınarak performans düşüşü yaşanır.
- Redis veya Memcached gibi nesne önbelleği çözümleri, veritabanı yoğun sitelerde TTFB süresini 'den fazla azaltabilir.
- Query Monitor eklentisi, hangi fonksiyonların ve veritabanı sorgularının yavaşlamaya neden olduğunu tespit etmek için kullanılır.

Ö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.

- **[Admin yavaş ama ön yüz iyi](https://bw.agency/blog/wordpress-admin-yavas/).** Bu bir önbellek sorunu değildir ve asla olmayacaktır. admin-ajax, Heartbeat, `admin_init` çağrıları veya [autoload](https://bw.agency/blog/wordpress-autoload-siskinligi/)'dur.

- **Ö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](https://bw.agency/blog/yavas-wordpress-sorgulari/), sonra autoload boyutuna bakın.

- **Host "autoloaded data" işaretledi.** Harekete geçmeden önce kendiniz ölçün; bazı paneller WordPress 6.6+ sürümünde eksik sayar.

- **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 | Değerlendirme |
| ---- | -------------- |
| 200 ms altı | Mükemmel |
| 200–500 ms | Kabul edilebilir |
| 500 ms üstü | İyileştirme gerekir |

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:

- Index'siz meta sorguları (özellikle WooCommerce ürünleri)

- `post_content` üzerinde LIKE sorguları

- `wp_postmeta` üzerinde çoklu JOIN'ler

- 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](https://bw.agency/blog/wordpress-nesne-onbellegi/), 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.

- **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.

- **TTFB'yi ölçün.** Chrome DevTools veya WebPageTest. Hızlıysa ön yüze odaklanın. Yavaşsa devam edin.

- **Autoload boyutunu kontrol edin.** Yukarıdaki SQL'i çalıştırın. 1 MB üstü hemen aksiyon gerektirir.

- **SAVEQUERIES'i etkinleştirin.** wp-config.php'ye geçici olarak `define('SAVEQUERIES', true);` ekleyin. Yavaş olanlar için `$wpdb->queries`'e bakın.

- **Query Monitor kurun.** Hangi fonksiyonun hangi sorguyu tetiklediğini gösteren ücretsiz eklenti. Hata ayıklama için şart.

- **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](https://bw.agency/blog/ajanslar-icin-wordpress-site-teshisi/) 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:

- Her isteğe bağlanan eklentiler eklersiniz

- İçerik ve meta veri birikir

- Daha çok trafik gelir (gizli sorunları açığa çıkarır)

- 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

### İyi bir WordPress TTFB değeri nedir?
200 ms altı mükemmel, 200–500 ms kabul edilebilir, 500 ms üstü iyileştirme gerektirir. TTFB'niz 500 ms'yi aşıyorsa ön yüze dokunmadan önce backend performansına odaklanın.
### Önbellek eklentisi backend performansını düzeltir mi?
Hayır. Önbellek eklentileri ön yüz dağıtımını çözer. Önbelleğe içerik gönderilmeden önce çalışan PHP ve veritabanı sorgularına dokunmaz. Cache miss, giriş yapmış kullanıcı ve admin isteği tam maliyeti öder.
### PageSpeed skorum 95 ama site yavaş, neden?
PageSpeed çoğunlukla ön yüz teslimini ölçer. Yüksek TTFB, sunucunun yanıt vermeye başlamasının yavaş olduğu anlamına gelir. Yavaş sorgu veya autoload şişkinliği, skor yüksek olsa bile siteyi yavaş hissettirir.