PageSpeed Insights’ta:
“İlk sunucu yanıt süresini azaltın”
uyarısını gördüğünüzde sorun çoğu zaman görseller başlamadan önce oluşuyordur.
TTFB — Time to First Byte — tarayıcının isteği göndermesi ile sunucudan ilk yanıt baytını almaya başlaması arasında geçen süredir.
WordPress’te yüksek TTFB’nin çözümü her zaman hosting değiştirmek değildir.
Aynı şekilde her zaman cache eklentisi kurmak da değildir.
Doğru çözüm için önce bu sürenin nerede oluştuğunu ayırmak gerekir.
TTFB tam olarak neyi içerir?
Basitleştirilmiş istek zinciri:
Kullanıcı
↓
DNS
↓
TCP bağlantısı
↓
TLS
↓
sunucu / PHP / uygulama
↓
veritabanı
↓
HTML üretimi
↓
ilk byte
TTFB bu zincirin tamamından etkilenebilir.
Dolayısıyla:
“TTFB 1,5 saniye = PHP 1,5 saniye çalıştı”
sonucu otomatik olarak doğru değildir.
İyi TTFB kaç olmalı?
web.dev referansında çoğu sitenin:
0,8 saniye veya daha düşük
TTFB hedeflemesi önerilir.
0,8–1,8 saniye aralığı iyileştirme gerektirebilir.
1,8 saniyenin üzerindeki değerler zayıf kabul edilir.
Ancak TTFB bir Core Web Vital değildir.
Buradaki amaç puan kovalamak değil, kullanıcının ana içeriği görmeye başlamasını gereksiz yere geciktirmemektir.
TTFB ile LCP ilişkisi
LCP tarayıcı sayfanın ana içeriğini göstermeye çalışırken ölçülür.
Ancak sunucu HTML’i geç gönderirse:
- tarayıcı DOM’u geç görür,
- CSS geç keşfedilir,
- LCP görseli geç keşfedilir,
- fontlar geç başlar.
Bu yüzden yüksek TTFB çoğu zaman LCP’nin başlangıcına doğrudan gecikme ekler.
WordPress’te yüksek TTFB’nin 10 yaygın nedeni
1. Page cache çalışmıyor
Anonim kullanıcı için cache’lenmesi gereken sayfa her istekte PHP tarafından yeniden üretiliyor olabilir.
Kontrol:
- cache HIT/MISS,
- response header,
- login/cookie,
- query string,
- cache exclusions.
2. Düşük hosting kaynağı
CPU veya PHP worker sayısı yetersizse yoğunluk sırasında istekler kuyruğa girebilir.
Site gece hızlı, gündüz yavaşsa yalnız frontend’e bakmak yeterli değildir.
3. Ağır eklentiler
Eklenti sayısından çok her eklentinin ne yaptığı önemlidir.
Bir eklenti:
- onlarca query,
- harici HTTP isteği,
- ağır hook,
- cron,
- admin AJAX
çalıştırabilir.
20 hafif eklenti bazen tek ağır eklentiden daha hızlıdır.
4. Veritabanı sorguları
Özellikle:
- büyük
wp_options, - autoload,
- karmaşık meta query,
- büyük WooCommerce tabloları,
- kullanılmayan plugin tabloları
TTFB’yi yükseltebilir.
5. Harici API beklemeleri
Sayfa oluşturulurken başka bir servisten cevap bekleniyorsa WordPress HTML’i gönderemez.
Örneğin:
- lisans kontrolü,
- kur dönüşümü,
- stok API,
- CRM,
- rezervasyon,
- uzaktaki XML/JSON servisleri.
Harici API isteğini frontend yükleme zincirinden ayırmak gerekebilir.
6. PHP sürümü ve OPcache
Güncel, desteklenen PHP sürümü ve doğru OPcache yapılandırması WordPress performansında önemlidir.
Ancak PHP sürümünü kör biçimde yükseltmeden önce tema ve eklenti uyumluluğu kontrol edilmelidir.
7. Object cache
Redis veya Memcached doğru projede faydalı olabilir.
Ancak:
Redis var = site hızlı
denklemi yoktur.
Object cache özellikle tekrar eden database object sorgularında faydalıdır.
Yanlış kurulum ise ek ağ gecikmesi veya cache karmaşası yaratabilir.
8. WooCommerce session ve cookie’leri
E-ticaret siteleri klasik içerik sitelerinden farklıdır.
Sepet ve kullanıcı oturumu nedeniyle bazı isteklerin cache dışı kalması gerekir.
Agresif cache:
- yanlış sepet,
- eski fiyat,
- kullanıcı karışması
gibi ciddi sorunlara yol açabilir.
9. WordPress cron
Yoğun veya uzun çalışan WP-Cron görevleri zaman zaman backend yükünü artırabilir.
Özellikle:
- backup,
- feed,
- senkronizasyon,
- mail,
- import/export,
- güvenlik taraması
gibi işler aynı anda çalışıyorsa performans dalgalanabilir.
10. Bot trafiği
Gerçek ziyaretçi az olsa bile:
- kötü botlar,
- scraper,
- brute force,
- yoğun crawler trafiği
sunucu kaynaklarını tüketebilir.
Bu nedenle performans incelemesinde yalnız Analytics kullanıcı sayısına bakılmaz.
TTFB sorununu nasıl ayırırım?
Önce aynı URL’yi birkaç katmanda test ederim.
Cache’li anonim istek
Amaç:
Frontend ziyaretçinin normal deneyimini görmek.
Cache bypass
Amaç:
Gerçek uygulama üretim süresini görmek.
Statik dosya testi
Sunucu/network katmanı ile PHP uygulamasını birbirinden ayırmaya yardımcı olur.
Backend profiling
Gerekirse:
- PHP,
- database query,
- slow query,
- application log,
- WordPress Query Monitor benzeri profiling
kullanılır.
Cloudflare TTFB’yi düşürür mü?
Bazı isteklerde evet.
Ancak burada iki farklı senaryo vardır.
Static asset
CDN doğrudan avantaj sağlayabilir.
Dynamic HTML
Cache politikası belirleyicidir.
HTML origin’e gidiyorsa backend TTFB sorunu devam eder.
HTML edge-cache ediliyorsa farklı davranabilir.
Bu nedenle Cloudflare açık/kapalı karşılaştırmasını yalnız PageSpeed puanıyla yapmamak gerekir.
LiteSpeed Cache yeterli mi?
LiteSpeed Server + LSCache doğru yapılandırıldığında WordPress için güçlü bir yapı olabilir.
Ancak:
- cache exclusions,
- guest mode,
- ESI,
- WooCommerce,
- object cache,
- crawler,
- image optimization
gibi özelliklerin tamamını bilinçsizce açmak doğru değildir.
Daha fazla özellik her zaman daha hızlı site anlamına gelmez.
“TTFB yüksek, hosting değiştirelim” ne zaman doğru?
Şunlar birlikte gözleniyorsa hosting ciddi adaydır:
- statik dosya yanıtları da yavaş,
- PHP worker beklemesi var,
- CPU sürekli limitte,
- disk I/O problemi,
- yoğun saatlerde gecikme artıyor,
- aynı uygulama daha güçlü test ortamında belirgin biçimde hızlanıyor.
Sadece tek PageSpeed çalışmasına bakarak hosting değiştirmem.
TTFB düzeldi ama PageSpeed hâlâ düşükse?
Bu mümkündür.
Sonraki darboğaz:
- LCP image,
- CSS,
- JavaScript,
- fonts,
- third party,
- layout shift
olabilir.
Web performansı zincirdir.
Bir halkayı düzeltmek diğerlerinin otomatik olarak düzeldiği anlamına gelmez.
Uygulama sıram
- Ölç.
- Cache davranışını doğrula.
- Server/application süresini ayır.
- Veritabanı ve PHP’yi incele.
- Harici servisleri kontrol et.
- Gerekiyorsa hosting/CDN katmanını değiştir.
- Tekrar ölç.
- LCP/INP/CLS’ye devam et.
WordPress sitenizde TTFB neden yüksek?
Tek bir eklenti önermek yerine önce gerçek darboğazı bulalım.