TTFB Nedir? Sunucu Yanıt Süresi Nasıl Düşürülür?

Bir web sitesinin “yavaş” hissettirmesinin en sinsi sebeplerinden biri, kullanıcı henüz hiçbir şey görmeden önce boş ekrana bakarak beklediği o ilk saniyelerdir. Görseller, yazı tipleri, JavaScript; bunların hepsi henüz sıraya bile girmemiştir. Tarayıcı sadece sunucudan gelecek ilk yanıtı bekler. İşte bu bekleyişin ölçüsü TTFB‘dir ve performans optimizasyonunda sıklıkla gözden kaçan, ancak diğer her metriğin üzerine inşa edildiği temeldir.

Bu yazıda TTFB’nin ne olduğunu, hangi bileşenlerden oluştuğunu, “iyi” bir değerin ne anlama geldiğini ve pratikte sunucu yanıt süresini nasıl düşürebileceğinizi adım adım ele alacağız. Amacımız teoriyi geçip, gerçekten uygulanabilir kaldıraçlara odaklanmak.

TTFB Nedir?

TTFB, açılımıyla Time to First Byte (İlk Bayta Kadar Geçen Süre), bir tarayıcının bir kaynak için HTTP isteğini gönderdiği andan, sunucudan yanıtın ilk baytını aldığı ana kadar geçen süredir. Dikkat edin: burada ölçülen, sayfanın tamamının yüklenmesi değildir. Sadece sunucunun “duydum, işte cevabın ilk parçası” demesine kadar geçen süredir.

Bu ayrım kritik. TTFB, sayfa ağırlığından, görsel sayısından veya JavaScript hacminden büyük ölçüde bağımsızdır. Tamamen sunucunun ve araya giren ağ katmanlarının ne kadar hızlı yanıt verdiğiyle ilgilidir. Bu yüzden 20 KB’lık bir sayfa ile 2 MB’lık bir sayfanın TTFB’si teoride aynı olabilir; fark, üretim ve iletim hızındadır.

TTFB Neden Bu Kadar Önemli?

TTFB tek başına Google’ın sıralama sinyallerinden biri değildir. Ancak dolaylı etkisi devasadır. Çünkü TTFB, kullanıcıya değer sunan asıl metriklerin altındaki zemindir:

• LCP (Largest Contentful Paint): Sayfanın en büyük içerik ögesinin ekrana gelme süresi. LCP hiçbir zaman TTFB’den daha hızlı olamaz. Sunucunuz ilk baytı 900 ms’de gönderiyorsa, LCP’nizin 900 ms’den iyi olması fiziksel olarak imkânsızdır.
• FCP (First Contentful Paint): İlk içeriğin boyanma anı. Aynı mantıkla o da TTFB’nin gölgesinde kalır.

Başka bir deyişle, TTFB’yi iyileştirmek çoğu zaman Core Web Vitals skorunuzu yükseltmenin en hızlı yoludur. Ön uçta megabaytlarca görsel optimize etmeden önce, sunucunun ilk yanıtını hızlandırmak çok daha yüksek getirilidir.

TTFB Nelerden Oluşur? Bileşenlerine Ayıralım

TTFB tek bir olay değil, birbirini takip eden bir zincirin toplamıdır. Bu zinciri anlamak, darboğazın nerede olduğunu görmenizi sağlar. Bir isteğin yolculuğu şöyle işler:

Bileşen	Ne Yapar?	Tipik Etki
DNS Çözümlemesi	Alan adını IP adresine çevirir	İlk ziyarette 20-120 ms; sonra önbelleklenir
TCP El Sıkışması	Tarayıcı ile sunucu arasında bağlantı kurar	Mesafeye bağlı 1 gidiş-dönüş süresi
TLS El Sıkışması	HTTPS şifreleme anlaşmasını yapar	1-2 gidiş-dönüş; HTTP/3 ile azalır
Sunucu İşleme Süresi	Sayfayı üretir (PHP, veritabanı, uygulama mantığı)	En değişken kalem: 20 ms ile 4 sn arası
Ağ Dönüş Süresi	İlk baytın tarayıcıya geri iletilmesi	Coğrafi mesafeye bağlı

Bu tablodaki en önemli satır sunucu işleme süresidir. DNS, TCP ve TLS büyük ölçüde protokol ve altyapı seviyesinde standartlaşmıştır; asıl oynaklık sunucunun sayfayı ne kadar hızlı ürettiğinden gelir. Sıfırdan üretilen dinamik bir WordPress veya e-ticaret sayfası tipik olarak 1-4 saniye sürerken, önbelleklenmiş aynı sayfa 200-500 ms, sunucu tarafı tam önbellekle ise 20 ms’nin altına inebilir.

İyi Bir TTFB Değeri Kaçtır?

Google’ın web.dev üzerinde tanımladığı eşikler nettir ve 75. yüzdelik dilime (yani kullanıcılarınızın %75’ine) göre değerlendirilir:

TTFB Aralığı	Değerlendirme
0 – 800 ms	İyi
800 ms – 1.800 ms	Geliştirilmeli
1.800 ms üzeri	Kötü

Burada önemli bir nüans var: 800 ms bir hedef değil, bir tabandır. Yani TTFB’nizin aktif olarak Core Web Vitals’ınıza zarar vermeye başladığı sınırdır. Gerçekten rahat bir LCP skoru için deneyimli performans mühendisleri tutarlı biçimde 200 ms’nin altını hedefler. İyi yapılandırılmış sunucu ortamları dinamik içerik için 200 ms altını, önbelleklenmiş yanıtlar için 50 ms altını rutin olarak sunabilir.

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

Optimize etmeden önce ölçmelisiniz. TTFB’yi görebileceğiniz birkaç pratik yol:

• Tarayıcı Geliştirici Araçları: Chrome DevTools’ta Network sekmesini açın, bir isteğe tıklayın ve “Timing” bölümünde “Waiting for server response” satırına bakın. Bu değer sunucu işleme süresini gösterir.
• PageSpeed Insights / Lighthouse: “Sunucu yanıt sürelerini azaltın” (Reduce server response times) denetimi doğrudan bu metriği işaret eder ve 600 ms’yi eşik alır.
• curl komutu: Terminalden hızlı bir ölçüm için curl -w “%{time_starttransfer}n” -o /dev/null -s https://alanadiniz.com komutu ilk baytın kaç saniyede geldiğini verir.
• CrUX / RUM verisi: Gerçek kullanıcı ölçümü (Real User Monitoring), laboratuvar testlerinden farklı olarak sahadaki asıl deneyimi gösterir.

Laboratuvar testi ile saha verisi arasında fark görürseniz şaşırmayın; coğrafi dağılım, önbellek durumu ve trafik yoğunluğu gerçek TTFB’yi belirgin biçimde değiştirir.

Sunucu Yanıt Süresi Nasıl Düşürülür? 8 Etkili Yöntem

Şimdi işin özüne gelelim. Aşağıdaki kaldıraçları genel olarak en yüksek getiriden en spesifik olana doğru sıraladık.

1. Sunucu Tarafı Tam Sayfa Önbelleği Kullanın

Tek bir değişiklikle en büyük kazancı sağlayan yöntem budur. Uygulamanızın önüne bir tam sayfa önbellek katmanı koyduğunuzda, aynı sayfa her istekte sıfırdan üretilmez; hazır çıktı doğrudan sunulur. Bu, 400 ms’lik bir TTFB’yi önbelleklenmiş sayfalarda 20 ms’nin altına indirebilir. LiteSpeed sunucularında LSCache, Apache/Nginx dünyasında Varnish veya FastCGI önbelleği bu işi görür. Alastyr sunucularında LiteSpeed ve LSCache standart olarak sunulduğu için, WordPress gibi dinamik uygulamalarda önbellek katmanı ek yapılandırma gerektirmeden devreye girer.

2. Güncel PHP Sürümü ve OPcache

PHP’nin her ana sürümü belirgin performans artışı getirir. Eski bir PHP sürümünden güncel bir sürüme geçmek, kod tabanına dokunmadan sunucu işleme süresini ciddi biçimde kısaltabilir. Buna ek olarak OPcache, derlenmiş PHP kodunu bellekte tutarak her istekte yeniden derleme yükünü ortadan kaldırır. Alastyr hosting paketlerinde PHP sürüm seçici bulunur; uyumlu olduğunuz en güncel sürüme geçmeniz önerilir.

3. Kaliteli ve Doğru Konumlandırılmış Hosting

Tüm yazılım optimizasyonlarını yaptıysanız ve TTFB hâlâ yüksekse, darboğaz büyük ihtimalle donanım ve altyapıdır. Aşırı doldurulmuş paylaşımlı bir sunucuda, komşularınızın yükü sizin yanıt sürenizi doğrudan etkiler. Burada iki şey önemlidir: sunucunun donanım gücü ve kullanıcılarınıza coğrafi yakınlığı. Türkiye’deki kullanıcılara hizmet veriyorsanız, yurt dışı bir veri merkezi yerine yerli bir veri merkezi ağ dönüş süresini gözle görülür azaltır. Alastyr’ın İzmir’deki kendine ait veri merkezi, all-flash Dell EMC Unity depolama ve Intel Xeon Gold işlemcilerle bu tarafı güçlü tutar.

4. Gereksiz Yönlendirmeleri Kaldırın

Her yönlendirme (301/302) ekstra bir gidiş-dönüş demektir ve TTFB’ye doğrudan eklenir. http’den https’e, www’den www’suz sürüme veya eski URL’lerden yenilerine zincirleme yönlendirmeler birikerek yüzlerce milisaniyeye mal olabilir. Yönlendirme zincirlerini teke indirin; ideal olarak sunucu yapılandırması seviyesinde tek adımda çözün.

5. Veritabanı Sorgularını Optimize Edin

Dinamik sayfalarda sunucu işleme süresinin büyük kısmı veritabanına gider. Eksik indeksler, N+1 sorgu problemleri veya optimize edilmemiş sorgular TTFB’yi kolayca ikiye katlar. Yavaş sorgu günlüğünü (slow query log) inceleyin, sık kullanılan sütunlara indeks ekleyin ve mümkünse Redis gibi bir nesne önbelleği (object cache) ile veritabanı yükünü azaltın.

6. TLS ve Protokol Katmanını Modernleştirin

HTTP/2 ve özellikle HTTP/3 (QUIC üzerinde), bağlantı kurma ve TLS el sıkışması aşamalarını hızlandırır. HTTP/3, TCP yerine UDP tabanlı QUIC kullandığı için özellikle mobil ve kararsız ağlarda gidiş-dönüş sayısını azaltarak TTFB’nin ağ bileşenini kısaltır. Ayrıca TLS 1.3 kullanmak el sıkışmasını tek gidiş-dönüşe indirir.

7. Ücretsiz SSL ve Doğru Sertifika Yapılandırması

Yanlış yapılandırılmış veya zincir eksikliği olan bir SSL sertifikası, ekstra doğrulama turlarına yol açarak TTFB’yi uzatabilir. Modern, doğru zincirlenmiş bir SSL sertifikası ve OCSP stapling desteği bu maliyeti düşürür.

8. Sunucu Kaynağınızı Büyütün

Yüksek trafikli veya ağır uygulamalar için paylaşımlı hosting tavan yapabilir. Böyle durumlarda ayrılmış kaynaklara geçmek en temiz çözümdür. Kendi CPU ve RAM’inize sahip olduğunuz bir VPS veya bulut sunucu, komşu etkisini ortadan kaldırarak tutarlı ve düşük bir TTFB sağlar. Trafiğiniz öngörülemez şekilde dalgalanıyorsa, ölçeklenebilir bulut altyapısı ani yük artışlarında bile yanıt süresini korur.

Sık Yapılan Bir Hata: TTFB’yi CDN ile Karıştırmak

Yaygın bir yanılgı, “CDN kurunca TTFB düzelir” düşüncesidir. CDN yalnızca statik ve önbelleklenebilir içerik için ilk baytı hızlandırır; edge sunucu içeriği önbelleğinde tutuyorsa. Ancak dinamik, kişiye özel içerikte (giriş yapmış kullanıcı, sepet, hesap sayfası) istek yine de köken sunucuya (origin) gider. Yani asıl sunucunuz yavaşsa, CDN bu tür sayfalarda sizi kurtarmaz. CDN önemli bir araçtır ama köken sunucu optimizasyonunun yerini tutmaz. Önce sunucu tarafını sağlamlaştırın.

Özet ve Öncelik Sıralaması

TTFB’yi düşürmek istiyorsanız, çabanızı şu sırayla harcamanız en yüksek getiriyi sağlar:

• Önce ölçün: DevTools ve PageSpeed Insights ile mevcut TTFB’nizi netleştirin.
• Sunucu tarafı tam sayfa önbelleğini (LSCache/Varnish) devreye alın.
• PHP sürümünü güncelleyin ve OPcache’i etkinleştirin.
• Yönlendirme zincirlerini temizleyin, veritabanı sorgularını optimize edin.
• Bunlara rağmen yüksekse hosting kalitesini ve coğrafi konumu gözden geçirin, gerekirse VPS/bulut sunucuya geçin.

Unutmayın: TTFB görünmez bir metrik gibi dursa da, kullanıcının siteyi “hızlı” mı yoksa “yavaş” mı algıladığını belirleyen ilk andır. Bu ilk saniyeyi kazanmak, geri kalan tüm optimizasyonların üzerine oturacağı sağlam bir zemin kurar.

Sıkça Sorulan Sorular

TTFB tam olarak neyi ölçer?

TTFB, tarayıcının bir isteği gönderdiği andan sunucudan gelen yanıtın ilk baytını aldığı ana kadar geçen süreyi ölçer. Bu süre DNS çözümlemesi, TCP el sıkışması, TLS el sıkışması, sunucunun sayfayı üretme süresi ve ilk baytın tarayıcıya dönmesini kapsar. Sayfanın tamamının yüklenmesini ölçmez.

İyi bir TTFB değeri kaçtır?

Google 75. yüzdelik dilimde 800 ms ve altını “iyi”, 800-1.800 ms arasını “geliştirilmeli”, 1.800 ms üzerini “kötü” olarak değerlendirir. Ancak 800 ms bir tabandır; rahat bir LCP skoru için tutarlı biçimde 200 ms altını hedeflemek en sağlıklısıdır.

TTFB ile sunucu yanıt süresi aynı şey mi?

Tam olarak aynı değildir. Sunucu yanıt süresi, TTFB’nin içindeki “sunucu işleme” bileşenidir. TTFB ise buna ek olarak DNS, TCP ve TLS gibi ağ ve bağlantı aşamalarını da içerir. Uygulamada ikisi sıkça birbirinin yerine kullanılır çünkü sunucu işleme süresi çoğu zaman en büyük kalemdir.

TTFB Google sıralamasını etkiler mi?

TTFB doğrudan bir sıralama sinyali değildir. Ancak LCP ve FCP gibi Core Web Vitals metriklerinin altındaki zemin olduğu için dolaylı ama güçlü bir etkisi vardır. Yüksek TTFB, kullanıcı deneyimini ve dolayısıyla arama görünürlüğünü olumsuz etkiler.

Yüksek TTFB’nin en yaygın sebebi nedir?

En yaygın sebep, dinamik sayfaların her istekte sıfırdan üretilmesidir; yani önbellek eksikliğidir. Bunu aşırı doldurulmuş paylaşımlı hosting, eski PHP sürümü, optimize edilmemiş veritabanı sorguları ve gereksiz yönlendirme zincirleri takip eder.

Önbellek TTFB’yi ne kadar düşürür?

Etkisi dramatiktir. Sıfırdan üretildiğinde 1-4 saniye süren bir sayfa, tam sayfa önbelleğiyle 200-500 ms’ye, sunucu tarafı tam önbellekle 20-50 ms’nin altına inebilir. Bu yüzden önbellek, TTFB optimizasyonundaki en yüksek getirili tek adımdır.

CDN kullanmak TTFB sorununu çözer mi?

Kısmen. CDN, statik ve önbelleklenebilir içerik için edge sunuculardan hızlı yanıt vererek TTFB’yi düşürür. Ancak dinamik ve kişiye özel içerik yine köken sunucuya gider; bu yüzden asıl sunucunuz yavaşsa CDN tek başına yeterli olmaz. Önce sunucu tarafını optimize etmek gerekir.

Paylaşımlı hostingde düşük TTFB mümkün mü?

Evet, mümkündür. LiteSpeed ve LSCache gibi güçlü bir sunucu yazılımı, güncel PHP, OPcache ve kaliteli donanımla desteklenen iyi yapılandırılmış bir paylaşımlı hosting, birçok site için 200-400 ms bandında TTFB sunabilir. Ancak çok yüksek trafik veya ağır uygulamalarda ayrılmış kaynaklı VPS ya da bulut sunucu daha tutarlı sonuç verir.

TTFB’mi nasıl ölçebilirim?

Chrome DevTools’un Network sekmesindeki “Waiting for server response” satırından, PageSpeed Insights’ın “Sunucu yanıt sürelerini azaltın” denetiminden veya terminalde curl komutunun time_starttransfer değeriyle ölçebilirsiniz. Gerçek kullanıcı deneyimi için saha (RUM/CrUX) verisine bakmak en doğrusudur.