TTFB (Time to First Byte) Nedir? Nasıl Düşürülür?

Bir sayfanın hızı hakkında konuşulurken genellikle görseller, betikler ve yazı tipleri akla gelir. Oysa bunların hiçbiri, sunucu ilk cevabı göndermeden devreye giremez. Time to First Byte (TTFB), tarayıcının bir sayfa isteğine karşılık sunucudan ilk baytı ne kadar sürede aldığını ölçer. Kullanıcı ekranda henüz hiçbir şey görmez; ama bu sürede kaybedilen her milisaniye, sonraki bütün metriklere olduğu gibi eklenir.

Bu yüzden TTFB, hız çalışmasının temelidir. FCP ve LCP ne kadar iyi optimize edilirse edilsin, TTFB’nin altına inemez.

TTFB neyi ölçer?

Yaygın kanının aksine TTFB yalnızca “sunucunun düşünme süresi” değildir. Kullanıcının gezinmeyi başlattığı andan yanıtın ilk baytının gelmesine kadar geçen tüm süreyi kapsar. Bu süre şu aşamalardan oluşur:

1. Yönlendirme süresi: Kullanıcının tıkladığı adres başka bir adrese yönleniyorsa, her yönlendirme için geçen süre.
2. Service worker başlatma süresi: Site bir service worker kullanıyorsa, onun uyanıp isteği karşılamaya hazırlanması.
3. DNS çözümlemesi: Alan adının IP adresine çevrilmesi.
4. Bağlantı kurulumu: TCP bağlantısının açılması ve güvenli bağlantı (TLS) el sıkışması.
5. İstek ve sunucu işleme süresi: İsteğin sunucuya ulaşması, sunucunun sayfayı hazırlaması ve ilk baytın geri gönderilmesi.

Referans aldığımız Türkçe kaynakların çoğu yalnızca DNS, bağlantı ve sunucu işleme süresini sayar; yönlendirme ve service worker kalemlerini atlar. Oysa uygulamada, özellikle reklam trafiğinde, en büyük kayıp çoğu zaman yönlendirme zincirlerinden gelir.

Bağlantı kurulumunun gizli maliyeti

Dördüncü madde, sunucunun hızından bağımsız olarak fizik kurallarına tabidir. Her el sıkışma, veri paketinin kullanıcı ile sunucu arasında gidip gelmesini gerektirir. Bu gidiş-dönüş süresine RTT denir. TCP bağlantısı bir gidiş-dönüş, TLS 1.3 bir gidiş-dönüş daha gerektirir; ardından istek gönderilip yanıt beklenir. Kullanıcı ile sunucu arasındaki gidiş-dönüş 150 milisaniye ise (orta kaliteli bir mobil bağlantıda olağan bir değer), sunucu anında cevap verse bile TTFB yarım saniyeyi rahatlıkla bulur. Sunucuyu kullanıcıya yaklaştırmanın (CDN) neden bu kadar etkili olduğu bu hesaptan anlaşılır.

TTFB eşik değerleri

Google’ın web.dev dokümantasyonunda önerilen değerler şunlardır:

1. İyi: 0,8 saniye ve altı
2. İyileştirilmeli: 0,8 ile 1,8 saniye arası
3. Zayıf: 1,8 saniyenin üzeri

Değerlendirme, diğer metriklerde olduğu gibi gerçek kullanıcı ziyaretlerinin 75. yüzdelik dilimine göre yapılır. İnternette dolaşan “200 milisaniyenin altı mükemmel” gibi bantlar resmî değildir; ancak şu açıdan bir anlam taşır: TTFB 0,8 saniye olan bir sayfanın LCP’yi 2,5 saniyenin altında tutması zordur, çünkü geriye yalnızca 1,7 saniye kalır. Bu yüzden pratikte hedeflenmesi gereken değer, özellikle mobilde, 0,8 saniyenin belirgin biçimde altıdır.

TTFB bir Core Web Vitals metriği mi?

Hayır. TTFB, Core Web Vitals setinde yer almaz ve doğrudan bir sayfa deneyimi sinyali değildir. Buna rağmen önemi büyüktür, çünkü iki kritik metriğin tabanını oluşturur:

FCP = TTFB + ilk bayttan ilk çizime kadar geçen süre

LCP = TTFB + kaynak yükleme gecikmesi + kaynak yükleme süresi + çizim gecikmesi

Yani TTFB’deki her iyileşme, hiçbir ön yüz değişikliği yapmadan FCP ve LCP’ye doğrudan yansır.

TTFB ve tarama bütçesi

TTFB’nin SEO’ya daha az konuşulan bir etkisi daha vardır: Googlebot, sunucunun yanıt süresine göre tarama hızını ayarlar. Yavaş yanıt veren bir sunucuda Google, siteyi yormamak için daha az sayfa tarar. Binlerce sayfalık sitelerde bu, yeni içeriklerin ve güncellemelerin dizine daha geç yansıması anlamına gelir. Search Console’daki tarama istatistikleri raporunda yer alan “ortalama yanıt süresi”, Googlebot’un gördüğü sunucu performansını doğrudan gösterir.

TTFB neden yavaş olur?

1. Önbelleksiz dinamik sayfalar

Her istekte veritabanına gidip sayfayı sıfırdan oluşturan sistemler, trafik arttıkça yavaşlar. WordPress, e-ticaret altyapıları ve özel yazılımlarda en yaygın sebep budur.

2. Yavaş veritabanı sorguları

İndekslenmemiş tablolar, her sayfada tekrarlanan ağır sorgular ve şişmiş seçenek tabloları sunucu işleme süresini uzatır. Özellikle eklenti sayısı fazla olan sitelerde sorgu sayısı sayfa başına yüzleri bulabilir.

3. Yetersiz sunucu kaynakları

Paylaşımlı barındırmada kaynaklar yüzlerce siteyle paylaşılır. Yoğun saatlerde diğer sitelerin yükü sizin yanıt sürenize yansır.

4. Coğrafi mesafe

Sunucu yurt dışındaysa ve kullanıcılar Türkiye’deyse her gidiş-dönüş onlarca milisaniye ekler. Yukarıda anlattığımız gibi, bağlantı kurulumu birden fazla gidiş-dönüş gerektirdiği için mesafenin etkisi katlanır.

5. Yönlendirme zincirleri

Reklam bağlantılarındaki takip yönlendirmeleri, HTTP’den HTTPS’e ve www’siz adresten www’li adrese giden kurallar, eski adreslerden yenilerine yapılan yönlendirmeler üst üste bindiğinde kullanıcı daha hiçbir şey görmeden yüzlerce milisaniye harcanır. Zincir temizliğini URL yönlendirmeleri rehberimizde anlattık.

6. Üçüncü taraf çağrıları

Sunucunun sayfayı hazırlarken dış servislerden (döviz kuru, stok, kişiselleştirme, reklam) veri beklemesi, o servislerin yavaşlığını doğrudan sizin TTFB’nize ekler.

7. Soğuk başlatma

Sunucusuz (serverless) mimarilerde uzun süre istek almayan fonksiyonlar uykuya geçer; ilk istek geldiğinde uyanmaları zaman alır. Düşük trafikli sayfalarda bu durum TTFB’de düzensiz sıçramalar olarak görünür.

TTFB nasıl düşürülür?

Önbellek katmanlarını kurun

Sayfa önbelleği, hazırlanmış HTML’i saklayarak her istekte yeniden oluşturmayı ortadan kaldırır ve genellikle en büyük kazancı sağlar. Nesne önbelleği (Redis, Memcached gibi), veritabanı sorgu sonuçlarını bellekte tutar; özellikle oturum açmış kullanıcıların önbelleğe alınamayan sayfalarında etkilidir. Tarayıcı önbelleği ise tekrar ziyaretlerde statik dosyaların yeniden indirilmesini önler.

HTML’i CDN kenarında önbelleğe alın

Birçok site CDN’i yalnızca görseller ve betikler için kullanır; HTML her seferinde ana sunucudan gelir. Oysa TTFB’yi belirleyen HTML’dir. HTML’in de kenar sunucularında önbelleğe alınması, kullanıcıya en yakın noktadan anında yanıt verilmesini sağlar. İçerik güncellendiğinde önbelleğin temizlenmesi ve stale-while-revalidate gibi yönergelerle kullanıcının eski içerik görmeden hızlı yanıt alması mümkündür.

Yönlendirmeleri azaltın

İç bağlantıların, site haritasının ve reklam hedef adreslerinin doğrudan son adresi göstermesi gerekir. HTTP’den HTTPS’e yapılan ilk yönlendirmeyi ortadan kaldırmak için HSTS başlığı kullanılabilir; tarayıcı bir kez öğrendikten sonra siteye doğrudan güvenli bağlantıyla gider.

Bağlantı protokollerini güncelleyin

TLS 1.3, el sıkışmayı TLS 1.2’ye göre bir gidiş-dönüş kısaltır. HTTP/3, taşıma ve güvenlik katmanını birleştirerek bağlantı kurulumunu daha da kısaltır ve kayıplı mobil ağlarda daha dayanıklıdır. Bu ayarlar çoğu CDN ve modern barındırma panelinde birkaç tıklamayla açılabilir.

Sunucu tarafını iyileştirin

1. Güncel bir çalışma ortamı sürümü kullanın (örneğin güncel PHP sürümleri belirgin biçimde daha hızlıdır).
2. Yavaş sorguları tespit edip indeks ekleyin, gereksiz sorguları kaldırın.
3. Kullanılmayan eklentileri ve modülleri tamamen silin.
4. Dış servis çağrılarını sayfa oluşturma sürecinden çıkarın veya sonuçlarını önbelleğe alın.
5. Gerekirse paylaşımlı barındırmadan ayrılmış kaynaklı bir sunucuya geçin. Taşıma sürecini sunucu değişikliği kontrol listemizle yürütün.

İlk baytı erken gönderin

Sayfanın tamamı hazır olmadan başını göndermek (akış hâlinde HTML), tarayıcının CSS ve kritik kaynakları daha erken keşfetmesini sağlar. Bu yöntem TTFB’yi değil ama TTFB’den sonraki bekleme süresini kısaltır. 103 Early Hints ise bir adım daha ileri gider: sunucu sayfayı hazırlarken tarayıcıya “şu dosyalara ihtiyacın olacak” bilgisini önceden gönderir ve tarayıcı bekleme süresini boşa harcamadan indirmeye başlar.

Tarayıcı özelliklerinden yararlanın

Geri-ileri önbelleği (bfcache) sayesinde kullanıcı geri döndüğünde sayfa hiç sunucuya gitmeden anında gösterilir; bunun için sayfanın Cache-Control: no-store başlığı taşımaması ve unload olayı kullanmaması gerekir. Tahminli önceden yükleme ise kullanıcının büyük olasılıkla tıklayacağı sayfayı önceden hazırlayarak algılanan TTFB’yi sıfıra yaklaştırabilir.

TTFB nasıl ölçülür?

Chrome geliştirici araçları

Ağ panelinde ana belge isteğine tıklayıp “Timing” sekmesine geçtiğinizde TTFB’nin alt kalemleri ayrı ayrı görünür: kuyrukta bekleme, DNS, ilk bağlantı, SSL ve “sunucu yanıtı bekleniyor”. Son kalem yüksekse sorun sunucudadır; bağlantı kalemleri yüksekse sorun mesafe veya protokoldedir.

Server-Timing başlığı

Sunucu tarafında hangi işlemin ne kadar sürdüğünü görmek için Server-Timing yanıt başlığı kullanılabilir. Örneğin veritabanı süresi, önbellek isabeti ve şablon oluşturma süresi bu başlıkla gönderildiğinde geliştirici araçlarında TTFB’nin içi görünür hâle gelir. Önbellekten mi yoksa sıfırdan mı yanıt verildiğini anlamak için de son derece kullanışlıdır.

PageSpeed Insights ve CrUX

PageSpeed Insights’ın gerçek kullanıcı verisi bölümünde TTFB de yer alır. Bu değer, farklı konum ve bağlantılardan gelen kullanıcıların deneyimini yansıttığı için tek bir testten çok daha güvenilirdir.

Komut satırı ve test araçları

Teknik ekipler, komut satırı araçlarıyla farklı sunuculardan istek gönderip ilk bayta kadar geçen süreyi ölçebilir. WebPageTest gibi araçlar ise farklı şehir ve bağlantı profillerinden test yaparak coğrafi farkları görünür kılar.

Ölçüm tuzakları

1. Önbellek isabeti ile ıskasını karıştırmak. Aynı adresi art arda test ettiğinizde ikinci test önbellekten gelir ve gerçekçi olmayan iyi bir sonuç verir. İlk ziyaretçinin deneyimini görmek için önbelleği atlayan test de yapın.
2. Oturum açmış kullanıcıları unutmak. Yönetici olarak siteye girdiğinizde çoğu önbellek devre dışı kalır; gördüğünüz TTFB ziyaretçilerinkinden farklıdır.
3. Yalnızca kendi şehrinizden ölçmek. Kullanıcılarınız farklı bölgelerdeyse onların TTFB’si farklıdır.
4. Sayfa türlerini ayırmamak. Ana sayfa önbellekten hızlı gelirken arama sonuçları, sepet ve filtreli kategori sayfaları önbelleğe alınamadığı için çok daha yavaş olabilir.
5. Tek ölçüme güvenmek. TTFB, sunucu yüküne göre gün içinde dalgalanır.

Varsayımsal bir TTFB dökümü

TTFB’yi parçalarına ayırmanın neden bu kadar önemli olduğunu bir örnekle görelim. Rakamlar örnek amaçlıdır; gerçek bir müşteri sonucu değildir.

Bir e-ticaret sitesinin reklamdan gelen mobil ziyaretçileri için TTFB 2,1 saniye ölçülüyor. Geliştirici araçlarındaki döküm şöyle: yönlendirmeler 0,6 saniye, DNS 0,1 saniye, bağlantı ve TLS 0,4 saniye, sunucu yanıtı 1 saniye.

İlk akla gelen çözüm “daha güçlü sunucu almak”tır. Oysa tablonun yarısı sunucuyla ilgili değildir. Yönlendirmeler incelendiğinde reklam bağlantısının önce HTTP adrese, oradan HTTPS’e, oradan da www’li adrese gittiği görülür: üç ayrı istek, üç ayrı bekleme. Reklam hedef adresi doğrudan son adrese çevrilir ve HSTS eklenir; yönlendirme süresi sıfırlanır. Ardından HTML’in CDN kenarında önbelleğe alınması sağlanır; bağlantı süresi kullanıcıya yakın sunucu sayesinde 0,15 saniyeye, önbellekten gelen yanıt süresi ise 0,1 saniyeye iner.

Yeni toplam: 0 + 0,1 + 0,15 + 0,1 = 0,35 saniye. Sunucuya tek kuruş ek yatırım yapılmadan TTFB altıda birine düşer ve bu kazanç FCP ile LCP’ye olduğu gibi yansır.

Platforma göre TTFB sorunları

WordPress

WordPress sitelerinde TTFB’nin en büyük düşmanı, her istekte sayfayı PHP ve veritabanıyla sıfırdan oluşturmaktır. Sayfa önbelleği eklentisi veya sunucu düzeyinde önbellek, çoğu sitede TTFB’yi saniyelerden yüz milisaniyeler düzeyine indirir. Ağır eklentiler, özellikle her sayfada çalışan istatistik, güvenlik ve sayfa oluşturucu eklentileri, önbelleğe alınamayan sayfalarda yükü artırır. Adımların tamamı WordPress hızlandırma rehberimizde.

E-ticaret altyapıları

E-ticarette sayfaların önemli bir kısmı kişiseldir: sepet, hesap, ödeme ve bazı fiyat blokları kullanıcıya göre değişir. Bu sayfalar tam önbelleğe alınamaz. Çözüm, sayfanın kişisel olmayan kısmını önbellekten verip kişisel bölümleri (sepet sayacı, kullanıcı adı) sonradan küçük isteklerle doldurmaktır. Böylece ürün ve kategori sayfaları önbellekten hızlı gelir, kişiselleştirme de korunur. E-ticaret teknik altyapısının SEO tarafını e-ticaret SEO rehberimizde ele aldık.

Başsız (headless) ve tek sayfa mimariler

İçeriğin API’den çekilip sunucuda oluşturulduğu yapılarda TTFB, API’nin yanıt süresine bağlıdır. Sayfa her istekte API’yi bekliyorsa, API’nin yavaşlığı doğrudan TTFB olur. Statik ön oluşturma ve belirli aralıklarla yeniden oluşturma (artımlı yeniden oluşturma) bu mimarilerde TTFB’yi düşürmenin standart yoludur.

TTFB ve kişiselleştirme dengesi

Pazarlama ekipleri çoğu zaman sayfayı kullanıcıya göre değiştirmek ister: şehre göre farklı kampanya, geçmiş ziyarete göre farklı ürün. Bu değişiklikler sunucu tarafında yapıldığında sayfa önbelleğe alınamaz ve TTFB yükselir. Kişiselleştirmenin getirisi ile hız kaybının maliyetini karşılaştırmak gerekir. Çoğu durumda en iyi yol, sayfanın ortak kısmını önbellekten verip kişisel bölümü küçük bir istekle sonradan eklemektir; ancak bu bölümün düzen kaymasına yol açmaması için yeri önceden ayrılmalıdır.

Sık yapılan hatalar

1. Yalnızca sunucuyu güçlendirmek. Sorun yönlendirmede veya mesafedeyse daha güçlü sunucu sonucu değiştirmez.
2. CDN’i yalnızca statik dosyalar için kullanmak. TTFB’yi belirleyen HTML’dir.
3. Test ederken oturum açık kalmak. Yönetici oturumu önbelleği devre dışı bırakır ve yanıltıcı sonuç verir.
4. Önbelleği her güncellemede tamamen temizlemek. Yalnızca değişen sayfaların önbelleğini temizlemek, yoğun güncelleme dönemlerinde yavaşlamayı önler.
5. Reklam bağlantılarındaki yönlendirmeleri görmezden gelmek. Ücretli trafikte en büyük kayıp genellikle buradadır.
6. Tarama istatistiklerine bakmamak. Googlebot’un gördüğü yanıt süresi, kullanıcının gördüğünden farklı olabilir.

TTFB kontrol listesi

1. Sayfa önbelleği açık ve ziyaretçilere önbellekten yanıt veriliyor mu?
2. HTML, CDN kenar sunucularında önbelleğe alınıyor mu?
3. İç bağlantılar, site haritası ve reklam hedefleri doğrudan son adresi gösteriyor mu?
4. HSTS başlığı tanımlı mı?
5. TLS 1.3 ve HTTP/2 veya HTTP/3 açık mı?
6. Yavaş veritabanı sorguları tespit edilip iyileştirildi mi?
7. Sayfa oluşturma sırasında dış servis bekleniyor mu?
8. Server-Timing başlığıyla sunucu içi süreler görünür mü?
9. Search Console tarama istatistiklerindeki ortalama yanıt süresi izleniyor mu?

TTFB’yi kimin düzeltmesi gerekir?

TTFB sorunu tek bir ekibin alanına girmez ve bu yüzden çoğu zaman sahipsiz kalır. Yönlendirmeler pazarlama ve SEO ekibinin, CDN ve protokol ayarları altyapı ekibinin, veritabanı ve uygulama kodu yazılım ekibinin, barındırma paketi ise çoğu zaman satın alma kararının konusudur. Geliştirici araçlarındaki zaman dökümü, sorunu doğru ekibe yönlendirmenin en hızlı yoludur: “site yavaş” yerine “yanıtın 0,6 saniyesi yönlendirmede, 1 saniyesi sunucuda” demek, düzeltmenin kimde olduğunu tartışmasız gösterir.

Hız çalışmalarının kalıcı olması için TTFB’yi yayına alma sürecinin bir kontrol maddesine çevirmek de önemlidir: yeni bir eklenti, yeni bir kişiselleştirme kuralı veya yeni bir takip yönlendirmesi eklendiğinde TTFB’ye etkisi ölçülmelidir. Aksi hâlde birkaç ayda kazanılan hız, fark edilmeden geri kaybedilir. Hızın dönüşüm ve sıralamayla ilişkisini site hızı yazımızda bütünüyle ele aldık.

TTFB’nin mobil ve masaüstü farkı

Aynı sayfanın TTFB değeri mobilde masaüstüne göre genellikle belirgin biçimde yüksektir. Bunun sebebi sunucu değil ağdır: mobil bağlantılarda gidiş-dönüş süreleri daha uzundur, bağlantı kurulumu daha pahalıdır ve sinyal kalitesi değiştikçe paket kayıpları yaşanır. Bu yüzden TTFB hedeflerini mobil verisine göre belirlemek ve iyileştirmelerin etkisini mobil kullanıcılar üzerinde ölçmek gerekir. Gidiş-dönüş süresinin etkisini ve nasıl azaltılacağını RTT yazımızda ayrıntılı anlattık.

DNS tarafında yapılabilecekler

DNS çözümlemesi genellikle TTFB’nin küçük bir parçasıdır ama gözden kaçtığında düzenli bir gecikme kaynağı olur. Hızlı ve coğrafi olarak dağıtık bir DNS sağlayıcısı kullanmak, kayıtların yaşam süresini (TTL) makul tutmak ve gereksiz CNAME zincirlerinden kaçınmak bu kalemi düşürür. Sayfada ayrı alan adlarından yüklenen kritik kaynaklar varsa, tarayıcıya bu alan adlarını önceden çözümlemesini söyleyen dns-prefetch veya bağlantıyı da önceden kuran preconnect ipuçları kullanılabilir. Ancak ana belgenin TTFB’si için asıl belirleyici olan, kendi alan adınızın DNS performansıdır.

Özetle

TTFB, yönlendirme, service worker, DNS, bağlantı kurulumu ve sunucu işleme sürelerinin toplamıdır ve 0,8 saniyenin altında olması hedeflenir. Core Web Vitals metriği değildir ama FCP ile LCP’nin tabanını oluşturur ve Googlebot’un tarama hızını etkiler. En büyük kazançlar genellikle sayfa önbelleği, HTML’in CDN kenarında önbelleğe alınması ve yönlendirme zincirlerinin temizlenmesinden gelir. Doğru teşhis için geliştirici araçlarındaki zaman dökümüne ve Server-Timing başlığına bakmak, tahmin yürütmekten çok daha hızlı sonuç verir. Teknik altyapı çalışmanızı planlamak için SEO hizmetimizi inceleyebilirsiniz.