TTFB Yüksekse Sunucu Tarafında İncelenecek 8 Kritik Nokta (2026)

TTFB nedir ve neden sunucu tarafında incelenir?

TTFB (Time to First Byte, ilk bayta kadar geçen süre), tarayıcının isteği göndermeye başlamasıyla sunucudan yanıtın ilk baytının gelmesi arasında geçen süredir. web.dev (Google) belgelerine göre bu süre; bağlantı kurulumu, istek gönderimi ve sunucunun yanıtı üretmeye başladığı ana kadarki tüm aşamaları kapsar. Yani TTFB tek bir şey değil, üst üste binen birkaç katmanın toplamıdır.

TTFB’yi sunucu tarafında incelemek kritiktir çünkü toplam sürenin büyük kısmı genellikle backend işleme tarafında oluşur. Ağ, DNS ve TLS payı sabit ve görece küçükken; yavaş PHP yürütme, ağır veritabanı sorguları ve önbellek eksikliği backend süresini katlayarak büyütür. Bu yüzden ilk adım, ağ kaynaklı gecikmeyi sunucu kaynaklı gecikmeden ayırmaktır.

2026 itibarıyla netleşen önemli bir nokta şudur: TTFB resmi bir Core Web Vitals puanı değildir, ancak LCP’yi (Largest Contentful Paint) doğrudan besleyen bir teşhis metriğidir. İlk bayt geç gelirse tarayıcı içeriği işlemeye geç başlar ve LCP de kötüleşir. Terimin ayrıntılı açıklaması için TTFB teriminin sözlük tanımı bölümüne bakabilirsiniz.

Eşik değerleri konusunda referans olarak Google ~200ms’yi ideal, ~800ms’yi kabul edilebilir sınır, 1800ms üzerini ise kötü kabul eder. Bu rakamları teşhis sırasında bir pusula gibi kullanmak, hangi katmanda çalışacağınızı belirlemenize yardımcı olur.

TTFB’yi doğru ölçmek: Server-Timing, curl ve breakdown

Doğru teşhisin temeli, TTFB’yi bileşenlerine ayırarak ölçmektir. Komut satırından curl ile DNS çözümleme, TLS handshake ve backend yanıt sürelerini ayrı ayrı görebilirsiniz. Aşağıdaki gibi bir komut, her aşamanın saniye cinsinden payını döker:

• time_namelookup: DNS çözümleme süresi
• time_connect: TCP bağlantısı kurulum süresi
• time_appconnect: SSL/TLS handshake süresi
• time_starttransfer: ilk baytın geldiği an (TTFB)

Bu breakdown’da time_starttransfer ile time_appconnect arasındaki fark, saf backend işleme süresini verir. Bu fark büyükse sorun ağda değil, uygulama ve veritabanı katmanındadır. İlgili video kaynak: web.dev kanalının “Optimize Time to First Byte (TTFB)” anlatımı bu ölçüm mantığını görselle pekiştirir.

İkinci güçlü araç Server-Timing header’ıdır. Uygulamanızın yanıtına eklediğiniz bu header, backend içindeki alt süreçleri (veritabanı sorgusu, şablon render, dış API çağrısı) milisaniye cinsinden tarayıcıya iletir. Böylece “backend yavaş” demek yerine “hangi backend adımı yavaş” sorusunu yanıtlarsınız. DebugBear dokümantasyonu, Server-Timing’i sunucu tarafı darboğazları izole etmenin en şeffaf yolu olarak tanımlar.

Ölçümü tek araca bağlamayın. PageSpeed Insights, GTmetrix, WebPageTest ve DebugBear ile karşılaştırmalı bakın; ayrıca önbellek soğuk (ilk istek) ve sıcak (önbellekten gelen istek) senaryolarını ayrı ölçerek tekrarlanabilir sonuç elde edin. Soğuk ve sıcak arasındaki büyük fark, önbellek katmanının ne kadar iş yaptığını gösterir.

Sunucu tarafında adım adım kontrol listesi: yüksek TTFB nedenleri

Ölçümle darboğazı bulduktan sonra sunucu tarafını sistematik tarayın. İlk bakılacak yer hosting türü ve sunucu kaynaklarıdır. Paylaşımlı hostingte CPU, RAM ve özellikle disk I/O komşu sitelerle bölüşülür; yoğun saatlerde kaynak kısıtı doğrudan TTFB’ye yansır. top, htop veya hosting panelinden CPU ve I/O kullanımını trafik tepe saatinde gözlemleyin.

İkinci katman backend ve uygulama kodudur. Yavaş PHP yürütme, döngü içinde tekrarlanan ağır işlemler veya senkron dış API çağrıları ilk baytı geciktirir. Web sunucu yapılandırması da belirleyicidir: Nginx ile PHP-FPM kombinasyonu, Apache’nin mod_php yapılandırmasına göre genellikle daha az bellek ve daha hızlı yanıt verir. PHP-FPM işçi (worker) sayısını trafiğe göre ayarlamak ve OPcache‘i etkinleştirmek, derlenmiş kodu bellekte tutarak her istekte yeniden derlemeyi önler.

Üçüncü katman ağ payıdır: DNS çözümleme ve SSL/TLS handshake. Yavaş bir DNS sağlayıcısı veya gereksiz çoklu yönlendirme, kullanıcı backend’e ulaşmadan saniyeler ekleyebilir. 2026’da HTTP/3 (QUIC) yaygınlaşmasıyla bağlantı kurulum süresi kısalsa da, yanlış yapılandırılmış TLS hâlâ ölçülebilir bir gecikme kaynağıdır.

Barındırma kaynaklı gecikmeyi yapılandırma kaynaklı gecikmeden ayırmak için şu adım adım akışı izleyin:

1. TTFB’yi curl ve Server-Timing ile ölç: DNS, TLS ve backend sürelerini ayrıştırarak gerçek darboğazı belirleyin.
2. Ağ payını ayır (DNS ve TLS): handshake süresinin toplam TTFB içindeki payını ölçüp ağ kaynaklı gecikmeyi izole edin.
3. Sunucu kaynaklarını ve hosting’i incele: CPU/RAM/disk I/O kullanımını ve paylaşımlı hosting darboğazını kontrol edin.
4. Backend ve PHP yapılandırmasını optimize et: PHP-FPM işçi sayısı ve OPcache ayarlarıyla kod yürütme süresini kısaltın.
5. Önbellek katmanlarını etkinleştir: sayfa, nesne (Redis/Memcached) ve opcode cache’i devreye alın.
6. Veritabanı sorgularını indeksle: yavaş sorgu logunu inceleyip eksik indeksleri ekleyin.
7. CDN ve edge caching kur: önbeklenebilir içeriği kullanıcıya yakın sunup son ölçümle doğrulayın.

Önbellek ve veritabanı katmanı: TTFB’yi düşüren kritik ayarlar

Backend süresini en hızlı düşüren iki kaldıraç önbellekleme ve veritabanı optimizasyonudur. Önbellekleme katmanlarını üst üste düşünün: sayfa önbelleği tüm HTML çıktısını hazır tutar; nesne önbelleği (Redis veya Memcached) sık tekrarlanan veritabanı sonuçlarını bellekte saklar; opcode önbelleği (OPcache) derlenmiş PHP’yi tutar; CDN ise statik ve önbeklenebilir içeriği uç noktalarda dağıtır. Her katman, backend’in aynı işi tekrar hesaplamasını engeller.

Veritabanı tarafında en yaygın sorun indekssiz ve yavaş sorgulardır. Yavaş sorgu logunu (slow query log) açıp belirli eşiğin üzerindeki sorguları yakalayın, ardından EXPLAIN ile sorgu planını inceleyip eksik indeksleri ekleyin. Tek bir eksik indeks, listeleme veya arama sayfasında yüz milisaniyelerce gecikmeye yol açabilir; doğru indeks bu süreyi çoğu zaman onlarca ms’ye indirir.

CDN ve edge caching, coğrafi gecikmeyi azaltmanın en doğrudan yoludur. Fastly’nin teknik kaynaklarına göre, içeriği kullanıcıya en yakın uç sunucudan sunmak, önbeklenebilir içerikte TTFB’yi belirgin biçimde düşürür; çünkü istek artık ülkenin öbür ucundaki origin sunucuya gitmek zorunda kalmaz. 2026’da edge/serverless yaklaşımların yaygınlaşması bu kazancı daha da erişilebilir kıldı.

WordPress kullanıyorsanız iki nokta öne çıkar: ağır eklenti yükü her sayfada onlarca ek sorgu çalıştırabilir ve object cache eksikliği aynı sorguların tekrar tekrar veritabanına gitmesine neden olur. Redis tabanlı bir object cache ve uygun bir sayfa önbelleği eklentisi, dinamik WordPress sitelerinde TTFB’yi çoğu zaman tek başına yarıdan fazla düşürür.

Saha vakası: TTFB’yi 1200ms’den 250ms’ye düşürdüğümüz süreç

Türkiye’de bir e-ticaret odaklı WordPress sitesinde, kategori sayfalarında Server-Timing ölçümüyle başlangıç TTFB’sini ortalama 1200ms olarak gördük. curl breakdown’u ağ payının ihmal edilebilir, backend payının ise baskın olduğunu gösterince odağı tamamen sunucu tarafına çevirdik. İşte her değişikliğin önce/sonra Server-Timing verisiyle kazandırdığı yaklaşık süre:

• Redis object cache devreye alındı: tekrarlanan veritabanı sorguları bellekten karşılandı, backend ~1200ms’den ~720ms’ye indi.
• Yavaş sorgu indeksleme: slow query log’da yakalanan iki listeleme sorgusuna indeks eklendi, süre ~720ms’den ~520ms’ye düştü.
• PHP-FPM ve OPcache tuning: işçi sayısı trafiğe göre ayarlandı, OPcache açıldı, süre ~520ms’den ~380ms’ye geriledi.
• Sayfa önbelleği + CDN: önbeklenebilir sayfalar uç noktadan sunuldu, sıcak senaryoda TTFB ~250ms seviyesine oturdu.

Bu sıralama tesadüf değildi. Dinamik ve statik içerik farkına göre ilerledik: önce dinamik backend’i hafiflettik (object cache, indeks, PHP tuning), en sona statik/önbeklenebilir katmanı (sayfa cache + CDN) bıraktık. Tersini yapsaydık, CDN soğuk istekte yine yavaş origin’i vurur ve gerçek kazanç maskelenirdi.

Tekrar eden hatalardan en öğreticisi şuydu: ekip başta yalnızca CDN ekleyip sorunun çözüleceğini varsaymıştı. Oysa CDN, origin’in ürettiği yavaş ilk yanıtı hızlandırmaz; yalnızca önbeklenmiş yanıtları dağıtır. Backend’i düzeltmeden eklenen CDN, oturum açmış kullanıcı sayfalarında hiçbir kazanç sağlamadı. Saha öğrenimi net: önce backend, sonra dağıtım.

TTFB, site hızı ve SEO: SEOYEN ile teknik takip

TTFB doğrudan bir sıralama “puanı” olmasa da, LCP üzerinden Core Web Vitals’ı ve kullanıcı deneyimini etkiler; yavaş açılan sayfalar hem dönüşümü hem de tarama bütçesini olumsuz etkiler. Bu yüzden TTFB’yi tek seferlik değil, sürekli izlenmesi gereken bir teknik sağlık metriği olarak ele almak gerekir.

SEOYEN’in site sağlığı analizi aracı, sunucu tarafı performans uyarılarını ve site hızı sinyallerini tek bir Türkçe arayüzde toplayarak bu takibi kolaylaştırır. Tüm SEO araçlarının tek platformda olması, TTFB benzeri teknik bulguları aynı yerde teknik SEO, içerik ve sıralama verisiyle birlikte değerlendirmenizi sağlar; yerel Türkçe destek de teşhis sürecinde yanınızda olur.

Ahrefs ve SEMrush gibi yabancı araçlar güçlü performans ve denetim modülleri sunar; SEOYEN ise bu yetenekleri Türkiye pazarına uyarlanmış, TL bazlı fiyatlandırma ve Türkçe arayüzle, tüm araçları tek platformda birleştirerek sağlar. Detaylı bir kıyas için Ahrefs ile karşılaştırma sayfasına ve seçenekler için SEOYEN paket ve fiyatları sayfasına göz atabilirsiniz.

Özetle: TTFB’yi katman katman ölçün, sunucu tarafında backend’den dağıtıma doğru ilerleyin ve kazanımları kalıcı kılmak için site hızını düzenli izleyin. Teşhis disiplinli olduğunda, 1200ms’lik bir TTFB’yi 250ms seviyesine taşımak ulaşılabilir bir hedeftir.

Sıkça Sorulan Sorular