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

TTFB için başlangıç ölçümünü netleştirin

Gerçek kullanıcı verisinde açıkça görülür: aynı sayfa farklı cihazda farklı sonuç üretir.

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.

Hedef yalnızca raporda daha iyi görünen bir skor üretmek değildir.

TTFB darboğazını katman katman 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.

İyileştirme kalitesini belirleyen adım budur.

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.

TTFB tarafında öncelik sırası kurun

Hız çalışmasını sürdürülebilir yapan yaklaşım: etki-maliyet matrisini kurmaktır.

Yüksek etki + düşük maliyet işleri önce yapın. Database index eksikliği 2 saatte düzelir, TTFB'yi 400ms düşürür. Sunucu mimarisi değişikliği 3 ay sürer, belirsiz kazanç sağlar. Hangisini önce yapacağınız açıktı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.

TTFB değişikliklerini küçük yayınlarla doğrulayın

Pratikte en çok atlanan nokta: büyük değişiklikleri tek seferde yapmaya çalışmaktır.

• 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.

TTFB verisini yanlış okumayın

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

Teknik ekipte netleşmesi gereken alan: metrik yorumlama hatası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.

TTFB için sürdürülebilir kontrol rutini kurun

Gerçek kullanıcı verisinde açıkça görülü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.

• 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.

Vaka Notu: Dalgalı yanıt süresini dengeleme

Bir içerik servisinde TTFB özellikle yoğun saatlerde yükseliyordu. Katmanlı analizde ardışık veritabanı sorguları ve geç devreye giren cache akışı temel neden olarak belirlendi. Ekip sorgu planını sadeleştirdi, sıcak içerikler için önbellek anahtarlarını yeniden kurguladı ve yanıt zincirini kısalttı.

Sadece donanım artırımı yerine akış optimizasyonu tercih edildiğinde daha kalıcı sonuç alındı. TTFB dalgalanması azaldı ve yanıt süresi daha öngörülebilir hale geldi.