TTFB (First Byte) nedir? TTFB’yi düşürme rehberi

TTFB (Time to First Byte), bir kullanıcının isteği tarayıcıdan gönderdiği andan yanıtın ilk baytının (ilk veri parçası) geldiği ana kadar geçen süreyi ifade eder. Web sitenizin hız algısını doğrudan etkilediği için yalnızca "yüklenme yavaş" şikayetleriyle değil, isteklerin nerede beklediğini ölçerek çözmek gerekir. Bu rehberde TTFB’nin nasıl ölçüldüğünü, tipik kök nedenleri ve her katmanda TTFB’yi düşürmek için net uygulanabilir aksiyonları öğreneceksiniz.

TTFB nedir ve neden tek başına yeterli bir metrik değil?

TTFB, sunucu tarafındaki ilk yanıtın ne kadar sürede üretildiğini anlatır. Tarayıcı yüklenme süresi (LCP gibi) TTFB’den sonra gelen içerik aktarımını ve render’ı da içerir. Bu yüzden TTFB’yi hedeflemek, özellikle şu durumlarda kritik sonuç verir:

• Kullanıcı sayfada dakikalar beklemeden önce “ilk veri” gelmiyor gibi hissediyorsa
• Arama motoru tarama (crawl) bütçesi kısıtlıysa
• Özellikle dinamik sayfalarda (WordPress, API, e-ticaret katalog sayfaları) performans dalgalanıyorsa

TTFB’yi ölçerken “tam olarak ne ölçülüyor?” sorusu önemlidir. Tarayıcı ile ölçüm yapan araçlar genellikle kullanıcı deneyimiyle ilişkili bir zaman damgası üretir. Sunucuda ise yanıtın üretim hattındaki gecikmeler farklı katmanlarda ortaya çıkar.

Hız ölçümünde TTFB’nin karşılığı

Pratikte TTFB gecikmeleri şu süreçlerde birikmiş olabilir: - DNS çözüm süresi (özellikle ilk isabetlerde) - TCP/TLS kurulum süresi (özellikle yeni bağlantılarda) - Web sunucusu (Apache/Nginx/LiteSpeed) isteği alıp uygulamaya iletme süresi - Uygulama (PHP/Node/Java) sayfayı üretirken harcadığı süre - Veritabanı sorguları ve lock (kilit) beklemeleri - Önbellek katmanlarında (cache) istek isabeti

TTFB nasıl ölçülür? Ölçüm yapmadan optimizasyon olmaz

TTFB’yi düşürmenin ilk adımı doğru ölçüm tekniğidir. Aşağıdaki yöntemler aynı sayfada farklı konumlar için kullanılmalıdır.

1) Tarayıcı araçları (Chrome DevTools)

• Network sekmesine girin
• Sayfayı tam yükleyin (ilk açılış ve ikinci açılış farkını görmek için iki kez test edin)
• İlk istekte (fresh) TTFB yüksek, ikinci istekte belirgin düşüyorsa önbellek (cache) veya bağlantı kurulumu etkisi vardır

2) Lighthouse ve PageSpeed Insights

• “TTFB” doğrudan metriğini görmek için raporu inceleyin
• Önbellek etkisi için “tekrarlı test” mantığını koruyun

3) Sunucu odaklı test (curl)

Uygulamaya giden yanıtın ne kadar sürede geldiğini görmek için tek uçlu test kullanılabilir. Örnek: - curl -w "time_starttransfer: %{time_starttransfer}\\n" -o /dev/null -s https://example.com/

Buradaki time_starttransfer, ilk baytın geldiği anla ilişkilidir. Not: Bu değer, tarayıcıdaki DNS/TLS/HTTP3 farklarını birebir temsil etmeyebilir. Bu yüzden aynı koşullarda karşılaştırma yapın.

4) Gerçek kullanıcı koşulları (RUM)

En doğru senaryo; tarayıcıdan gelen gerçek kullanıcı ölçümleridir (RUM: Real User Monitoring). TTFB’yi zaman içinde trend olarak izlemek, “tek seferlik hızlı oldu” yanılsamasını engeller.

TTFB’nin en yaygın kök nedenleri ve hızlı teşhis

TTFB sorunlarını “tek bir ayarla çözülsün” diye görmek doğru değil. Daha çok katman katman ilerlemek gerekir.

Yanlış veya yetersiz önbellek

Dinamik sayfada cache yoksa her istek uygulama ve veritabanı üretimine gider. Bu durumda TTFB sürekli yüksek olur.

Hızlı kontrol: - Aynı URL’yi iki kez test edin: TTFB ikinci denemede düşmüyorsa cache katmanı çalışmıyor olabilir - Uygulama loglarında “cache miss” oranı yüksekse önbelleğe uygun olmayan içerikler üretim hattında bekliyor olabilir

Veritabanı sorgu yavaşlığı (MySQL/PostgreSQL)

TTFB’nin en sık kaynağı uygulama içindeki sorgular ve kilit beklemeleridir.

Hızlı kontrol: - Uygulama panelinde (panel/log) yavaş sorgu raporlarını inceleyin - Sorgu süreleri düzenli olarak 200-800 ms ve üstüne çıkıyorsa TTFB de buna paralel artar

DNS ve bağlantı kurulumu gecikmesi

Özellikle kullanıcı ilk kez geldiğinde veya farklı coğrafi bölgelerde DNS çözümü uzadığında TTFB etkilenir.

Hızlı kontrol: - DNS süreleri için bölgesel test yapın - DNS kayıtlarını kontrol edin (A/AAAA) ve TTL değerlerinin çok yüksek olup olmadığını gözden geçirin

TLS/HTTP protokolü etkisi

Yeni bağlantılar için TLS handshake süresi veya HTTP/1.1 yerine HTTP/2/HTTP/3 kullanımı fark yaratabilir.

Hızlı kontrol: - CDN üzerinden HTTP/2 ve (mümkünse) HTTP/3 aktif mi kontrol edin - Ana domain ve alt domainlerde aynı sertifika ve aynı zincir (chain) kullanımı var mı inceleyin

Sunucu kaynak tıkanması

CPU doygunluğu, RAM yetersizliği veya I/O tıkanması TTFB’yi doğrudan yükseltir.

Hızlı kontrol: - CPU steal time (özellikle sanallaştırmada) yüksek mi? - Disk I/O wait yükseliyor mu? - Uygulama beklemeleri thread/pool tükenmesinden mi oluşuyor?

TTFB’yi düşürme: Katman katman net aksiyon planı

Aşağıdaki aksiyonlar, farklı hosting türlerinde uygulanabilir. Önce en düşük maliyetle en fazla etkiyi sağlayan adımları alın.

1) CDN ve edge cache ile ilk baytı hızlandırın

CDN, kullanıcıya yakın lokasyondan yanıt ürettiği için “ilk bayt” süresini ciddi azaltabilir.

• Statik içerik (CSS/JS/img) için CDN cache zorunludur
• Dinamik sayfalarda “tam sayfa cache” (full page cache) mümkünse en büyük kazanç ortaya çıkar
• Sık güncellenmeyen sayfalarda TTL’yi makul seviyede (ör. 5-15 dk aralığı) sabitleyin

Kontrol listesi: - CDN origin’e (ana sunucu) her istekte gitmiyor musunuz? (cache hit oranını izleyin) - Cache purging (temizleme) mekanizması kurallara uygun mu?

2) DNS ve yönlendirmeleri sadeleştirin

TTFB’yi etkileyen pratik hatalar: - Birden fazla 301 redirect zinciri - www/non-www karışıklığı - Çok yüksek TTL yüzünden düzeltmelerin yavaş yayılması

Net hedef: - Tek yönlendirme veya hiç yönlendirme olmaması - A/AAAA kayıtlarında gereksiz gecikme oluşturmayan yapı

3) Web sunucusu katmanında doğru ayarlar

Apache/Nginx/LiteSpeed için tek doğru ayar yok; ama TTFB’nin etkilendiği ortak alanlar var.

• Keep-Alive ve bağlantı yeniden kullanımının açık olduğundan emin olun
• Gzip/Brotli gibi sıkıştırma, CPU maliyeti yaratır. CPU tıkanması varsa TTFB düşmeyebilir. Önce CPU ile test edin
• Upstream timeouts (uygulama zaman aşımı) çok kısa/çok uzun olmasın; “ilk bayt gelmeden önce” beklemeler oluşur

Pratik yaklaşım: - “Önce kök nedeni” bulun: loglarda en yavaş endpoint/URL’yi belirleyin - Sonra web sunucusu ayarlarını o endpoint’e göre test edin

4) Uygulama performansı: TTFB’yi üreten kodu hızlandırın

Dinamik sayfalarda en etkili hedef, istek başına harcanan süreyi düşürmektir.

• Sayfa üretiminde gereksiz fonksiyon çağrılarını azaltın
• Kullanılmayan eklentileri (plugins) kaldırın
• Template rendering sırasında tekrar eden hesapları cache’leyin
• API çağrılarında paralellik kurun (ör. sunucu tarafında birden fazla bağımlı isteği sırayla beklemeyin)

5) Veritabanı: sorgu ve indeks (index) önceliği

TTFB’yi düşürmenin en net yolu, veritabanı sorgularını hızlandırmaktır.

• EXPLAIN ile sorgu planlarını inceleyin
• WHERE/JOIN kolonlarında indeks ekleyin
• N+1 sorgu desenlerini temizleyin (özellikle ORM kullanımlarında)
• Lock beklemelerini azaltmak için transaction süresini kısaltın

Net hedef: - Yavaş sorgu listesi çıkarın ve ilk 10 sorguyu sırayla optimize edin - Aynı sayfanın TTFB değerini her optimizasyondan sonra ölçün

6) Önbellekleme stratejisi: doğru katmana, doğru süreyle

Cache tek başına “her şeyi çözmez”. Doğru cache türünü doğru senaryoya yerleştirin:

• Sayfa cache (full page cache): Herkes için aynı HTML dönen sayfalarda en hızlı kazanım
• Parça cache (fragment cache): Aynı sayfada değişmeyen bileşenler için
• Veri cache: Sık tekrar eden hesaplar veya sabit veri için

TTL seçimi: - Çok kısa TTL: Cache miss artar, TTFB yükselir - Çok uzun TTL: Güncelleme gecikir, içerik tutarsızlığı oluşur

7) Hosting seçimi: TTFB’yi etkileyen kaynaklar (CPU/RAM/I-O)

TTFB sorunlarının bir kısmı kullandığınız altyapının limitlerinden gelir. Bu noktada hosting türü seçimi belirleyicidir.

Aşağıdaki tablo, tipik senaryolara göre beklenti oluşturur:

Net karar kuralı: - Uygulama/DB optimizasyonu sonrası TTFB düşmüyorsa, kaynak planını (CPU/RAM) büyütmeyi veya daha izole bir modele geçmeyi test edin

8) Ölçümle doğrulama: her değişiklik “kanıt” ister

TTFB optimizasyonlarında en sık hata, değişikliği yaptıktan sonra ölçmeden “hissetmeye” güvenmektir.

Her adım için şu rutini kurun: - Aynı URL setini seçin (en önemli 5-10 sayfa) - Aynı coğrafi test noktasında ölçün - İlk açılış ve sonraki açılış ayrımını yapın - Değişiklik sonrası TTFB’de hedeflenen düşüş gerçekleşiyor mu bakın

Sonuç: TTFB’yi düşürmek için en kısa yol

TTFB’yi düşürmek için önce ölçün, sonra kök nedeni bulun: cache çalışmıyor mu, veritabanı sorguları mı yavaş, bağlantı kurulumu mu uzuyor, yoksa kaynak tıkanması mı var? En hızlı sonuç genellikle CDN + doğru önbellek ve ardından yavaş sorguların indeks/plan ile düzeltilmesi ile gelir. Bu rehberdeki kontrol listesini kullanarak en yüksek TTFB üreten 5 URL’yi seçin, katman katman ilerleyin ve her değişiklikten sonra yeniden ölçün. En sonunda, TTFB düşüşü ölçümle doğrulandığında hosting/altyapı değişikliğini değil, doğru optimizasyon önceliklerini kazandığınızı göreceksiniz.