TTFB değeri yüksekse sorun hostingte mi uygulamada mı?

TTFB yüksek göründüğünde ilk refleks çoğu zaman sunucuyu değiştirmek olur. Oysa ilk bayta kadar geçen süre; DNS, ağ gecikmesi, sunucu yanıtı, uygulama kodu, veritabanı sorguları, önbellek katmanı ve hatta üçüncü taraf servislerin etkisiyle uzayabilir. Bu yüzden doğru karar, tek bir ölçüme değil kontrollü karşılaştırmaya dayanmalıdır.

TTFB nedir ve neden tek başına karar verdirmez?

TTFB, tarayıcının isteği göndermesinden sunucudan ilk baytı almasına kadar geçen süredir. Yüksek TTFB, sayfanın geç açılacağına dair önemli bir sinyal verir; ancak görsellerin boyutu, JavaScript yükü veya tarayıcı tarafı işlemler hakkında doğrudan bilgi vermez.

Örneğin ana sayfada TTFB 1.2 saniye iken statik bir CSS dosyasında 80 ms görülüyorsa sorun büyük olasılıkla uygulama katmanındadır. Tüm dosyalarda benzer gecikme varsa ağ, sunucu yoğunluğu veya hosting altyapısı daha güçlü adaydır.

Sorunun sunucuda mı uygulamada mı olduğunu nasıl ayırırsınız?

1. Statik dosya ile dinamik sayfayı karşılaştırın

İlk kontrol basittir: Aynı alan adında bir görsel, CSS veya boş bir HTML dosyası test edilir. Statik dosya hızlı, dinamik sayfa yavaşsa PHP, Node.js, Java, WordPress, Android uygulama API katmanı ya da veritabanı sorguları incelenmelidir.

Statik dosya da yavaşsa ağ rotası, TLS el sıkışması, sunucu kaynakları, disk performansı veya yanlış yapılandırılmış güvenlik katmanları değerlendirilmelidir. Bu ayrım gereksiz paket yükseltmelerini ve yanlış optimizasyonları önler.

2. Cache açık ve kapalı test yapın

Önbellek açıkken TTFB düşüyor, kapalıyken belirgin yükseliyorsa problem uygulamanın sayfayı üretme süresindedir. WordPress tarafında ağır eklentiler, çok sayıda sorgu, dış API çağrıları veya optimize edilmemiş tema yapısı buna neden olabilir.

Kurumsal projelerde yalnızca tam sayfa cache yeterli görülmemelidir. Nesne önbelleği, sorgu optimizasyonu ve kritik endpoint’lerin ayrı izlenmesi gerekir. Özellikle mobil uygulamaların kullandığı API’lerde her isteğin cache’e uygun olmadığı unutulmamalıdır.

3. Aynı testi farklı lokasyonlardan çalıştırın

Tek lokasyondan yapılan ölçüm yanıltıcı olabilir. Türkiye’den hızlı, Avrupa’dan yavaş bir yanıt CDN veya bölgesel ağ rotasıyla ilgilidir. Tüm lokasyonlarda yüksek değer görülüyorsa uygulama işlem süresi ya da sunucu kaynağı daha olasıdır.

Sunucu kaynaklı TTFB belirtileri

CPU sürekli yüksekse, RAM sıkışıyorsa, disk I/O bekleme süresi artıyorsa veya aynı sunucudaki tüm sitelerde gecikme varsa altyapı tarafı incelenmelidir. Paylaşımlı ortamlarda komşu hesapların yoğunluğu da yanıt süresini etkileyebilir.

Bu noktada hosting değişimi düşünülmeden önce erişim logları, hata logları, kaynak kullanım grafikleri ve yavaş istek kayıtları birlikte okunmalıdır. Sadece “site yavaş” gözlemiyle alınan karar, maliyeti artırıp asıl sorunu yerinde bırakabilir.

Uygulama kaynaklı TTFB belirtileri

Yavaş veritabanı sorguları, gereksiz eklentiler, ağır tema fonksiyonları, optimize edilmemiş API endpoint’leri ve her istekte çalışan uzak servis kontrolleri TTFB’yi yükseltebilir. Android uygulamalarında da arka uç API’si geç yanıt veriyorsa kullanıcı ekranda yükleme bekler; sorun uygulamada değilmiş gibi görünse de kaynak çoğu zaman sunucu tarafı koddur.

Pratik bir yöntem olarak en yavaş URL’ler listelenmeli, her biri için veritabanı süresi, uygulama çalışma süresi ve dış servis bekleme süresi ayrıştırılmalıdır. Böylece genel tahmin yerine hangi işlem adımının süreyi büyüttüğü görülür.

Hızlı kontrol listesi

• Statik dosya testi: Statik dosya hızlıysa uygulama katmanına odaklanın.
• Cache karşılaştırması: Cache açıkken dramatik iyileşme varsa üretim süresi yüksektir.
• Kaynak grafikleri: CPU, RAM ve disk bekleme değerlerini yoğun saatlerde inceleyin.
• Veritabanı analizi: Yavaş sorguları, eksik indeksleri ve gereksiz tekrarları kontrol edin.
• Lokasyon testi: Bölgesel fark varsa CDN, DNS ve ağ rotasını değerlendirin.
• Dış servisler: Ödeme, bildirim, lisans veya analitik çağrılarının isteği bloke etmediğinden emin olun.

Karar verirken hangi sırayı izlemelisiniz?

Önce ölçüm standardı belirleyin: aynı URL, aynı saat aralığı, aynı cache durumu ve birden fazla lokasyon. Ardından statik-dinamik karşılaştırması yapın. Uygulama yavaşsa kod, sorgu ve eklenti tarafını sadeleştirin; tüm katmanlar yavaşsa sunucu kaynaklarını ve yapılandırmayı inceleyin.

Altyapı gerçekten yetersizse daha güçlü bir paket, ayrılmış kaynaklar veya CDN destekli mimari doğru çözüm olabilir. Ancak uygulama her istekte gereksiz sorgu çalıştırıyorsa daha büyük sunucu yalnızca sorunu bir süre görünmez kılar. Sağlıklı yaklaşım, TTFB’yi tek bir sayı olarak değil, isteğin geçtiği katmanların toplam davranışı olarak okumaktır.