TTFB (Time to First Byte), tarayıcının isteği göndermesinden sunucudan ilk baytın gelmesine kadar geçen süredir; yönlendirmeleri, DNS, bağlantı ve TLS kurulumunu ve sunucunun isteği işleme süresini içerir. Google'ın web.dev rehberi çoğu site için 0,8 saniye veya altını hedef olarak gösterir. Yüksek TTFB genellikle önbellek eksikliği, yavaş veritabanı sorguları, yetersiz sunucu kaynağı veya kullanıcıya uzak lokasyondan kaynaklanır.
Bu yazıda TTFB'yi bileşenlerine ayıran bir curl komutu, iyi değer aralıkları ve her katmanda TTFB'yi düşürmenin yolları yer alıyor. Ölçümler sorunun sunucu tarafında olduğunu gösteriyorsa sunucu tarafı performans optimizasyonu için teklif alabilirsiniz.
TTFB nedir?
TTFB, bir sayfa isteğinin başlamasıyla yanıtın ilk baytının tarayıcıya ulaşması arasındaki süredir. Sayfanın tamamının yüklenme süresi değildir; tarayıcının HTML'i işlemeye ne zaman başlayabileceğini belirler.
Genellikle HTML belgesi için ölçülür. Tarayıcı, ilk bayt gelmeden ne görselleri ne stil dosyalarını ne de betikleri indirmeye başlayabilir; bu yüzden TTFB, sonraki tüm yükleme adımlarının başlangıç çizgisidir. Ön yüz (frontend) optimizasyonu, yüksek TTFB'nin yarattığı gecikmeyi büyük ölçüde telafi edemez.
TTFB hangi aşamalardan oluşur?
web.dev tanımına göre TTFB şu aşamaların toplamıdır: yönlendirme süresi, varsa service worker başlatma süresi, DNS çözümlemesi, bağlantı ve TLS kurulumu ve ilk bayt gelene kadar geçen istek süresi.
| Aşama | Ne olur? | Tipik uzama nedeni | Ne kısaltır? |
|---|---|---|---|
| Yönlendirme | Tarayıcı başka bir adrese yönlendirilir, süreç yeniden başlar | http → https, www ↔ www'suz zincirleri | Doğrudan son adrese bağlantı, HSTS |
| DNS | Alan adı IP adresine çözülür | Yavaş veya uzak DNS sunucusu, düşük TTL | Hızlı DNS altyapısı, makul TTL |
| TCP bağlantısı | Sunucuyla bağlantı kurulur (bir gidiş-dönüş) | Sunucunun kullanıcıya uzaklığı | Yakın lokasyon, CDN, bağlantının yeniden kullanımı |
| TLS el sıkışması | Şifreli oturum anlaşması | TLS 1.2, uzak sunucu | TLS 1.3, HTTP/3 |
| Sunucu işleme | Uygulama sayfayı üretir, ilk bayt gönderilir | Önbellek yok, yavaş sorgu, dolu PHP havuzu | Sayfa önbelleği, PHP-FPM ve veritabanı ayarları |
Yönlendirmeler
Her yönlendirme, yeni bir istek ve çoğu zaman yeni bir bağlantı demektir. http://alanadiniz.com → https://alanadiniz.com → https://www.alanadiniz.com gibi bir zincir, kullanıcı daha sayfayı görmeden birkaç gidiş-dönüş harcatır. İç linkleri ve reklam bağlantılarını doğrudan son adrese verin; HSTS başlığı tarayıcının sonraki ziyaretlerde http → https adımını atlamasını sağlar.
DNS
Tarayıcı alan adını IP adresine çevirmeden bağlantı kuramaz. Sonuç önbelleğe alındığı için DNS süresi genellikle yalnızca ilk ziyarette belirgindir. Kayıtların TTL değerini gereksiz yere çok düşük tutmak, çözümlemenin sık tekrarlanmasına yol açar.
TCP ve TLS bağlantısı
TCP bağlantısı bir gidiş-dönüş (RTT) sürer; TLS 1.3 tam el sıkışmayı bir, TLS 1.2 iki gidiş-dönüşte tamamlar. İlk bayt için isteğin gidip yanıtın dönmesi de bir gidiş-dönüş daha ekler. Bu yüzden yeni bir HTTPS bağlantısında sunucuya uzaklık, TTFB'ye birkaç kat olarak yansır.
Sunucunun isteği işleme süresi
Uygulamanın sayfayı üretmesi için geçen süredir: PHP kodunun çalışması, veritabanı sorguları, dış servis çağrıları. Dinamik sitelerde TTFB'nin en değişken ve en çok iyileştirilebilen kısmıdır.
İyi bir TTFB değeri nedir?
web.dev rehberine göre çoğu site 0,8 saniye veya altını hedeflemelidir; 1,8 saniyenin üzeri kötü kabul edilir.
| Değer | Değerlendirme (web.dev) |
|---|---|
| 0,8 saniye veya altı | İyi |
| 0,8 – 1,8 saniye | İyileştirme gerekli |
| 1,8 saniyenin üzeri | Kötü |
Aynı rehber TTFB'nin bir Core Web Vitals metriği olmadığını, bu yüzden "iyi" eşiğini karşılamanın zorunlu olmadığını da belirtir. Ancak yüksek TTFB, aşağıda anlatıldığı gibi LCP'yi doğrudan geciktirir.
TTFB nasıl ölçülür?
Üç kaynağı birlikte kullanın: sunucuya yakın ve uzak noktalardan curl, tarayıcıda DevTools ve gerçek kullanıcı verisi için PageSpeed Insights.
curl -w
curl, bağlantının her aşamasının bittiği anı saniye cinsinden, isteğin başından itibaren birikimli olarak yazdırabilir:
curl -o /dev/null -s -w 'dns: %{time_namelookup}\ntcp: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntoplam: %{time_total}\n' https://alanadiniz.com/Değerler birikimli olduğu için aşamaların kendi süreleri farklarla bulunur: TCP süresi tcp − dns, TLS süresi tls − tcp, sunucu işleme süresi ve bir gidiş-dönüş ise yaklaşık ttfb − tls'dir. Yönlendirmeleri de izleyip süresini görmek için komuta -L ekleyin ve biçime %{time_redirect} alanını katın. Tek ölçüm yanıltıcı olabilir; komutu birkaç kez çalıştırın ve aynı saatte, farklı konumlardan tekrarlayın.
Chrome DevTools
Network sekmesinde sayfayı yeniden yükleyin, ilk satırdaki HTML belgesine tıklayın ve Timing sekmesini açın. DNS Lookup, Initial connection, SSL ve "Waiting" satırları aşamaları ayrı ayrı gösterir. DevTools'taki bekleme satırı yalnızca istek gönderildikten sonraki süredir; web.dev'in tanımladığı toplam TTFB değildir. Ölçüm sırasında "Disable cache" seçeneğini işaretleyin.
PageSpeed Insights ve CrUX
PageSpeed Insights, gerçek Chrome kullanıcılarından toplanan CrUX (Chrome User Experience Report) verisini ve bir laboratuvar testini birlikte gösterir. Gerçek kullanıcı verisi yalnızca yeterli trafiği olan siteler ve sayfalar için bulunur; yoksa yalnızca laboratuvar sonucu görürsünüz. Laboratuvar ölçümü tek bir konumdan yapılır, kullanıcılarınızın çoğu farklı bir ülkedeyse sonuç onların deneyimini yansıtmaz.
TTFB'yi düşürmenin yolları
En büyük kazanç genellikle sunucu işleme süresinden gelir; ağ tarafındaki iyileştirmeler onu tamamlar.
Sayfa önbelleği
Sayfa önbelleği, üretilmiş HTML'i saklar ve sonraki isteklerde PHP ile veritabanını hiç çalıştırmadan sunar. Önbelleksiz dinamik bir sitede TTFB'yi en çok düşüren tek adım budur. Nginx fastcgi_cache, LiteSpeed'in sunucu önbelleği veya CMS önbellek eklentileriyle kurulur; oturum açmış kullanıcılar ve sepet sayfaları önbellek dışında tutulmalıdır.
PHP-FPM ve OPcache
PHP havuzu doluysa istek, işlenmeden önce kuyrukta bekler ve bu bekleme doğrudan TTFB'ye eklenir. OPcache kapalıysa her istekte PHP kodu yeniden derlenir. Süreç sayısının RAM'e göre hesaplanması PHP-FPM optimizasyonu yazısında anlatıldı.
Veritabanı
Önbelleğe alınamayan sayfalarda TTFB'nin büyük kısmı sorgulara gider. Yavaş sorgu günlüğü, eksik indeksler ve buffer pool boyutu için MySQL ve MariaDB optimizasyonu rehberine bakabilirsiniz.
CDN
CDN (içerik dağıtım ağı), içeriği kullanıcıya yakın uç sunuculardan sunar. Bağlantı ve TLS kurulumu yakındaki uç sunucuyla yapıldığı için bu aşamalar kısalır. Ancak HTML önbelleğe alınmıyorsa istek yine kaynak sunucuya gider ve sunucu işleme süresi aynen kalır; CDN yavaş bir uygulamayı hızlandırmaz.
Sunucu lokasyonu
Işık fiber içinde saniyede yaklaşık 200.000 km ilerler; bu, her 1.000 km'lik fiber yolun gidiş-dönüşe en az 10 ms eklemesi demektir. İstanbul ile Frankfurt arasındaki kuş uçuşu mesafe yaklaşık 1.870 km'dir; kaba bir hesapla bu, teorik alt sınır olarak yaklaşık 19 ms'lik bir gidiş-dönüş süresi eder, gerçek fiber güzergâhları daha uzundur. Yeni bir HTTPS bağlantısında TTFB en az üç gidiş-dönüş (TCP, TLS 1.3, istek) içerdiği için bu fark birkaç kat büyür. Bu değerler fizik temelli bir alt sınır hesabıdır, ölçüm sonucu değildir. Kullanıcılarınızın çoğu Türkiye'deyse sunucunun da Türkiye'de olması bu farkı ortadan kaldırır. Bulutzone'un VDS paketleri İstanbul'daki Mars veri merkezinde çalışır; Türkiye'deki kullanıcılar için VDS paketlerine bakabilirsiniz.
HTTP/2 ve HTTP/3
HTTP/2, birden fazla isteği tek bağlantı üzerinden taşır; aynı sunucuya yapılan sonraki istekler yeni bağlantı kurmaz. HTTP/3, QUIC protokolü üzerinde çalışır ve taşıma ile şifreleme el sıkışmasını birleştirerek yeni bağlantıyı daha az gidiş-dönüşle kurar; web.dev, HTTP/3'ün TCP'deki hat başı tıkanması (head-of-line blocking) sorununu da çözdüğünü belirtir. Sunucunuzun HTTP/2 desteğini curl -s -o /dev/null -w '%{http_version}\n' https://alanadiniz.com/ ile kontrol edebilirsiniz.
TTFB ve Core Web Vitals (LCP) ilişkisi
LCP (Largest Contentful Paint), sayfanın en büyük içerik öğesinin ekranda görünme süresidir ve bir Core Web Vitals metriğidir; web.dev iyi değeri 2,5 saniye veya altı olarak tanımlar. web.dev'in LCP rehberi LCP'yi dört alt parçaya ayırır ve ilki TTFB'dir. Aynı rehbere göre iyi optimize edilmiş sayfalarda TTFB, LCP süresinin yaklaşık yüzde 40'ını oluşturur. TTFB 1,5 saniye olan bir sayfa, 2,5 saniyelik LCP bütçesinin yarısından fazlasını daha ilk bayt gelmeden harcamış olur.
Sık sorulan sorular
TTFB kaç olmalı?
web.dev'e göre çoğu site 0,8 saniye veya altını hedeflemelidir; 1,8 saniyenin üzeri kötü kabul edilir. Önbellekten sunulan sayfalarda bu değerin çok altında kalmak mümkündür.
TTFB neden yüksek?
En sık nedenler önbellek eksikliği, yavaş veritabanı sorguları, dolu PHP havuzu, yönlendirme zincirleri ve kullanıcıya uzak sunucudur. curl çıktısında büyük farkın hangi aşamada olduğuna bakmak nedeni daraltır.
CDN TTFB'yi düşürür mü?
Bağlantı ve TLS aşamalarını kısalttığı için düşürür; HTML de CDN'de önbelleğe alınıyorsa etkisi büyüktür. HTML her istekte kaynak sunucudan geliyorsa sunucu işleme süresi değişmez.
TTFB SEO'yu etkiler mi?
TTFB bir Core Web Vitals metriği değildir. Ancak LCP'nin ilk parçası olduğu için yüksek TTFB, Core Web Vitals'taki LCP değerini doğrudan kötüleştirir.
Sorun hostingte mi, kodda mı?
Üç basit karşılaştırma sorunun yerini büyük ölçüde gösterir:
- Statik dosya ile dinamik sayfa: aynı sunucudaki küçük bir statik dosyanın (örneğin
/robots.txt) TTFB'si düşük, dinamik sayfanınki yüksekse sorun uygulama ya da veritabanındadır. - Sunucunun içinden ölçüm: ağı devreden çıkarmak için ölçümü sunucunun kendisinde yapın:
curl -o /dev/null -s -w '%{time_starttransfer}\n' --resolve alanadiniz.com:443:127.0.0.1 https://alanadiniz.com/. İçeriden hızlı, dışarıdan yavaşsa ağ ve lokasyon öne çıkar. - Yavaşlık anında kaynaklar: içeriden de yavaşsa sunucu kaynaklarına bakın; load average çekirdek sayısını aşıyor mu, swap kullanılıyor mu? Adım adım kontrol için darboğaz tespiti akışını izleyin.
Kalıcı iyileştirme adımları Linux sunucu optimizasyonu rehberinde katman katman anlatılıyor. TTFB sorununun sunucu kaynaklı olup olmadığını birlikte incelemek isterseniz tek seferlik sunucu optimizasyonu hizmeti için teklif alabilirsiniz. Yanıt süresinin ve servislerin sürekli izlenmesi için servis izleme içeren sunucu yönetimi paketlerine de bakabilirsiniz.