Bir bağlantıya tıkladığınızda tarayıcı önce bekler. Sunucu cevabın ilk baytını gönderene kadar ekranda hiçbir şey olmaz, çünkü tarayıcının okuyacağı bir HTML yoktur. Bu bekleme süresinin adı TTFB'dir (Time to First Byte, ilk bayta kadar geçen süre).
TTFB, yükleme zincirinin ilk halkasıdır. Sayfanın ilk görünen parçası (FCP) da, en büyük öğesi (LCP) da ondan sonra gelir. Yani TTFB'de kaybettiğiniz her milisaniye, sonraki her metriğe aynen eklenir.
TTFB Testi
Aşağıdaki araç sitenizi İstanbul'daki sunucumuzdan ister ve ilk baytın kaç milisaniyede geldiğini ölçer. Süreyi parçalarına da ayırır: DNS, bağlantı, TLS ve sunucunun bekletme süresi. Siteniz yeterince Chrome ziyaretçisi alıyorsa gerçek kullanıcıların gördüğü değeri de yanına koyar.
"Sitenizde bir eklenti güncellemesi veya tema güncellemesi yaptıysanız mutlaka TTFB değerini buradan test edin. Yeni bir eklenti eklediyseniz TTFB'ye etkisini de bu kısımdan analiz edebilirsiniz."
Celal Dinç, Yazılım Mühendisi
TTFB Neyi Ölçer?
Tıklamayla ilk bayt arasında geçen süre tek bir iş değildir. Arka arkaya beş adım çalışır ve TTFB hepsinin toplamıdır:
- Yönlendirmeler. Adres başka bir adrese yönleniyorsa (301, 302) her yönlendirme ayrı bir istek, ayrı bir bekleme demektir.
- Service worker'ın açılması. Sitede service worker varsa tarayıcının onu başlatması gerekir. Çoğu sitede bu adım yoktur.
- DNS çözümü. Tarayıcı, alan adını (turksem.com) sunucunun IP adresine çevirir. Bu işi sunucu değil tarayıcı yapar ve sonucu bir süre hafızada tutar.
- Bağlantı ve TLS. Tarayıcı sunucuya bağlanır, HTTPS için şifreli bağlantıyı kurar.
- İstek ve sunucu. Tarayıcı sayfayı ister, sunucu sayfayı hazırlar ve ilk baytı gönderir. Veritabanı sorgusu, eklentiler ve şablon işleme bu adımda zaman yer.
İlk dört adım ağ tarafıdır, sonuncusu sunucunun kendisi. TTFB'si yüksek bir sitede ilk iş, sürenin hangi adımda kaybolduğunu bulmaktır. Yukarıdaki aracın kırılımı tam bunu gösterir.
İyi Bir TTFB Kaç ms Olmalı?
Google'ın web.dev rehberi 800 milisaniyeyi eşik olarak verir:
| TTFB | Değerlendirme |
|---|
| 0,8 sn ve altı | İyi |
| 0,8 ile 1,8 sn arası | Geliştirilmeli |
| 1,8 sn üstü | Zayıf |
Bu değerlendirme tek bir ziyarete değil, ziyaretlerin %75'ine bakar. Ziyaretçilerinizin dörtte üçü ilk baytı 800 ms içinde alıyorsa TTFB'niz iyidir.
Core Web Vitals mı?
Hayır. TTFB, Core Web Vitals'ın üç metriğinden (LCP, INP, CLS) biri değildir; web.dev onu teşhis metriği olarak anlatır. Sayfanız LCP'de iyi sonuç alıyorsa 800 ms'yi tutturmak şart değildir. Ama LCP'nin iyi eşiği 2,5 saniyedir ve TTFB bu sürenin içinden harcanır: 1,5 saniyelik TTFB, en büyük öğeyi indirip çizmeye yalnız 1 saniye bırakır.
Kendi Ölçümümüz: İstanbul'dan İki Adres
Eşikler soyut kalmasın diye 1 Kasım 2026'da İstanbul'daki sunucumuzdan iki adresi beşer kez istedik. Tarayıcı kimliği olarak güncel Chrome'u kullandık.
| Adres | İlk istek | Sonraki istekler |
|---|
| www.turksem.com | 450 ms | 160 ile 171 ms |
| www.google.com.tr | 920 ms | 848 ile 859 ms |
İki satır iki ayrı ders veriyor. Kendi sitemizde ilk istek 450 ms sürdü, sonraki dört istek 171 ms'yi geçmedi. Aradaki fark DNS çözümü ve bağlantı kurulumu: ilk ziyarette ödenir, sonra tarayıcı hatırlar. Yani ilk kez gelen ziyaretçi, düzenli okurunuzdan her zaman daha uzun bekler.
Google'ın satırı daha şaşırtıcı. google.com.tr artık kendi sayfasını açmıyor, ziyaretçiyi google.com'a yönlendiriyor. Google bu kararı 15 Nisan 2025'te duyurdu. Ölçümümüzde yalnız bu yönlendirme 0,40 saniye sürdü. Asıl sayfanın ilk baytı ancak 0,85 saniyede geldi. Tek bir yönlendirme, dünyanın en hızlı altyapılarından birinde bile TTFB'yi ikiye katlayıp 800 ms eşiğinin üstüne taşıdı.
Bu ölçümün sınırı
Ölçüm tek konumdan yapıldı. Londra'daki ya da Ankara'daki bir ziyaretçi, sunucuya uzaklığına göre başka sayılar görür. Sitenizin gerçek fotoğrafı için aşağıdaki "TTFB Nasıl Test Edilir ve Takip Edilir?" bölümünde anlattığımız ziyaretçi verisine bakın.
TTFB Neden Önemli?
Çünkü tarayıcı ilk bayt gelmeden hiçbir şey yapamaz. HTML'i okuyamaz, hangi CSS dosyasının, hangi görselin gerektiğini öğrenemez. TTFB yavaşsa sayfanın geri kalanı ne kadar hafif olursa olsun yükleme geç başlar.
Arama tarafında etkisi dolaylıdır. Google, sayfa deneyimini değerlendirirken Core Web Vitals'a baktığını söyler. TTFB bu metriklerin arasında yoktur ama LCP'nin içinde saklıdır. Yavaş bir sunucu, LCP'yi de beraberinde aşağı çeker.
"TTFB değeri diğer tüm değerlerin sürelerini etkileyen temel bir parametredir."
Tahir Dinç, Türk SEM
TTFB Nasıl Düşürülür?
Maddeleri, çoğu sitede getirdiği kazanca göre sıraladık. Önce aracın kırılımına bakın: süre sunucuda mı kayboluyor, ağda mı? Cevaba göre ilgili maddeden başlayın. Google'ın TTFB iyileştirme rehberi de aynı başlıkları sayar.
1. Barındırmayı Gözden Geçirin
Sunucu bekleme süresi yüksekse ilk bakılacak yer barındırmadır. Paylaşımlı barındırmada yüzlerce site aynı işlemciyi ve belleği paylaşır, komşunuz yoğunlaşınca sizin sayfanız yavaşlar. Bellek ve işlemci sınırına dayanan bir sunucuyu büyütmek ya da kendi sunucunuza geçmek çoğu zaman en büyük farkı yaratır. PHP gibi sunucu yazılımlarının güncel sürümleri de eskilerinden belirgin biçimde hızlıdır.
Sunucunun yeri de önemlidir. Ziyaretçileriniz Türkiye'deyse sunucunuz Türkiye'ye yakın olmalı. Her kilometre, bağlantı kurulurken gidip gelen paketlere süre ekler.
2. Sayfa Önbelleği Kullanın
WordPress gibi içerik yönetim sistemleri her ziyarette sayfayı yeniden üretir: veritabanına gider, eklentileri çalıştırır, şablonu işler. Tam sayfa önbelleği bu işi bir kez yapar ve hazır HTML'i saklar. Sonraki ziyaretçi veritabanına hiç uğramadan sayfayı alır. Dinamik sitelerde TTFB'deki en büyük düşüş genellikle buradan gelir.
3. CDN Kullanın
CDN (içerik dağıtım ağı), sitenizin kopyasını dünyanın dört bir yanındaki kenar sunucularda tutar. Ziyaretçi en yakın kenar sunucuya bağlanır, paketin gidip geleceği yol kısalır. İyi bir CDN bunun yanında hızlı DNS, HTTP/2 ve HTTP/3 ile TLS 1.3'ü de getirir. Bunların her biri bağlantı adımından süre kazandırır.
Bir uyarı: CDN, HTML'inizi önbelleğe almıyorsa her istek yine sizin sunucunuza gider. Statik dosyalar hızlanır ama TTFB yerinde sayar.
4. Yönlendirmeleri Kaldırın
Google örneğinde gördüğünüz gibi tek bir yönlendirme bile yüzlerce milisaniye ekler. En sık rastladıklarımız http'den https'ye, www'suz adresten www'li adrese ve sondaki eğik çizgiden kaynaklanan yönlendirmelerdir. Sitenizin içindeki bağlantıları her zaman son adrese verin. http'den https'ye giden adımı ise HSTS başlığı ortadan kaldırır: tarayıcı bir kez öğrendikten sonra siteye doğrudan https ile gider.
5. DNS'i Hızlandırın
DNS çözümü ilk ziyarette ödenir. Yavaş bir DNS sağlayıcısı, sitenize ilk kez gelen herkese her seferinde aynı gecikmeyi yaşatır. Hızlı ve dünyaya dağılmış bir DNS sağlayıcısı seçin, kayıtların önbellekte kalma süresini (TTL) çok kısa tutmayın. DNS yanıt sürenizi DNS Kontrol aracımızla görebilirsiniz.
Sık karıştırılan bir nokta: dns-prefetch ve preconnect ipuçları sayfanın kendi TTFB'sine yaramaz. Bunlar sayfa açıldıktan sonra yazı tipi, analitik gibi başka alan adlarına yapılacak bağlantıları öne çeker.
6. HTML'i Erken Göndermeye Başlayın
Sunucu, sayfanın tamamını hazırlamadan ilk parçasını göndermeye başlayabilir. Akışlı sunucu çizimi (streaming SSR) bunu yapar. Kişiye özel olmayan sayfaları önceden üretip statik dosya olarak sunmak ise beklemeyi neredeyse sıfıra indirir.
Bir adım daha var: 103 Early Hints. Sunucu asıl cevabı hazırlarken tarayıcıya "şu CSS'e ve şu yazı tipine ihtiyacın olacak" der, tarayıcı da onları beklemeden indirmeye başlar. web.dev'e göre 103 yanıtı da ilk bayt sayılır, yani ölçülen TTFB düşer. Asıl kazanç ise kritik dosyaların erken inmesidir.
TTFB Nasıl Test Edilir ve Takip Edilir?
Tek bir ölçüm fikir verir, karar vermeye yetmez. Üç kaynağı birlikte kullanın:
- Bu sayfadaki araç: İstanbul'dan tek istek ve fazlara ayrılmış süre. Bir değişiklikten sonra hızlı kontrol için idealdir.
- Gerçek ziyaretçi verisi: Chrome kullanıcılarının son 28 gündeki deneyimi (Chrome UX Report). PageSpeed Insights'ta ve PageSpeed portalımızda görünür. Yalnız Chrome'u kapsar ve yeterince trafiği olan sitelerde oluşur.
- Tarayıcının kendisi: Chrome'da Geliştirici Araçları'nı açın, Network sekmesinde sayfanın ilk isteğini seçin. Timing bölümündeki "Waiting for server response" satırı sunucunun bekletme süresidir.
Ölçümü bir kez değil, düzenli yapın ve farklı konumlardan bakın. Aynı sayfanın sabah ve akşam, İstanbul'da ve Frankfurt'ta farklı sonuç vermesi normaldir. Önemli olan eğilimdir. Sayfayı gerçek tarayıcıda üç kez açıp ortalamasını alan, şelale grafiği çıkaran ayrıntılı bir test için Site Speed Metrix'i kullanabilirsiniz. Search Console'daki deneyim raporlarını okumak için Search Console rehberimize bakabilirsiniz.
Sunucu Tarafında Yardım Alın
TTFB'yi düşürmek çoğu zaman sitenin içinden değil, sunucunun ayarlarından geçer: önbellek katmanı, sunucu yazılımı, CDN kuralları. Kırılımda sürenin sunucuda kaybolduğunu görüyor ama nereden başlayacağınızı bilmiyorsanız SEO ekibimizle birlikte bakabiliriz.
