TTFB (Time to First Byte) Nedir? Nasıl Düşürülür?

TTFB (Time to First Byte), kullanıcının sayfa yüklenmeye başladıktan sonra ilk yanıtı ne kadar sürede aldığına dair en kritik göstergelerden biridir. TTFB düştüğünde sayfa “hızlı açılıyor” algısı güçlenir; SEO ve dönüşüm metrikleri de buna paralel şekilde etkilenir. Bu rehberde TTFB’nin ne olduğunu, hangi katmanlarda oluştuğunu ve VDS/VPS veya web hosting üzerinde nasıl net biçimde düşürüleceğini adım adım öğreneceksiniz.

TTFB nedir? (Time to First Byte)

TTFB, tarayıcının isteği yaptıktan sonra sunucudan ilk baytı (ilk yanıt verisini) aldığı zamandır. Teknik olarak tarayıcı, örneğin GET /page isteğini gönderir; sunucu uygulama (application) veya web sunucusu (nginx/apache) tarafından ilk yanıt üretildikten sonra ilk veri paketleri tarayıcıya ulaşır.

TTFB tek bir sebep yüzünden yükselmez. İstek şu bileşenlerden geçerek yanıtı üretir: - DNS çözüm süresi (domainin IP’si) - TCP bağlantısı ve/veya TLS (HTTPS) el sıkışması - Web sunucusunun isteği kabul etmesi ve yönlendirmesi - Uygulamanın (WordPress/PHP/Node/Java vb.) veriyi üretmesi - Veritabanının (database) sorgu süresi - Önbelleğin (cache) bulunup bulunmaması

Burada kritik nokta şudur: TTFB artışı genellikle “net gecikme” değil, ilk yanıt üretme sürecindeki bekleme yüzündendir.

TTFB mi yoksa PageSpeed mi? Hangisi doğru?

TTFB, “ilk baytın gelme hızı”dır. PageSpeed Insights ise tarayıcının ölçtüğü kullanıcı deneyimi metriklerini (LCP, CLS, FCP) farklı sinyallerle değerlendirir. İkisi birbirini tamamlar: - TTFB yüksekse, genellikle LCP ve FCP de etkilenir. - TTFB düşük ama LCP hâlâ kötüyse problem çoğunlukla görsel/JS ağırlığı veya istemci render sürecindedir.

TTFB neden düşer, neden yükselir?

TTFB’yi yükselten en sık kök nedenler şunlardır. Bunlar aynı zamanda NetKıyas’ta farklı hosting senaryolarını ayırırken de en çok görülen sorun kümeleridir.

1) Cache yokluğu veya yanlış önbellekleme - Dinamik sayfa her istek geldiğinde yeniden üretiliyorsa TTFB artar. - WordPress’te object cache (APCu/Redis) veya sayfa önbelleği (full page cache) yoksa uygulama her istekte veriyi yeniden sorgular.

2) Veritabanı yavaşlığı - Sorgular gereksiz tabloları tarar. - İndeks (index) eksiktir. - Disk/IO tıkanır; bu da DB yanıtını geciktirir.

3) Uygulama tarafında uzun işlem - Senkron (synchronous) ağır hesaplar. - Harici API çağrıları (ör. ödeme/CRM) isteğin içinde yapılır.

4) Ağ ve kurulum katmanı gecikmeleri - DNS yavaş yanıt verir. - TLS handshake uzar (zayıf/uygunsuz konfig). - Sunucuya giden yol (routing) yoğun veya uzak kalır.

5) Yanlış web sunucusu/uygulama eşleşmesi - nginx ↔ PHP-FPM ayarları (worker, timeout, max_children) yanlışsa iş kuyruğu oluşur. - Apache mod_php kullanıp kaynakları yetersiz yönetmek TTFB’yi yükseltebilir.

TTFB nasıl ölçülür? Net yöntem

Ölçüm olmadan optimizasyon, körlemedir. Aşağıdaki yöntemlerle TTFB’yi hem “genel” hem de “bölümlenmiş” biçimde görebilirsiniz.

Tarayıcı geliştirici araçları

• Chrome DevTools → Network
• Sayfa yükleyince ilk istekleri inceleyin.
• “TTFB” tarayıcıda her zaman tek satırda görünmeyebilir; ancak waterfall üzerinden “request → first response data” gecikmesi okunur.

curl ile başlık/ilk yanıt testi

Basit testler için curl kullanabilirsiniz. Örnek: - curl -s -o /dev/null -w "DNS:%{time_namelookup} TCP:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer}\n" https://ornek.com/

Bu çıktıda kritik değer time_starttransfer’dir; karşılık gelen TTFB yaklaşımıdır.

Sunucu logları ile eşleştirme

TTFB’yi uygulama tarafında görmek için web sunucusu + uygulama loglarını zaman damgalarıyla eşleştirin. - nginx: request log + upstream zamanları - PHP-FPM: yavaş istek logları - DB: slow query log (varsa)

Hedef, “TTFB yüksek olan isteklerin” hangi katmanda geciktiğini bulmaktır.

TTFB’yi düşürmek için uygulanabilir adımlar (hosting/VDS odaklı)

Aşağıdaki adımlar, sorunu kökünden çözmek için sırayla uygulanmalıdır. Her adımın sonunda TTFB’yi yeniden ölçün.

1) Önbelleği doğru kurun: full page + object cache

En hızlı kazanım çoğu senaryoda önbellekten gelir.

• Statik ve yarı statik sayfalar için full page cache kullanın.
• WordPress’te object cache için Redis veya Memcached kurun.
• API çağrıları (varsa) sayfa üretimi sırasında tekrar tekrar çalışıyorsa cache’e alın.

Pratik karşılaştırma: - Full page cache kullanmayan sistemlerde TTFB genelde “her istek aynı maliyeti” taşır. - Full page cache kullanan sistemlerde TTFB, çoğu zaman çok daha stabil hale gelir.

WordPress özelinde kontrol listesi: - wp_options ve sık kullanılan meta sorguları object cache ile hızlanır. - Sorgu tekrarlarını azaltan eklentiler seçilir (her eklentinin kendi cache’i olmalı).

2) Veritabanı: slow query, indeks ve sorgu optimizasyonu

DB kaynaklı TTFB artışı çok yaygındır.

Yapılacak net işler: - DB slow query log’u açın. Örn: 0.5s üzeri sorguları yakalayın. - En çok çağrılan sorgularda EXPLAIN ile indeks kullanımını kontrol edin. - Gereksiz ORDER BY / SELECT * gibi maliyetli yapıları düzeltin.

IO (g/ç) ve disk performansı da TTFB’yi etkiler. NVMe tabanlı depolama, ağır okuma-yazma işlerinde belirgin fark yaratır; ancak DB sorgusu kötü ise tek başına NVMe sorunu “tam çözmez”.

3) Uygulama sunucu ayarları: nginx + PHP-FPM örnek kontrol

TTFB, uygulama tarafından ilk bayt üretilene kadar geçen süredir. Bu yüzden uygulama iş kuyruğu (queue) oluşmamalı.

nginx ↔ PHP-FPM tarafında bakılacaklar: - PHP-FPM worker sayısı (max_children benzeri) - worker timeout - istek başına aşırı süreç yaratımı

Net teşhis yaklaşımı: - Sunucu aynı anda çok istek alıyorsa TTFB lineer artar. - CPU düşmesine rağmen TTFB yükseliyorsa çoğu zaman “bekleme” (ör. DB, dış servis) vardır.

4) Statik içerik ve sıkıştırma: ilk bayt gecikmesini azalt

TTFB “ilk byte” olduğundan, statik dosyaları doğru sunmak zaman kazandırır. Şunları netleştirin: - gzip veya Brotli sıkıştırma - doğru MIME type’lar - cache-control başlıkları (ETag/Last-Modified)

Bu adımlar TTFB’yi tek başına her zaman dramatik düşürmeyebilir; ancak ilk yanıt üretildikten sonraki akışta kullanıcı deneyimini net hızlandırır.

5) CDN kullanın ama kök sebebi saklamayın

CDN, kullanıcıya yakın edge noktasında önbelleği sağlayarak ilk erişimde gecikmeyi azaltabilir.

CDN’in etkisi nasıl anlaşılır? - TTFB düşüyorsa çoğu zaman coğrafi gecikme veya cache katmanı iyileşmiştir. - TTFB yine de yüksek kalıyorsa origin (sunucu) uygulama/DB gecikmesi devam ediyor demektir.

TTFB düşüşünü CDN ile “maskelenmiş” mi yoksa gerçekten düzelmiş mi diye ayırt etmek için aynı URL’i: - doğrudan origin’den test edin - CDN’den test edin

6) TLS/HTTP ayarları ve bağlantı yeniden kullanımı

HTTPS kullanıyorsanız TLS handshake maliyeti vardır. TLS süresinin TTFB’yi etkileyip etkilemediğini curl çıktısıyla görün.

Somut iyileştirme hedefleri: - HTTP/2 veya HTTP/3 (uygunsa) etkinleştirin. - Keep-Alive (bağlantı yeniden kullanım) açık olsun. - Sertifika/anahtar güncel ve doğru şifre takımlarıyla servis edilsin.

7) Sunucu kaynaklarını “anlık taşma” olmadan ayarlayın

VDS/VPS üzerinde kaynak yönetimi yanlışsa TTFB dalgalı olur.

Kısa rehber: - CPU kullanımı sürekli %90 üstüyse uygulama sıkışır; TTFB yükselir. - CPU daha düşükken TTFB yükseliyorsa DB/IO tıkanması veya dış servis beklemesi daha olasıdır. - Disk I/O wait artıyorsa, DB ve logs bir darboğaz yaratıyor olabilir.

Net karşılaştırma: TTFB sorunu hangi katmanda?

Aşağıdaki tabloyu tanı amaçlı kullanın. Her satır, TTFB’yi düşürmek için hangi adımların öncelikli olduğunu gösterir.

Sonuç: Hangi aksiyonla başlayın?

TTFB’yi düşürmek için en doğru sıra “ölç → kök nedeni ayır → tek tek iyileştir” yaklaşımıdır. İlk turda full page cache ve object cache’i net biçimde devreye alın, ardından DB tarafında slow query log ile en pahalı sorguları düzeltin. Son olarak nginx/PHP-FPM (veya uygulama sunucusu) tarafında worker/timeout kaynaklı tıkanmayı giderin.

Aksiyon önerisi: Önce 10 URL’lik bir test seti oluşturun, her değişiklikten sonra aynı URL’leri tekrar ölçün ve TTFB’de hedeflediğiniz iyileşmeyi (ör. 1.0s → 0.6s gibi) sayısal olarak doğrulayın. Bu şekilde optimizasyon, tahminle değil veriyle ilerler.