TTFB (Time to First Byte) Nedir?
Kısa tanım
TTFB (Time to First Byte), tarayıcının bir sayfaya gitmeye başladığı andan sunucu yanıtının ilk baytı gelmeye başlayana kadar geçen süredir. Yönlendirmeleri, DNS sorgusunu, bağlantı ve TLS kurulumunu ve sunucunun yanıtı hazırlama süresini kapsar. Core Web Vitals metriği değildir; web.dev, 75. yüzdelikte 0,8 saniye veya altını iyi kabul eder.
Diğer adları: Time to First Byte, ilk bayta kadar geçen süre, ilk bayt süresi, sunucu yanıt süresi
İlk bayta kadar neler oluyor?
Kullanıcı bir bağlantıya tıkladığında sunucu daha tek bir satır HTML göndermeden önce birkaç adım tamamlanır. TTFB bu adımların toplamıdır:
- Yönlendirmeler: İlk adres 301 veya 302 döndürüyorsa her sıçrama süreye eklenir.
- Service worker başlatma: Sayfayı bir service worker kontrol ediyorsa onun ayağa kalkması da hesaba girer.
- DNS sorgusu: Alan adının IP adresine çözülmesi.
- Bağlantı ve TLS: TCP (veya QUIC) bağlantısı ile HTTPS şifreleme el sıkışması.
- Sunucu süresi: İsteğin işlenmesi; veritabanı sorguları, şablonun render edilmesi, varsa harici API çağrıları. Ölçüm, yanıtın ilk baytı tarayıcıya ulaştığında biter.
Bu yüzden TTFB'yi yalnızca "sunucu hızı" olarak okumak eksik kalır. Hızlı bir uygulama sunucusu, uzak bir veri merkezi ya da iki aşamalı bir yönlendirme zinciri yüzünden yine de yüksek TTFB üretebilir.
Eşik değerleri ve doğru beklenti
| Değerlendirme | TTFB (75. yüzdelik) |
|---|---|
| İyi | ≤ 0,8 sn |
| İyileştirme gerekli | 0,8–1,8 sn |
| Zayıf | > 1,8 sn |
TTFB, Core Web Vitals'ın parçası değildir ve web.dev de bu eşiği zorunlu bir hedef olarak değil, kaba bir rehber olarak sunar. Önemi dolaylıdır: ilk bayt gelmeden hiçbir şey çizilemeyeceği için TTFB'deki her milisaniye FCP'ye ve LCP'ye doğrudan eklenir. Sunucuda render edilen sitelerde TTFB, HTML'in üretilme süresini de içerdiği için daha yüksek çıkabilir ama karşılığında anlamlı içerik hemen gelir. Boş bir HTML kabuğu gönderip içeriği JavaScript ile dolduran sitelerde ise ilk baytın çabuk gelmesi daha da kritiktir; çünkü asıl iş, bu baytlar geldikten sonra başlar.
Sahada ve laboratuvarda ölçüm
Gerçek kullanıcı ölçümünde TTFB, Navigation Timing API'deki responseStart değerinden okunur:
const [nav] = performance.getEntriesByType("navigation");
// Navigasyonun başlangıcından ilk yanıt baytına kadar geçen süre (ms)
console.log(nav.responseStart);web-vitals kütüphanesinin onTTFB() fonksiyonu aynı değeri analitik sisteminize göndermeyi kolaylaştırır. Chrome kullanıcılarının saha verisi PageSpeed Insights'ta da görülebilir. Laboratuvarda ise DevTools'un Network panelindeki zamanlama sekmesi, sürenin DNS, bağlantı ve sunucu bekleme arasında nasıl dağıldığını gösterir. Sunucu tarafını parçalamak için Server-Timing başlığı kullanışlıdır:
Server-Timing: db;dur=48, render;dur=112Bir not: 103 Early Hints yanıtı gönderen sunucularda bu ara yanıt "ilk bayt" sayılır. Bu durum ölçümü iyi gösterirken asıl HTML'in geç gelmesini gizleyebilir; araçlar arasında farklı sonuç görürseniz ilk bakılacak yer burasıdır.
Yüksek TTFB'nin olağan şüphelileri
- Önbelleksiz HTML: Her istekte sayfayı baştan üretmek. Kısa süreli bir HTML önbelleği bile yoğun sayfalarda büyük fark yaratır; kuralları Cache-Control başlığıyla belirlenir.
- Coğrafi mesafe: Sunucu kullanıcıdan uzaktaysa her gidiş-dönüş gecikme ekler. İçeriği kullanıcıya yakın uç noktalardan sunan bir CDN bu mesafeyi kısaltır.
- Yavaş sorgular: İndekssiz veritabanı sorguları, yanıtı bekletilen harici servisler, soğuk başlatma yaşayan serverless fonksiyonlar.
- Gereksiz yönlendirmeler: http → https → www → sondaki eğik çizgi gibi zincirler. HSTS, tekrar ziyaretlerde HTTP'den HTTPS'e yönlendirmeyi ortadan kaldırır.
Hangi aşamanın pahalı olduğunu bilmeden yapılan iyileştirme çoğu zaman yanlış yere harcanır; önce süreyi parçalara ayırıp ölçmek gerekir. Ayrıntılı tanım ve öneriler web.dev üzerinde yer alır.