TTFB (Time to First Byte) Nedir? Düşürme Rehberi

TTFB (Time to First Byte), bir web sayfasının kullanıcıya ilk yanıtını ne kadar hızlı verdiğini ölçer. Tek bir sayı gibi görünse de; DNS, TLS, sunucu bekleme süreleri, uygulama katmanı ve veritabanı gibi birçok bileşenden etkilenir. Bu rehberde TTFB’nin ne olduğunu, hangi araçlarla doğru şekilde ölçülmesi gerektiğini ve “TTFB’yi düşürmek için” uygulanabilir teknik adımları parça parça ele alacaksınız.

TTFB (Time to First Byte) nedir?

TTFB, kullanıcının tarayıcısı sayfayı talep ettikten sonra tarayıcıya ilk veri baytının (first byte) gelmesine kadar geçen süreyi ifade eder. Kullanıcı deneyimi açısından önemlidir; çünkü ilk byte gelmeden sayfa tamamen yüklenemez.

TTFB’yi etkileyen başlıca zincir şöyle ilerler: - DNS çözümleme (domainin IP adresinin bulunması) - TCP kurulumu ve çoğu durumda TLS/HTTPS el sıkışması - Sunucunun isteği kabul edip uygulamayı çalıştırması - Uygulamanın sayfa üretirken beklediği işler (cache kontrolü, veritabanı sorgusu, dosya erişimi) - Yanıtın ilk baytının tarayıcıya gönderilmesi

Bu yüzden TTFB tek başına “internet yavaştır” demek değildir. Aynı site farklı lokasyonlarda farklı TTFB gösterebilir; aynı sunucuda ise saatler içinde yük artınca TTFB yükselir.

TTFB ile ilgili yaygın karışıklık

• TTFB: İlk baytın gelme süresi
• TTI (Time to Interactive): Sayfanın etkileşime hazır hale gelmesi
• PageSpeed/CLS/LCP: Farklı performans metrikleri (TTFB, özellikle sunucu tarafı gecikmelerini daha net yansıtır)

Bu rehber özellikle TTFB’ye odaklanır; çünkü bariz ve sık yaşanan performans problemlerini genellikle TTFB üzerinden yakalamak daha kolaydır.

TTFB’yi doğru ölçmek için araçlar

TTFB’yi “göz kararı” yapmak yerine ölçmek gerekir. Ölçüm, sorunun nerede olduğunu ayırmanızı sağlar.

Chrome DevTools ile hızlı kontrol

1. Sayfayı açın
2. DevTools > Network sekmesine geçin
3. Sayfayı yenileyin (F5)
4. İlk isteklerin zamanlamasında TTFB benzeri metrikleri inceleyin

DevTools’ta değerler istek bazında görülür. Özellikle HTML belgesinin TTFB’si en kritik göstergedir.

WebPageTest ve Lighthouse

• WebPageTest (WebPageTest.org): Lokasyon ve tarayıcı simülasyonlarıyla TTFB’yi daha sistematik görmenizi sağlar.
• Lighthouse (PageSpeed Insights): Sunucu kaynaklı yavaşlıklar hakkında genel sinyaller verir.

Uygulama ve sunucu tarafı logları

TTFB yükselince bazen tek sorumlu “sunucu” değildir. Uygulama katmanında geciken istekler loglardan görülebilir: - Web sunucusu erişim logları (Nginx/Apache) - Uygulama logları (PHP-FPM, Node.js, Java) - Veritabanı sorgu logları

Hedefiniz şu soruya net cevap vermek olmalı: “TTFB yükselmesi uygulama bekleme süresinden mi geliyor, yoksa önbellek devreye girmediği için mi?”

İyi ve kötü TTFB hedefleri

Tek bir evrensel eşik yoktur; ama pratikte şu yaklaşım işe yarar: - İlk bayt genelde 200–400 ms bandında ise çoğu sayfa iyi kullanıcı deneyimi verir. - 400–800 ms bandı için uygulama/sunum katmanında optimizasyon gerekir. - 800 ms ve üzeri sürekli ise; çoğunlukla cache eksikliği, veritabanı gecikmesi, yanlış upstream ayarları veya aşırı yük vardır.

Önemli: Bu değerleri “her lokasyonda” ve “yoğunlukta” inceleyin. Çünkü bir sağlayıcıda gece saatleri iyi, gündüz kötü çıkabilir.

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

Aşağıdaki maddeler TTFB düşürmede en çok etki edenlerdir. Her adımı bir öncekinin üzerine kurun.

1) Önbellekleme stratejisini doğru kur (cache)

TTFB’nin en yaygın nedeni, HTML’nin her istekte dinamik üretilmesidir.

Statik sayfalar için

• HTML, CSS, JS gibi varlıkları CDN üzerinden cache’leyin
• Tarayıcı cache başlıklarını doğru ayarlayın (örn. Cache-Control)

Dinamik içerik için (WordPress dâhil)

• Sunucu tarafı sayfa cache (reverse proxy cache veya uygulama cache)
• Uygulama seviyesinde object cache (Redis/Memcached)
• Veritabanı sorgu tekrarlarını azaltın

Net kontrol noktası: HTML isteğinin TTFB’si düşüyor mu? Varlıklar (CSS/JS) hızlı olsa bile HTML TTFB’si yavaşsa toplam deneyim hâlâ zarar görür.

2) CDN kullanın, özellikle HTML ve ilk istekleri düşünün

CDN sadece dosyaları hızlandırmaz; ilk baytın gelmesini de iyileştirebilir. CDN’in etkisi şu senaryolarda büyüktür: - Sunucu lokasyonu kullanıcıya uzaksa - İlk istek yoğun trafik alıyorsa - TLS ve TCP kurulumu maliyeti yüksekse

Uygulama adımları

• CDN provider tarafında edge cache etkinleştirin
• “Cache edilebilir” sayfaları (genelde kamuya açık sayfalar) belirleyin
• Dinamik kullanıcıya özel içeriklerde cache varyantlarını doğru yönetin (cookie ile cache kırılması gibi)

3) Veritabanı sorgularını TTFB’nin ana düşmanı kabul edin

TTFB artışı çoğu kez “veritabanı yavaş” anlamına gelmez; bazen veritabanına yapılan yanlış sorgu sayısı veya bekleme süreleri TTFB’yi büyütür.

Kontrol listesi

• Sık kullanılan tablolar için doğru indeks (index)
• N+1 sorgu problemine karşı toplu veri çekme
• Uzun sorguların sayısını azaltma
• Connection limit / pool ayarları

Özellikle şu durumlar TTFB’yi belirgin artırır: - Her istek için aynı raporun tekrar hesaplanması - İndeks olmayan sorgular - Çok yoğun saatlerde kilitlenme (lock) / bekleme

4) Uygulama katmanında “idle/queue” beklemelerini azaltın

TTFB’nin bir başka kaynağı, isteklerin worker kuyruğunda beklemesidir.

PHP-FPM (PHP) için net ayarlar

• pm modunu doğru seçin (ör. dynamic)
• max_children ve start_servers değerlerini trafik ve RAM’e göre ayarlayın
• Gerçek yük altında worker sayısı yetmiyorsa TTFB yükselir

Node.js / Java / diğerleri için

• Uygulama container/servislerinde CPU throttling veya yetersiz worker
• Event loop tıkanması (senkron ağır işlemler)

Net hedef: Aynı anda gelen istek sayısında uygulama işlenmeye başlamadan önce bekliyorsa, TTFB yükselir. Bu yüzden sadece “ortalama CPU” değil; worker/queue metriğini de kontrol edin.

5) Web sunucusu katmanında doğru ayarları yapın

TTFB’de web sunucusunun payı küçümsenmemelidir. Aşağıdaki noktalar sık görülür:

Nginx/Apache tarafında

• Uygun keep-alive ayarları (HTTP keep-alive)
• Tedarik zincirinde gecikme yapan proxy zaman aşımı (proxy_connect_timeout, proxy_read_timeout vb.)
• Yanlış upstream balanceleri (gereksiz hop sayısı)

Compression ve minimum iş

• Gereksiz büyük payload üretimi
• Her istekte yapılacak pahalı dönüştürmeler

Not: Brotli/Gzip sıkıştırma bazen CPU yükünü artırıp TTFB’yi kötüleştirebilir. Bu yüzden “sıkıştırmayı açtım hızlandı” varsayımı yerine test yapın.

6) DNS ve TLS tarafını optimize edin

TTFB’nin bir kısmı ağ kurulum maliyetidir. Özellikle ilk isteklerde DNS ve TLS maliyeti daha belirgin görünür.

Ne yapın?

• DNS kayıtlarını doğru TTL ile yönetin
• İstemci ile sunucu arasında gecikmesi yüksek bölgelerde CDN kullanın
• Sertifika yönetimini stabil tutun (sürekli yeniden el sıkışmaya neden olan hatalardan kaçının)

Bu adımlar TTFB’yi tek başına her zaman mucizevi düşürmez; ancak “ilk ziyaretlerde” bariz fark yaratabilir.

7) Sunucu kaynaklarını doğru ölçekleyin (VPS/VDS/Dedicated)

TTFB yükselmesi sadece yazılımdan gelmez. Kaynak yetersizliği uygulamanın daha yavaş yanıt vermesine neden olur.

Pratik ölçekleme sinyalleri

• Worker sayısı doluysa
• CPU sürekli %80+ bandında kalıyorsa
• RAM baskısı nedeniyle swapping başlıyorsa

Bu gibi durumlarda cache ve indeks iyileştirmeleri tek başına yeterli olmaz; kaynak artırma veya mimari değişiklik gerekir.

Sorunu hızlı teşhis etmek için TTFB “neden-sonuç” ayrımı

Aşağıdaki tablo, TTFB’de artış olduğunda nereye bakmanız gerektiğini hızlandırır.

Net kontrol listesi: “TTFB’yi şimdi düşür” planı

Aşağıdaki sırayla ilerlemek en az deneme-yanılma ile sonuç verir.

1. TTFB ölçümü: HTML isteğini baz alın, en az 3 ölçüm yapın.
2. Cache kontrolü: CDN edge cache ve uygulama cache’in gerçekten çalıştığını doğrulayın.
3. Veritabanı: En ağır sorguları bulun, indeks ve sorgu sayısını azaltın.
4. Uygulama işleme: PHP-FPM/worker/queue metriklerini kontrol edin.
5. Web sunucusu/proxy: Upstream hop ve time-out değerlerini gözden geçirin.
6. Ölçekleme: Worker veya RAM/CPU yetersizliği varsa planlı şekilde artırın.

Sonuç

TTFB’yi düşürmek, tek bir ayarı yapmak değil; cache katmanı, uygulama worker’ı, veritabanı sorguları ve CDN gibi bileşenlerin birlikte “ilk byte’ı hızlı üretmesini” sağlamaktır. Önce HTML isteğinin TTFB’sini ölçün, sonra cache-in çalıştığını doğrulayın ve DB + worker beklemelerini giderin. Eğer bu adımlar sonrası TTFB hâlâ 800 ms bandının üstünde kalıyorsa, kaynak artırımı veya mimari revizyonu net metriklerle değerlendirin.

NetKıyas’ta VDS/VPS/Dedicated karşılaştırması yaparken de TTFB’yi etkileyen noktaları (worker kapasitesi, disk türü, sağlayıcının performans yaklaşımı, CDN/edge desteği) paket kriteri olarak ele alın; böylece doğru sunucu türüne daha hızlı karar verirsiniz.