TTFB Nedir? Sunucu Yanıt Süresini Düşürme Yöntemleri

TTFB nedir ve ne ölçer?

TTFB (Time to First Byte), tarayıcının sunucuya istek gönderdiği andan sunucudan ilk yanıt baytının alındığı ana kadar geçen süredir. Bu süre, kullanıcının sayfayı açmak için tıkladığı andan sayfa içeriğinin tarayıcıya ulaşmaya başladığı ana kadar yaşanan toplam gecikmeyi temsil eder.

Google, iyi bir TTFB için 800 ms'nin altını hedef gösterir. Bu eşiğin üzerindeki değerler, diğer tüm performans optimizasyonlarını olumsuz etkiler. LCP, FCP ve TTI gibi metrikler TTFB'nin üzerine inşa edilir; sunucu yanıtı yavaşsa sayfanın geri kalan optimizasyonları ne kadar iyi olursa olsun sonuç sınırlı kalır.

TTFB'yi PageSpeed Insights, WebPageTest veya Chrome DevTools Network sekmesi üzerinden ölçebilirsiniz. DevTools'da Network sekmesini açıp ilk HTML isteğine tıkladığınızda "Waiting (TTFB)" satırı görünür; bu değer sunucunun ilk baytı göndermesi için ne kadar beklediğinizi gösterir.

TTFB hangi bileşenlerden oluşur?

TTFB tek bir gecikmenin değil, birden fazla aşamanın toplamıdır. Her aşama farklı bir katmanda gerçekleşir ve farklı çözümler gerektirir. Bu bileşenleri ayırt etmeden yapılan müdahale çoğu zaman yanlış katmana gider.

DNS çözümleme, tarayıcının alan adını IP adresine dönüştürmesidir. İlk ziyarette gerçekleşir; DNS cache sayesinde tekrar ziyaretlerde bu süre ortadan kalkar. Yavaş DNS sağlayıcısı 100-300 ms ekleyebilir. TCP bağlantı kurulumu, istemci ile sunucu arasında veri iletim kanalının açılmasıdır. Her yeni bağlantı bir "handshake" gerektirir; HTTP/2 ve HTTP/3 çoklu istek için tek bağlantı kullandığından bu maliyeti azaltır.

TLS anlaşması, HTTPS bağlantıları için ekstra bir adımdır. Şifreleme anahtarlarının değiş tokuşu gerçekleşir; modern TLS 1.3, önceki sürümlere göre daha hızlı anlaşma sağlar. Sunucu işlem süresi (Server Processing Time) ise gerçek iş yükünün yaşandığı aşamadır: veritabanı sorguları, uygulama mantığı, template render ve önbellek okuma bu aşamada gerçekleşir. TTFB yüksekse ve diğer aşamalar normal görünüyorsa sorun buradadır.

• DNS çözümleme: Hızlı DNS sağlayıcısı (Cloudflare 1.1.1.1, Google 8.8.8.8) ve TTL optimizasyonu ile 50-150 ms kazanılabilir.
• TCP + TLS: CDN ve edge lokasyonlar fiziksel mesafeyi kısaltır, bağlantı kurulum süresini azaltır; Keep-Alive bağlantı yeniden kullanımı sağlar.
• Sunucu işlem süresi: Veritabanı sorgu optimizasyonu, uygulama seviyesi önbellekleme ve statik oluşturma (SSG) bu aşamayı doğrudan etkiler.
• Ağ gecikmesi: CDN ile kullanıcıya coğrafi yakınlık sağlamak, uzak bölgelerden erişimde 200-500 ms kazandırabilir.

Sunucu tarafı önbellekleme TTFB'yi nasıl etkiler?

Sunucu önbelleklemesi, TTFB'yi düşürmenin en etkili yöntemlerinden biridir. Her istek için veritabanına gidip aynı veriyi tekrar hesaplamak yerine, önceden hesaplanmış sonuçları hızlı bir önbellekten sunmak sunucu işlem süresini 5-10 kat azaltabilir.

Sayfa önbelleklemesi (page caching) tüm HTML çıktısını saklar. WordPress için WP Rocket, Laravel için Response Cache gibi araçlar bu işlemi kolaylaştırır. Tam sayfa önbellek aktifken sunucu isteği işlemek yerine dosyadan okur; TTFB genellikle 50-100 ms'ye düşer. Dinamik sayfalar için uygun değildir; kişiselleştirilmiş içerikler önbellekten çıkarılmalıdır.

Nesne önbelleklemesi (object caching) veritabanı sorgu sonuçlarını, API yanıtlarını veya hesaplama sonuçlarını saklar. Redis ve Memcached bu amaçla yaygın kullanılır. Veritabanına gitmek 20-200 ms alırken Redis'ten okumak genellikle 1-5 ms sürer. Sık sorgulanan veriler için nesne önbelleği, TTFB'nin sunucu işlem süresini dramatik biçimde kısaltır.

• Tam sayfa önbelleği: Statik veya nadiren değişen sayfalar için en etkili yöntem; TTFB'yi 50 ms seviyesine indirebilir.
• Redis/Memcached: Veritabanı sorgu sonuçlarını bellekte saklar; yüksek trafikli uygulamalarda N+1 sorgu sorununu çözer.
• CDN edge cache: HTML sayfasını CDN edge noktasında önbelleğe almak, sunucuya hiç gitmeden yanıt dönmeyi sağlar.
• stale-while-revalidate: Önbellek süresi dolduğunda eski veriyi sunmaya devam ederken arka planda yenileme yapar; kullanıcı bekleme süresi sıfıra iner.

Yanıt süresini katman bazlı ayırt etmek güvenilir ölçümle başlar

Tek sayı üzerinden acele karar vermeyin; dağılıma bakın. Mobil tarafta düşük işlem gücü ve ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütür — ortalama 800ms olan TTFB bazı kullanıcılarda 2.3 saniyeye çıkabilir.

• Gerçek kullanıcı verisi: Chrome User Experience Report (CrUX) 28 günlük dağılımı gösterir, p75 değerine odaklanın.
• Laboratuvar testi: WebPageTest'te 3G bağlantı profiliyle 5 tekrar yapın, medyan değeri alın.
• Cihaz kırılımı: Mobil ve masaüstü ayrı izleyin, mobil genelde %40-60 daha yavaştır.
• Zaman karşılaştırması: Haftalık trend grafiği tutun, ani sıçramalar deployment ile ilişkilendirin.

Ağ, uygulama ve veri katmanındaki gecikmeyi birbirinden ayırın

Bağlantı ve yanıt süresi analizinde CDN dağıtım etkisi ile render blocking kaynak yükü birlikte izlendiğinde kök neden ayrımı hızlanır.

Server processing 1.2 saniye alıyorsa sorun backend'dedir. Initial connection 800ms ise ağ gecikmesi veya CDN yokluğu sorundur. Content download uzunsa dosya boyutu veya bant genişliği darboğazdır.

• Ağır medya: İlk HTML yanıtı 14KB'ı geçmesin, critical CSS inline olsun, font preload kullanın.
• Bloklayan kaynak: Render-blocking JS'i defer edin, üçüncü taraf scriptleri async yükleyin veya tamamen kaldırın.
• Ana iş parçacığı yükü: Long Task'ları 50ms altına indirin, code splitting yapın, heavy computation'ı Web Worker'a taşıyın.
• Sunucu gecikmesi: Database query sayısını azaltın (N+1 problem), Redis cache ekleyin, CDN kullanın, server-side rendering yerine static generation tercih edin.

Gecikme kaynağına göre etki-maliyet dengesini kurun

Database index eksikliği 2 saatte düzelir ve TTFB'yi 400ms düşürür. Sunucu mimarisi değişikliği 3 ay sürer ve kazanç belirsizdir. Önce yüksek etki + düşük maliyet adımları uygulanır.

• Etki büyüklüğü: Değişiklik TTFB'yi kaç milisaniye düşürür? 100ms altı kazanım düşük önceliklidir.
• Uygulama maliyeti: Kaç geliştirici-gün gerekir? 5 günden fazlası yüksek maliyetlidir, parçalara bölün.
• Risk seviyesi: Production'da kritik akışı etkiler mi? Yüksek riskli değişiklikleri feature flag arkasına alın.
• Geri dönüş süresi: Sorun çıkarsa ne kadar sürede rollback yaparsınız? 5 dakikadan uzunsa deployment stratejisini gözden geçirin.

Yanıt süresi değişikliklerini sınırlı trafikle doğrulayın

• Aşamalı yayın: Canary deployment ile %5 trafiğe verin, 24 saat izleyin, sorun yoksa %100'e çıkarın.
• Önce test sonra canlı: Staging ortamında Lighthouse CI kurun, her PR'da performans regresyonu kontrol edin.
• Regresyon kontrolü: TTFB eşiği 600ms ise CI/CD pipeline'da bu değeri aşan değişikliği reddedin.
• Geri alma planı: Feature flag kullanın, sorun çıkarsa kod deploy etmeden flag'i kapatın.

Değişiklik öncesi ve sonrası aynı ölçüm koşullarını korumak ekip içi değerlendirmede tartışmayı azaltır, karar kalitesini yükseltir.

Lab skoru yüksek ama alan verisi kötüyse TTFB ölçümü yanıltıcı olabilir

Sonuçları doğrularken Lighthouse raporunu bağlamlı yorumlama ve sayfa yüklenme hızı hedefleri aynı karar setinde tutulmalıdır.

Aynı sayfanın farklı cihaz ve ağ profillerinde farklı sonuç üretmesi normaldir; tek sayı üzerinden acele karar vermeyin. Dağılıma bakın — mobil tarafta düşük işlem gücü ve ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütür.

• Tek ölçüm yanılgısı: Lighthouse'da 95 skor aldınız, gerçek kullanıcıda CrUX p75 değeri 1.8 saniye. Lab verisi gerçeği yansıtmaz.
• Aşırı ortalama kullanımı: Ortalama TTFB 400ms güzel görünür, p95 değeri 2.1 saniye ise %5 kullanıcı çok kötü deneyim yaşıyor.
• Coğrafya farkı: ABD'de 200ms, Asya'da 1.2 saniye. CDN edge location'ları eksikse uzak kullanıcılar cezalandırılır.
• Cihaz sınıfı etkisi: Flagship telefonda 300ms, düşük segment cihazda 1.5 saniye. Hedef kitlenizin cihaz dağılımını bilin.

Yanıt süresi düzenli izlenmezse borç sessizce birikir

Yeni deploy sonrası TTFB yavaş yükselir ama kimse fark etmez. Düzenli kontrol olmadan kayma haftalarca görünmez kalır.

• Haftalık denetim: Her Pazartesi sabahı CrUX raporunu kontrol edin, TTFB p75 değeri 600ms'yi geçtiyse alarm verin.
• Yayın öncesi kontrol: CI/CD pipeline'da Lighthouse CI kurun, TTFB eşiği 500ms, aşarsa merge'i engelleyin.
• Otomatik alarm: Datadog veya New Relic'te TTFB p95 değeri 1 saniyeyi geçerse Slack'e bildirim gönderin.
• Dokümantasyon disiplini: Her optimizasyon sonrası önce/sonra metrik değerlerini wiki'ye kaydedin, 3 ay sonra tekrar ölçün.