TTFB Nedir ve Nasıl Düşürülür?

TTFB Nasıl Ölçülür?

En pratik yöntem komut satırından curl kullanmaktır. Aşağıdaki komut, bir isteğin her aşamasını saniye cinsinden ayrıştırarak gösterir ve darboğazın tam olarak nerede olduğunu görmenizi sağlar:

curl -o /dev/null -s -w "DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n" https://ornek-site.com

Buradaki time_starttransfer değeri pratikte TTFB'ye karşılık gelir. Tarayıcı tarafında ise Chrome DevTools'un Network sekmesinde bir isteğin Timing detayında "Waiting for server response" satırı aynı bilgiyi verir. Sahadaki gerçek kullanıcı verisi için PageSpeed Insights ve Web Vitals raporları daha güvenilir bir tablo sunar.

Sunucu Tarafı Önbellekleme

Dinamik sayfalarda en büyük kazanç çoğunlukla önbellekten gelir. PHP tabanlı bir sistemde her istekte aynı sorguların tekrar tekrar çalışması, TTFB'yi gereksiz yere şişirir. Burada katmanlı bir yaklaşım işe yarar:

• OPcache: Derlenmiş PHP bytecode'unu bellekte tutarak yorumlama maliyetini ortadan kaldırır.
• Nesne önbelleği: Redis veya Memcached ile sık erişilen veritabanı sonuçlarını saklar.
• Tam sayfa önbelleği: LiteSpeed Cache veya Varnish ile hazır HTML çıktısını doğrudan sunar.

LiteSpeed kullanan bir ortamda tam sayfa önbelleğini .htaccess üzerinden etkinleştirmek mümkündür:

<IfModule LiteSpeed>
  CacheLookup on
  RewriteEngine On
  RewriteRule .* - [E=Cache-Control:max-age=300]
</IfModule>

Veritabanı ve Uygulama Katmanı

Önbellek devre dışı kaldığında ya da içerik kişiselleştirildiğinde sunucu gerçekten çalışmak zorunda kalır. Bu noktada yavaş veritabanı sorguları en sık karşılaşılan suçludur. MySQL veya MariaDB tarafında yavaş sorgu günlüğünü açıp, çalışma süresi uzun ifadeleri tespit etmek ilk adımdır:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Tespit edilen sorgular için doğru sütunlara index eklemek, çoğu durumda yanıt süresini kat kat aşağı çeker. Bunun yanında PHP sürümünü güncel tutmak da somut fark yaratır; modern bir PHP 8.x sürümü, eski 7.x dallarına göre belirgin biçimde hızlıdır. Hız öncelikli projeler için altyapısı buna göre yapılandırılmış bir SEO odaklı hosting planlarıyla TTFB'yi tabandan iyileştirebilirsiniz.

Ağ, CDN ve Coğrafi Mesafe

Sunucu hızlı olsa bile ziyaretçi kıtanın diğer ucundaysa, paketlerin gidiş dönüşü tek başına yüzlerce milisaniye ekleyebilir. Bu fiziksel gecikmeyi azaltmanın en etkili yolu içeriği kullanıcıya yaklaştırmaktır.

• CDN kullanımı: Statik ve mümkünse dinamik içeriği edge sunuculardan sunar.
• HTTP/2 ve HTTP/3: Bağlantı kurulum maliyetini düşürür, çoklamayı iyileştirir.
• TLS oturum yeniden kullanımı: Tekrar eden el sıkışmalarını azaltır.
• Keep-Alive: Aynı bağlantı üzerinden birden çok isteğin işlenmesini sağlar.

Cloudflare gibi bir katman kullanıyorsanız, origin sunucunuzun yanıt sürelerini ayrıca izlemeniz gerekir; edge cache isabet etmediğinde gerçek TTFB'yi yine origin belirler. DNS tarafında da kazanç vardır: yetkili DNS sağlayıcınızın anycast ağ kullanması, çözümleme süresini özellikle uzak bölgelerdeki ziyaretçiler için kısaltır.

TLS ve Bağlantı Optimizasyonu

HTTPS bugün standart olduğundan, TLS müzakeresi her yeni bağlantıda küçük ama gerçek bir gecikme ekler. Bu maliyeti tamamen ortadan kaldıramazsınız, fakat birkaç ayarla belirgin biçimde azaltabilirsiniz. Modern bir TLS yapılandırması, gereksiz tur sayısını düşürmeye odaklanmalıdır.

• TLS 1.3: El sıkışmayı tek tura indirir ve eski sürümlere göre daha hızlıdır.
• OCSP Stapling: Sertifika doğrulamasını sunucu tarafına taşıyarak ek istek gecikmesini önler.
• Oturum bileti yeniden kullanımı: Tekrar bağlanan istemcilerde tam el sıkışmayı atlar.

Nginx tarafında bu ayarların büyük kısmı sunucu bloğunda birkaç satırla devreye girer:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;
ssl_stapling on;
ssl_stapling_verify on;

Bogahost Önerisi: TTFB'yi düşürmeye başlamadan önce mutlaka bir temel ölçüm alın. "Önce ölç, sonra değiştir, tekrar ölç" döngüsü olmadan yapılan optimizasyonlar çoğu zaman yanlış katmana harcanır. Cache açıkken ve kapalıyken ayrı ayrı test edin.

Sunucu Kaynağı ve Barındırma Türü

Aşırı yoğun bir paylaşımlı sunucuda komşu hesapların yükü, sizin yanıt sürenizi dolaylı yoldan bozar. CPU ve I/O için belirli kaynakların ayrıldığı yapılar bu dalgalanmayı azaltır. Trafiği büyüyen veya yanıt tutarlılığı kritik olan projelerde, performans için optimize edilmiş bir web hosting altyapısına geçmek istikrarlı bir TTFB için sağlam bir zemin oluşturur. Disk türü de burada önemlidir; NVMe SSD üzerinde çalışan bir veritabanı, klasik depolamaya göre belirgin biçimde hızlı yanıt verir.

Barındırma türünü seçerken yalnızca fiyata değil, garanti edilen kaynaklara ve sunucu yoğunluğuna da bakın. PHP işçi sayısı (örneğin PHP-FPM için pm.max_children) ve eşzamanlı bağlantı limitleri, trafik arttığında isteklerin kuyrukta beklemesine ya da hızla işlenmesine karar verir. Kuyruk birikmesi, kullanıcı tarafında doğrudan yükselen bir TTFB olarak görünür.

Sık Yapılan Hatalar

TTFB üzerinde çalışırken bazı yaygın yanlışlar emeği boşa çıkarır. Bunların farkında olmak, optimizasyonu doğru yere yönlendirir:

• Yanlış katmanı suçlamak: Frontend'i optimize ederken sorunun backend'de olması.
• Cache'i ölçmemek: Test sırasında cache isabetinin TTFB'yi gerçekte olduğundan iyi göstermesi.
• Eklenti yığını: CMS üzerinde her isteği yavaşlatan gereksiz eklentilerin birikmesi.
• Harici çağrılar: Sayfa render edilirken bloklayan dış API isteklerinin yapılması.

Özetle Yol Haritası

TTFB'yi tek bir sihirli ayarla düşürmek mümkün değil; kazanç, DNS'ten veritabanına kadar her katmandaki küçük iyileştirmelerin toplamından gelir. Ölçümle başlayın, en büyük gecikmenin hangi aşamada olduğunu bulun ve oraya odaklanın. Önbellekleme katmanlarını doğru kurduğunuzda, sorguları indeksleyip güncel bir PHP sürümü kullandığınızda ve içeriği coğrafi olarak kullanıcıya yaklaştırdığınızda, sunucunuz isteklere fark edilir biçimde daha çabuk cevap verir.