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

TTFB (Time to First Byte), kullanıcının sitenizdeki sayfa yükleme sürecinde “ilk yanıt”ı ne kadar hızlı aldığıdır. Sayfa görsel olarak tam yüklenmeden önce bile, bu ölçüm ziyaretçi algısını doğrudan etkiler. NetKıyas’ta kullanıcıların en sık yaşadığı sorunlardan biri TTFB’nin yüksek çıkmasıdır: Uygulama yavaşlığı, veritabanı gecikmesi, cache eksikliği veya kötü ağ/denetim tasarımı TTFB’yi şişirebilir.

Bu rehberde TTFB’nin ne olduğunu, hangi metrikle karıştırılmaması gerektiğini ve en sık kök nedenleri net bir kontrol listesiyle ele alacaksınız. Sonrasında da sunucu, kontrol paneli ayarları, CDN (içerik dağıtım ağı) ve uygulama tarafında TTFB’yi düşürmek için uygulanabilir adımları göreceksiniz.

TTFB nedir, hangi gecikmeleri içerir?

TTFB, tarayıcının veya test aracının isteği gönderip ilk yanıt baytını (first byte) alana kadar geçen süredir. Bir sayfanın “ilk etki” zamanı gibi düşünülür. Ancak TTFB, toplam sayfa yükleme süresinin (load) birebir karşılığı değildir.

Aşağıdaki ayrım kritik: - TTFB: Sunucunun isteği işleyip ilk veriyi göndermesine kadar geçen süre. - TTL/Latence (gecikme): Ağ yolundaki iletişim süresi. - First Contentful Paint (FCP) / DOMContentLoaded: Tarayıcı tarafında içerik/DOM hazır olana kadar geçen süre.

TTFB’yi şişiren tipik bileşenler: 1. İstek bekleme (queue) / iş parçacığı (thread) tükenmesi 2. Uygulamanın ilk istek için geç ayağa kalkması (cold start) 3. Uygulama kodunun istek başına pahalı çalışması 4. Veritabanı sorgularının yavaşlığı (özellikle N+1 sorunları) 5. Cache (önbellek) eksikliği; her istekte dinamik üretim 6. TLS/HTTP oturum maliyeti veya yanlış keep-alive ayarları 7. CDN araya girse bile “cache-hit” olmaması (yanlış varyant, yanlış başlıklar)

TTFB nasıl ölçülür? Doğru aracı ve yöntemi seçin

TTFB’yi tek bir ölçümle “iyi/kötü” diye etiketlemek hatalıdır. En doğru yaklaşım, farklı yol ve istek tiplerinde (HTML, JSON, asset değil) TTFB’yi ölçmektir.

Hangi testler kullanılmalı?

Aşağıdaki seçenekler pratik: - Browser (Tarayıcı) Developer Tools: Network sekmesinden “Timing” değerlerini okuyun. - curl ile tek istek TTFB: Sunucu yanıt süresini kabaca görürsünüz. - Lighthouse / WebPageTest: TTFB dahil birçok metrik üretir; ancak yorum yaparken konfigürasyonu dikkate alın.

Örnek curl kullanım mantığı (değerler aracınıza göre değişir): - curl -w "time_starttransfer: %{time_starttransfer} ..." benzeri çıktı, ilk byte benzeri zamanla ilişkilidir.

Ölçümde dikkat edilecek 6 nokta

Ölçümü aynı URL ve aynı HTTP metodu ile yapın (GET vs POST fark yaratır).
Cache kontrolü yapın: İlk istek mi, tekrar istek mi? Dinamik içeriklerde fark normaldir.
Farklı konumlardan test edin (Türkiye içi lokasyon + yurtdışı).
Aynı anda tarayıcıda önbellek etkisi yaratmayacak test yapın.
Mobil/desktop simülasyonunu bilin: header ve istek sayısı değişir.
Veritabanı yoğunluğu dalgalanıyorsa zaman aralığı seçin.

TTFB’yi yüksek yapan kök nedenler (en sık karşılaşılanlar)

TTFB sorunlarını “hedeflediğiniz tek bir sayı” gibi görmek yerine kök nedeni sınıflandırın. NetKıyas’ta sık görülen örnekler:

1) Cache yok ya da cache çalışmıyor

Her istekte CMS/uygulama sayfayı yeniden render ediyor.
CDN var ama cache-hit gerçekleşmiyor.
Yanlış Cache-Control / Vary ayarları sebebiyle her istek farklı varyant gibi değerlendiriliyor.

2) Veritabanı yavaş veya yanlış indeks

Yüksek TTFB’nin çok yaygın nedeni, ilk işte ağır sorgu çalıştırılması.
Özellikle sayfa yüklenirken “ana sorgu + ilişkili sorgular” zinciri oluşur.

3) Uygulama katmanı iş kuyruğuna düşüyor

Uygulama sunucusu (ör. Nginx+PHP-FPM, Node.js, Java) işçi sayısı (worker/thread) yetersiz.
Yoğun saatlerde istekler sıraya girer; TTFB şişer.

4) DNS/TLS/HTTP oturum maliyeti

CDN yoksa veya bağlantı kurulum maliyeti yüksekse ilk isteklerde TTFB artar.
Yanlış DNS çözümleme veya uzak lokasyondan test yapmak da değerleri etkiler.

5) Ağ / WAF / throttling etkisi

Rate limit veya güvenlik kuralı bazı istekleri yavaşlatır.
Network throttling (ağ kısıtlaması) özellikle bedava veya düşük kaynaklı planlarda daha belirgin olabilir.

TTFB’yi düşürme: katman katman uygulanabilir adımlar

Bu bölümde uygulama, sunucu, kontrol paneli/otomasyon ve CDN tarafında net aksiyonlar göreceksiniz. Hedef: Aynı URL’de TTFB’yi düzenli şekilde düşürmek.

1) Cache stratejisini doğru kurun (en hızlı kazanımlar)

İlk hedefiniz, HTML ve/veya kritik sayfa parçaları için cache-hit oranını artırmak olmalı.

Checklist: - CMS (WordPress, framework’ler vb.) için sayfa cache (sayfa önbelleği) etkin mi? - CDN kullanıyorsanız “Cache-Control” başlıkları ile CDN’in cache tutmasına izin veriliyor mu? - Oturum (session) bilgisi cache’i bozuyor mu? Kullanıcıya özel içerik varsa ayrı varyant planlayın. - Vary başlıkları aşırı artmış mı? (Çok fazla varyant = cache-hit düşer.)

Örnek hedefler (tek sayı değil): - Tekrarlı testlerde TTFB’nin belirgin düşmesi (ilk istekten sonraya geçiş) - CDN üzerinden gelen isteklerde cache-hit oranının artması

2) Veritabanı sorgularını “TTFB ile” birlikte optimize edin

TTFB yüksekliğinde veritabanını göz ardı etmeyin. Uygulama hızlı olsa bile DB yavaşsa ilk byte gecikir.

Net uygulamalar: - En pahalı sorguları bulmak için slow query log açın. - İndeksleri kontrol edin: WHERE, JOIN ve ORDER BY kolonlarında indeks yoksa TTFB şişer. - N+1 sorgu problemine bakın (ORM kullanıyorsanız ilişkileri toplu çekin). - Sayfa başına kaç sorgu çalıştığını ölçün.

Hızlı karar kuralı: - Aynı URL’nin TTFB’si yoğun saatlerde ciddi artıyorsa DB + iş kuyruğu birlikte çalışıyor olabilir. - DB kaynaklı şişme varsa, yalnızca daha güçlü CPU almak yerine sorgu/indeks düzeltmesi öncelik olmalıdır.

3) Uygulama sunucusu işçi sayısı ve timeout ayarlarını düzeltin

TTFB çoğu zaman “cevap üretme” süresidir ama yoğunlukta “bekleme” de eklenir.

Örnek yaklaşım: - PHP-FPM kullanıyorsanız pm.max_children, pm.max_requests ve benzeri ayarlar kapasiteyi etkiler. - Node.js tarafında cluster/worker düzeni, istek başına CPU maliyeti ve event loop tıkanması TTFB’yi doğrudan etkiler. - Uygulama içi timeout’lar çok kısa ise yeniden denemeler veya yavaş fallback mekanizmaları gecikme yaratır.

Net kontrol: - İşçi sayısı yetersizse TTFB artar ve kuyruk oluşur. - CPU kullanımı yüksekse uygulama kaynak tıkanması yaşıyordur; sadece cache eklemek tek başına yetmeyebilir.

4) Sunucu tarafında HTTP/TLS ve bağlantı optimizasyonu yapın

Bu bölüm “küçük ama net” kazanımlar sağlar. Özellikle ilk isteklerde farkı görülebilir.

Öneriler: - HTTP/2 veya mümkünse HTTP/3 (QUIC) kullanımını doğrulayın (altyapı uygunsa). - TLS oturum tekrarını (session resumption) etkinleştirin. - Keep-Alive sürelerini doğru ayarlayın. - Gereksiz yönlendirme (redirect) zincirini temizleyin.

5) CDN’i doğru konfigüre edin: “cache-hit” hedefi koyun

CDN’in varlığı TTFB’yi otomatik düşürmez. CDN’in cache’i gerçekten sunuyor olması gerekir.

Net kontrol listesi: - CDN cache alan ana URL’ler: HTML sayfalarınız cacheleniyor mu? - Başlıklar: Cache-Control, ETag, Last-Modified CDN davranışını etkiler. - Cookie/Authorization kullanımı: Her istek cookie ile gidiyorsa CDN genellikle cache’i zorlar. - Varyantlar: Dil (Accept-Language), cihaz tipi (User-Agent) gibi parametreler varyantı artırıyorsa cache-hit düşer.

6) VDS/VPS kaynak planlaması: TTFB’yi düşürmek için doğru kapasite

TTFB’yi düşürmek için bazen yalnızca yazılımı optimize etmek yetmez; kaynak planlaması gerekir. Buradaki fark: “daha fazla RAM/CPU” her zaman doğru çözüm değildir; ama yetersiz kaynak TTFB’yi kesin bozar.

Aşağıdaki pratik eşleştirme: - PHP-FPM veya statik olmayan içerik yoğun ise: CPU + worker kapasitesi - DB yoğun ise: disk IOPS ve DB buffer cache - Node.js etkinse: event loop tıkanması ve concurrency

NetKıyas’ta karşılaştırırken bakmanız gereken noktalar: - Bulut depolama türü (performans profili) - VDS’in CPU limitleri (burst/guaranteed) - Ağ kalitesi (latency) - Yedekleme stratejisi (değişiklik yapmadan önce geri dönüş imkanı)

7) Değişiklikleri güvenle test edin (regresyon önleyici plan)

TTFB düşürürken başka metrikleri bozma riski vardır (ör. cache yanlışsa yanlış içerik gösterme).

Uygulama planı: 1. Önce ölç: 3-5 tekrar ile TTFB değerini kaydedin. 2. Tek seferde tek değişiklik yapın (cache başlığı, indeks, worker ayarı gibi). 3. Sonra tekrar ölçün: Aynı URL, aynı test koşulları. 4. Değişiklik geri alınabilir mi? Yedek (backup) veya hızlı rollback var mı?

Sonuç: TTFB için “tek hamlede” değil, ölçülebilir adımlarla ilerleyin

TTFB; cache, uygulama işleme hızı, veritabanı ve kaynak/iş kuyruğu gibi farklı katmanların ortak sonucudur. Bu yüzden doğru yaklaşım, önce ölçümle kök nedeni ayırmak, sonra cache-hit’i artırmak ve en ağır sorguları indeks/optimizasyonla düzeltmektir. Son olarak HTTP/TLS ve CDN davranışını kontrol ederek ilk byte süresini kalıcı şekilde düşürün.

Aksiyon önerisi: Bugün kullandığınız 3 kritik URL için (ana sayfa, kategori sayfası, ürün/haber sayfası gibi) TTFB’yi tekrar eden testlerle ölçün. Ardından önce cache davranışını (cache-control + CDN cache-hit), sonra veritabanı tarafındaki en ağır sorguları (slow query log + indeks) hedefleyin. Bu sırayla ilerlediğinizde TTFB’de düşüşü hem sayısal hem de kalıcı şekilde görmeniz mümkün olur.