TTFB nedir? (Time to First Byte) ve 2026’da düşürme rehberi

TTFB (Time to First Byte), bir kullanıcının sayfadan ilk yanıtı ne kadar sürede aldığını gösteren en kritik performans sinyallerinden biridir. Yavaş TTFB; sayfa etkileşimi, SEO metrikleri ve kullanıcı terkini doğrudan etkiler. Bu yazıda TTFB’nin ne olduğunu, nasıl ölçüldüğünü ve VDS/VPS üzerinde veya hosting tarafında TTFB’yi düşürmek için uygulanabilir adımları sıralayacağız.

TTFB (Time to First Byte) nedir?

TTFB, tarayıcının isteği gönderdikten sonra ilk yanıt baytını (first byte) alması için geçen süreyi ifade eder. Ölçüm “sayfanın tamamen yüklenmesi” değil, sunucunun ilk yanıtı üretmeye başlaması ile ilgilidir.

TTFB’yi etkileyen ana zincir şu şekilde düşünülür: - DNS çözüm süresi (her zaman TTFB ölçümüne dahil olmayabilir) - TCP/TLS bağlantısı kurulması - HTTP isteğinin sunucuya ulaşması - Uygulamanın isteği işleyip ilk yanıtı üretmesi - Sunucunun ilk baytı göndermesi

Bu nedenle TTFB; uygulama (app) katmanı, web sunucusu (Nginx/Apache/LiteSpeed), veritabanı (DB), cache, CDN ve kısa yol (network) bileşenlerinden etkilenir.

TTFB neden sadece “hosting yavaştır” demek değildir?

TTFB değerini bozan etken çoğu zaman şu üç başlıktan çıkar: 1) Uygulama isteği yavaş işliyor (ör. yavaş sorgu, ağır şablon render, senkron IO) 2) Cache yok veya yanlış yapılandırılmış (her istekte dinamik üretim) 3) İlk paket gecikiyor (TLS/HTTP ayarları, oversize yük, kaynak darboğazı)

İyi TTFB kaç ms? Kötü TTFB hangi durumda?

TTFB için tek bir “evrensel” eşik yoktur; sayfa türü ve mimari belirleyicidir. Ancak pratik değerlendirme için şu çerçeveyi kullanın:

• 0–200 ms: Çok hızlı (genellikle iyi CDN/cache + hazır içerik)
• 200–500 ms: Kullanılabilir ama iyileştirme şansı yüksek
• 500–1000 ms: Kullanıcı algısını belirgin etkiler, kök neden araştırılmalı
• >1000 ms: Net şekilde sorun var; DB/uygulama gecikmesi veya cache kaçırma çok olası

Özellikle dinamik sayfalar (kullanıcıya göre değişen içerik) için 500–800 ms görülebilir; fakat aynı URL için tekrarlı ölçümlerde sürekli artış varsa kök nedene inmek gerekir.

TTFB nasıl ölçülür? (Net yöntemlerle)

TTFB’yi ölçerken aynı URL, aynı koşul ve aynı kullanıcı/konum için kıyas yapmak gerekir. En sık kullanılan ölçüm yöntemleri:

Tarayıcı / DevTools

• Chrome DevTools → Network sekmesi
• Sayfa isteğini seçin
• TTFB benzeri zamanlama değerlerini inceleyin (bazı görünümlerde “Waiting (TTFB)” ya da “Time to first byte” karşılığı yer alır)

Lighthouse / WebPageTest / PageSpeed Insights

• Lighthouse “lab” verisi üretir; varyans olabilir
• WebPageTest’te tekrar denemeler ve farklı lokasyon seçimi daha sağlıklı kıyas sağlar

Sunucu tarafı doğrulama

TTFB’nin uygulama mı yoksa sunucu mü olduğunu anlamak için logları birlikte okumak gerekir: - Web sunucu access log: isteğin sunucuya geliş ve yanıt süreleri - Uygulama logları: istek işleme süresi - DB slow query log: yavaş sorgular

Net hedef: Aynı URL için hem tarayıcı tarafında TTFB’yi düşürün hem de sunucu tarafında “ilk yanıtın üretim süresi” azalsın.

TTFB’yi düşürmek için 2026’da uygulanabilir adımlar

Aşağıdaki maddeler, TTFB’yi düşürmede en yüksek etkiyi getiren sıraya göre listelenmiştir. Uyguladığınızda ölçümle doğrulayın.

1) CDN ve cache: İlk baytı daha yakından servis edin

TTFB’yi düşürmenin en pratik yolu, mümkün olan içerikleri CDN üzerinden cache’lemek ve uygulamanın her istek için dinamik üretim yapmasını engellemektir.

Hangi içerikler cache’lenmeli?

• Görsel, CSS, JS dosyaları: agresif cache
• Tam sayfa HTML: mümkünse edge cache veya server-side cache
• Sitemap, robots, standart landing sayfaları: yüksek TTL

Dinamik içerik zorunluysa bile şu yöntemler işe yarar: - “Shell” yaklaşımı: sayfanın değişmeyen kısmını cache’le - Kullanıcı bazlı parçaları ayrı endpointlerden servis et

Cache yanlışsa TTFB artar

Aşağıdaki durumlar “cache yok” etkisi yaratır: - Cache-Control header’ları hatalı - Vary (Vary: Accept-Encoding vb.) yüzünden cache’lenmeme - Query parametresi yüzünden her isteğin farklı sayılması

2) Web sunucu ayarları: İlk yanıtın gecikmesini azaltın

Web sunucu katmanında hedef, ilk yanıt üretimi öncesinde beklemeyi azaltmaktır.

HTTP/2 / HTTP/3 ve TLS optimizasyonu

• HTTP/2: çoklu istekte daha iyi performans
• TLS handshake maliyetini azaltmak için CDN veya uygun session ayarları
• İstemci ile sunucu arasında gereksiz round-trip varsa lokasyon etkisi büyür

Nginx/Apache/LiteSpeed için odak noktaları

Sunucuya göre farklılıklar olsa da kontrol edeceğiniz alanlar şunlardır: - Keep-Alive süreleri - Worker/Thread ayarları (CPU doygunluğu varsa TTFB uzar) - Büyük dosyalarda doğru buffer ayarları

3) Uygulama performansı: TTFB’nin en yaygın kök nedeni

TTFB’nin “ilk byte” üretimindeki gecikme çoğu zaman uygulama işleme süresinden gelir.

DB sorgularını hızlandırın

En sık görülen hatalar: - İndeks yok (özellikle WHERE + JOIN kolonlarında) - N+1 query (ORM kaynaklı) - Her istek için aynı verinin tekrar çekilmesi

Yapılacak net işler: - Slow query log’u açın (örn: PostgreSQL’de pg_stat_statements veya slow query log) - En yavaş sorguları tespit edin - Uygun indeks ekleyin - Sık kullanılan veriyi cache’leyin

Template render ve senkron işler

• Template içinde tekrar eden ağır hesaplar
• Senkron dış servis çağrıları (API) ve timeout yokluğu

Çözüm yaklaşımı: - Ağır hesapları önceden üretin (cache/precompute) - Timeout belirleyin - “İlk byte” kritikse, dış çağrıları paralel veya arka planda kurgulayın (tasarıma göre)

Kod düzeyinde gecikme ölçümü

Uygulamada istek akışını parçalayın: - Routing - Auth - DB - Template render - Response gönderimi

Net hedef: TTFB’nin uzadığı segmenti bulup oraya müdahale etmek.

4) Cache katmanlarını doğru kurgulayın: Browser, CDN, server-side

TTFB, özellikle server-side rendered (SSR) sitelerde “ilk HTML üretimi” ile ilişkilidir.

Önerilen katmanlar: - CDN edge cache: HTML ve statik dosyalarda en büyük etki - Uygulama cache: sayfa parçaları veya sorgu sonuçları - Tarayıcı cache: tekrar ziyaretlerde RTT’yi azaltır

Aşağıdaki tabloyu bir karar rehberi gibi kullanın:

5) Kaynak darboğazını kaldırın: CPU, RAM, I/O

TTFB, sunucu kaynaklarının doygunluğunda doğrudan artar.

Net kontrol listesi: - CPU sürekli %80+ seyrediyor mu? - RAM swap’a düşüyor mu? (swap kullanımı TTFB’yi dramatik artırır) - Disk I/O bekleme süreleri artmış mı? - Yük altında thread/worker sayısı yetersiz mi?

VDS/VPS tarafında çözüm: - Uygun iş parçacığı/worker ayarları - PHP-FPM/Node/Golang runtime ayarları - Gerekirse ölçekleme (daha yüksek CPU/RAM) veya dikey değilse yatay ölçek

6) Veritabanı ve bağlantı maliyetlerini azaltın

Her istekte yeni bağlantı kurmak (DB connection churn) TTFB’yi yükseltir.

Net iyileştirmeler: - Bağlantı havuzu (connection pooling) kullanın - Uygulamada pool ayarlarını doğru yapılandırın - Çok sayıda eşzamanlı istek DB’yi boğuyorsa query optimizasyonu + indeks şart

7) Ölçüm disiplinini kurun: Değişiklik sonrası doğrulama

TTFB’yi düşürdüğünüzü “hissetmek” yerine sayısal doğrulayın.

Pratik ölçüm planı

1) Değişiklik öncesi: aynı URL’yi 5-10 kez ölçün (en az) 2) Değişiklik sonrası: tekrar 5-10 kez ölçün 3) Median (ortanca) ile kıyas yapın

Tek seferlik ölçüm; anlık yoğunluk veya ağ dalgalanması yüzünden yanıltır.

Uygulama örnekleri: Somut hedef senaryoları

Senaryo A: Cache yok, SSR sayfa TTFB 900 ms

Hedef: 900 ms → 400 ms altı - CDN’de HTML cache kur - Cache-Control ve varyantları düzelt - Uygulamada DB sorgularını indeksle

Beklenen sonuç: - Aynı URL’de TTFB düşer çünkü dinamik üretim azalır

Senaryo B: Dinamik içerik var, ama parçalar tekrar eden

Hedef: 700 ms → 500 ms - Sayfa “shell” kısmını cache’le - Kullanıcıya özel parçaları ayrı endpoint ile veya fragment cache ile üret

Beklenen sonuç: - İlk HTML daha hızlı hazırlanır; kullanıcı özel kısım sonradan tamamlanır

Senaryo C: Sunucu yoğun, kaynak darboğazı

Hedef: 1200 ms → 800 ms altı - Worker sayısı ve runtime ayarlarını gözden geçir - CPU/RAM/I/O durumunu düzelt - Gerekirse ölçekleme

Beklenen sonuç: - TTFB artış dalgaları azalır

NetKıyas ile doğru altyapıyı seçerken TTFB’yi nasıl bağlarsınız?

TTFB; tek başına “VDS/VPS fiyatı” ile bire bir değişmez. Ancak altyapı seçerken şu teknik kriterler kararınızı hızlandırır:

• CPU/RAM oranı: Uygulamanız CPU-bound ise sadece RAM artışı tek başına çözmez
• Disk tipi ve IOPS: DB ve cache performansını etkiler
• Lokasyon: CDN ile desteklenmiyorsa kullanıcı lokasyonu TTFB’yi büyütür
• Cache/edge imkânı: Managed CDN veya WAF/CDN entegrasyonu varsa ilk byte süresi düşer

Kontrol listesi: TTFB düşürmek için 15 dakikalık başlangıç planı

• [ ] En yavaş 5 URL’yi listeleyin (TTFB > 700 ms olanlar)
• [ ] Her URL için 5 kez ölçüm alıp median çıkarın
• [ ] En yavaş URL’de DB slow query var mı kontrol edin
• [ ] Cache-Control header’larını gözden geçirin (CDN ve server-side)
• [ ] Nginx/Apache/LiteSpeed tarafında worker ve keep-alive mantığını doğrulayın
• [ ] Uygulamada template render ve harici servis çağrılarını izleyin
• [ ] DB connection pooling kullanılıyor mu kontrol edin
• [ ] Değişiklik sonrası aynı URL’leri tekrar ölçün

Sonuç: Aksiyon alarak TTFB’yi düşürün

TTFB’yi düşürmenin yolu “genel performans iyileştirmesi” değil, ilk byte gecikmesinin hangi zincirde oluştuğunu netleştirmektir. İlk adım olarak en yavaş URL’leri ölçün, ardından cache (CDN + server-side), DB sorguları ve kaynak darboğazı üçlüsünde hedefli aksiyon alın. Bu yaklaşımı uygularsanız TTFB’yi sayısal olarak düşürür, kullanıcı deneyimini ve dönüşüm metriğini doğrudan iyileştirirsiniz.