19 Eylül 2026
TTFB (Time to First Byte / İlk Bayta Kadar Geçen Süre), gezinme başladıktan sonra tarayıcının yanıtın ilk baytını almasına kadar geçen süredir. TTFB tek başına sunucunun işlem süresi değildir: ağ gecikmesi, bağlantı kurulumu, yönlendirmeler ve sunucunun yanıtı hazırlaması ölçümü etkileyebilir.
TTFB, Core Web Vitals metriği değildir; bu metrik grubunda LCP, INP ve CLS yer alır. Yine de ilk HTML yanıtı gecikirse FCP ve LCP gibi sonraki ölçümlerin başlaması da gecikebilir. Bu nedenle TTFB’yi bir sıralama hedefi gibi değil, gerçek kullanıcı deneyimindeki gecikmenin olası nedenlerini bulmak için teşhis sinyali olarak kullanın. web.dev TTFB rehberi çoğu site için 800 ms veya altını kaba bir hedef olarak verir; bu evrensel bir garanti ya da tek başına başarı ölçütü değildir.
TTFB neleri kapsar?
Tarayıcı, navigasyon başlangıcından yanıtın ilk baytının gelişine kadar geçen süreyi ölçer. Ölçüm; kullanıcının ağı ve konumu, DNS ve bağlantı kurulumu, TLS, bir veya daha fazla yönlendirme, sunucu veya edge katmanının işi ve önbellek durumundan etkilenebilir. Chrome DevTools’taki Waiting (TTFB) aşaması bir ağ gidiş-dönüşünü ve sunucunun yanıtı hazırlama süresini içerir. Bu yüzden TTFB’yi “PHP/Node çalışma süresi” ya da yalnızca origin sunucu süresi olarak okumayın.
TTFB, LCP’nin kendisi veya LCP’nin tamamı değildir. LCP’nin toplamı; ilk bayta kadar geçen süreye ek olarak LCP kaynağının keşfi, indirilmesi ve ekranda çizilmesi için geçen zamanı da kapsar. TTFB’yi düşürmek sonraki aşamalara zaman kazandırabilir; ancak tarayıcı tarafındaki kaynak gecikmelerini veya render engellerini tek başına düzeltmez. LCP alt aşamalarını inceleyin.
Hangi TTFB değeri iyi sayılır?
web.dev’nin genel rehberindeki yaklaşık eşikler, kullanıcıların 75. yüzdelik dilimindeki ölçüme göre şöyledir:
| TTFB | Genel yorum |
|---|---|
| 800 ms veya daha az | İyi için kaba rehber |
| 800-1800 ms | İyileştirme alanı |
| 1800 ms üzeri | Yüksek gecikme; nedeni araştırın |
Bunları garanti, Google sıralama eşiği veya bütün sayfalara uygulanacak hedef olarak kullanmayın. Sitenin render modeli, içerik teslim şekli, coğrafi dağılımı ve daha önemli olan gerçek FCP/LCP sonuçları yorumlamayı değiştirir. İyi TTFB bile kötü LCP’yi dışlamaz.
Önce doğru veriyi ölçün
- Gerçek kullanıcı verisini (field/RUM) kontrol edin. PageSpeed Insights’ta URL düzeyinde CrUX verisi varsa cihaz türüne göre inceleyin; yalnızca origin verisi varsa bunu tek bir sayfanın sonucu gibi raporlamayın. Site kendi RUM verisini topluyorsa örneklem, navigasyon tipi, bölge ve cihaz kırılımlarını kaydedin.
- 75. yüzdelik dilimi ve eğilimi karşılaştırın. Tek Lighthouse çalışması ya da tek istek kararı vermek için yeterli değildir. Trafiğin geldiği bölgeyi, soğuk/sıcak önbelleği ve aynı URL’nin yönlendirmeli veya yönlendirmesiz girişlerini karşılaştırın.
- Laboratuvar ölçümünü tanı koymak için kullanın. Chrome DevTools Network panelinde ana HTML isteğini seçip Timing sekmesindeki Waiting (TTFB) ile DNS, Initial connection ve redirect aşamalarını ayırın. Chrome DevTools ölçüm açıklaması TTFB beklemesinin ağ gidiş-dönüşü ve sunucu hazırlama süresini içerdiğini belirtir.
- Saha ve laboratuvar farkını açıklayın. Laboratuvar testi son URL’yi doğrudan açıyorsa önceki yönlendirme süresini kaçırabilir. Önbellek, coğrafya, ağ koşulları ve cihaz farkları da sonuçları değiştirir. web.dev, kullanıcı deneyimini anlamada saha verisini temel almayı ve laboratuvarı sorun ayıklamak için kullanmayı önerir.
Yavaş TTFB’yi adım adım teşhis edin
1. Yönlendirme zincirini ve ilk isteği kontrol edin
HTTP→HTTPS, eski URL→yeni URL, slash normalizasyonu, bölge veya dil seçimi gibi gereksiz ardışık yönlendirmeleri bulun. Eski URL’yi laboratuvarda atlayıp doğrudan son URL’yi test etmek kullanıcı yolundaki gecikmeyi gizleyebilir. Her yönlendirme kuralının tek, doğru ve kalıcı hedefe ulaştığını doğrulayın; kullanıcı veya bot türüne göre farklı yanıt üretmeyin.
2. İsteklerin hangi katmanda beklediğini ayırın
Network zaman çizelgesinde DNS, bağlantı/TLS, yönlendirme ve Waiting (TTFB) bölümlerini karşılaştırın. Waiting uzunsa sunucu uygulaması, veritabanı, dış servis, kuyruk veya edge cache yanıtı hazırlıyor olabilir. DNS veya bağlantı bölümü uzunsa ağ, çözümleyici, TLS ya da kullanıcının origin’e uzaklığı araştırılmalıdır. Tek bir toplam sayı bu ayrımı yapmaz.
3. Gerçek sunucu izleriyle pahalı işi bulun
Yüksek TTFB görülen URL ve zaman aralığını uygulama izleri, APM, web sunucusu erişim kayıtları ve veritabanı sorgu süreleriyle eşleştirin. Dinamik sayfalarda yavaş sorguları, N+1 sorguları, senkron dış API çağrılarını, gereksiz middleware ve soğuk başlangıçları araştırın. Değişiklikten önce aynı istek, önbellek durumu ve bölge koşullarını kaydedin.
4. Önbelleği güvenli ve ölçülebilir kullanın
Tekrar üretilebilir, kişiselleştirilmemiş HTML ve veriler için uygun CDN, reverse proxy, uygulama veya veri önbelleği TTFB’yi azaltabilir. Cache key’in host, yol ve gerçekten gerekli varyasyonları kapsadığını; cookie, oturum, yetki, dil veya para birimi gibi farklı içerikleri yanlışlıkla ortaklaştırmadığını doğrulayın. Giriş yapmış kullanıcıların, sepet/ödeme akışlarının ve özel verilerin genel önbelleğe sızmasını önleyin. Geçersiz kılma (purge), TTL ve hata durumundaki eski içeriği sunma davranışını test edin. “Her HTML’i CDN’de cache’le” güvenli bir varsayılan değildir.
5. Sunucu kapasitesi ve konumunu talebe göre iyileştirin
CPU/bellek baskısı, eşzamanlılık sınırları, disk ve veritabanı darboğazlarını ölçün. Yalnızca TTFB yüksek ve bunun sebebi kapasite/uzaklık olarak doğrulanmışsa runtime veya hosting katmanını değiştirin. CDN/edge HTML cache ya da bölgesel origin, uzak kullanıcıların ağ gecikmesini azaltabilir; ancak dinamik yanıt, cache doğruluğu ve cache miss davranışı ayrıca değerlendirilmelidir. HTTP/3 ya da belirli bir sağlayıcı tek başına TTFB’yi garanti etmez.
Değişiklik sonrası doğrulama
- Aynı URL şablonları, cihaz/bölge dilimleri ve cache sıcaklıklarıyla önce/sonra ölçün.
- Laboratuvarda birkaç tekrar alıp medyanı ve dağılımı raporlayın; saha verisindeki p75 eğilimini ayrıca izleyin.
- LCP ve FCP’yi birlikte kontrol edin. TTFB düştüğü halde LCP değişmiyorsa LCP kaynağının keşif/indirme/render aşamasını inceleyin.
- Yanıt içeriği, HTTP durumu, canonical, varyasyonlar ve önbellek güvenliğini regresyon testlerinden geçirin.
- Sonucu “TTFB iyileşti” diye ölçüm kanıtıyla raporlayın; bunun organik sıralamayı artırdığını ayrıca veri olmadan iddia etmeyin.
Sık sorulan sorular
TTFB bir Core Web Vitals metriği midir?
Hayır. web.dev TTFB’yi Core Web Vitals dışında, sonraki render metriklerini anlamaya yarayan bir teşhis ölçümü olarak tanımlar. Google’ın Core Web Vitals seti LCP, INP ve CLS’ten oluşur.
TTFB, LCP’nin doğrudan alt bileşeni midir?
LCP zaman çizgisinde ilk alt aşama TTFB’dir; ancak TTFB ile LCP aynı metrik değildir. Kaynak keşfi, kaynak indirme ve elementin çizilmesi de LCP süresine eklenir.
TTFB’yi 200 ms altına indirmek zorunlu mu?
Hayır. 200 ms evrensel veya Google tarafından belirlenmiş bir eşik değildir. Önce saha p75’ini ve LCP/FCP’yi ölçün; 800 ms önerisini de yalnızca genel bir başlangıç rehberi olarak değerlendirin.
Paylaşımlı hosting her zaman yavaş TTFB üretir mi?
Hayır. Barındırma türü tek başına sonucu belirlemez. Uygulama yükü, kaynak paylaşımı, önbellek, konum, ağ ve talep profili ölçülmelidir. Taşıma kararı ölçüm ve maliyet/işletim gereksinimleriyle verilmelidir.
İlgili yazılar
- Core Web Vitals nedir? Optimizasyon rehberi
- Sayfa yüklenme hızı optimizasyonu
- Teknik SEO kontrol listesi
- React SEO: React sitelerinde arama motoru optimizasyonu