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

TTFB nedir sorusuyla çoğu kişi bir rapor yüzünden karşılaşır: PageSpeed Insights ya da GTmetrix "sunucu yanıt süresini azaltın" der, altında saniye cinsinden bir rakam yazar ve o rakamın ne anlama geldiği hiçbir yerde açıklanmaz. Time to First Byte, yani ilk bayt süresi, tarayıcının isteği gönderdiği andan sunucudan gelen ilk baytı aldığı ana kadar geçen süredir. Ama bu tanım tek başına yanıltıcıdır, çünkü o süreye DNS çözümlemesi, TCP el sıkışması, TLS anlaşması ve ağ mesafesi de dahildir — sunucunun gerçekten "düşünerek" harcadığı zaman ise bunların yalnızca bir parçasıdır.

Türkçe kaynakların neredeyse tamamı bu noktayı atlayıp doğrudan aynı çözüm listesine geçiyor: CDN kullanın, önbellek açın, PHP'yi güncelleyin. Oysa hangi rakamın gerçek olduğunu bilmeden bu listeyi uygulamak, ateşi ölçmeden ilaç vermeye benzer. Bu yazıda önce TTFB'nin içindeki beş ayrı aşamayı ayıracağız, sonra curl ile saf sunucu süresini nasıl izole edeceğinizi göstereceğiz, ardından yüksek çıkan değeri gerçekten düşüren müdahaleleri etki sırasına göre uygulayacağız. Sonunda elinizde tahmin değil, ölçülmüş bir rakam olacak.

TTFB Nedir ve Tam Olarak Neyi Ölçer#

TTFB, tarayıcının HTTP isteğini yollamasıyla yanıtın ilk baytının gelmesi arasındaki toplam süredir. "İlk bayt" ifadesi önemlidir: sayfanın tamamının inmesi değil, yalnızca yanıtın başlamasıdır. Yani 2 MB'lık bir sayfa da 20 KB'lık bir sayfa da aynı TTFB'ye sahip olabilir; boyut bu metriği etkilemez.

Bu metriğin değerli olmasının sebebi, sayfa üzerindeki her şeyin ondan sonra başlamasıdır. Tarayıcı HTML gelmeden CSS'i, script'i veya görselleri öğrenemez. TTFB 1,5 saniyeyse, sayfanın geri kalanı için sayaç 1,5 saniyeden başlar ve o kaybı sonradan hiçbir optimizasyonla geri alamazsınız. Bu yüzden ilk bayt süresi, ölçülmesi gereken ilk şeydir; sayfa ağırlığı ve script yükü daha sonra gelir. Yavaşlığın hangi katmandan geldiğini ayırmanın genel yöntemini sitem neden yavaş açılıyor yazısında ele aldık.

Sık yapılan bir karışıklığı baştan çözelim: TTFB bir Core Web Vitals metriği değildir. Google'ın sıralama sinyali olarak kullandığı metrikler LCP, CLS ve INP'dir. TTFB ise bunların hepsini besleyen bir ön koşuldur — kötü TTFB kötü LCP üretir, ama TTFB'nin kendisi doğrudan bir sıralama metriği olarak raporlanmaz.

TTFB'nin İçinde Ne Var: Beş Aşamalı Kırılım#

Tek bir "TTFB" rakamı aslında beş ayrı işin toplamıdır ve bunların yalnızca sonuncusu sizin kontrolünüzdedir.

Bu tablonun anlamı şudur: yurt dışından ölçüm yaptığınızda ilk üç satır toplamda 300 ms'yi bulabilir ve TTFB'niz "kötü" görünür — sunucunuz aslında 60 ms'de cevap veriyor olmasına rağmen. Tersine, aynı şehirden ölçtüğünüzde ağ maliyeti neredeyse sıfırlanır ve gerçek sunucu süresi ortaya çıkar.

O yüzden anlamlı olan tek rakam sunucu üretim süresidir ve onu izole etmek gerekir. Bunun nasıl yapıldığı bir sonraki bölümün konusu.

TTFB Nasıl Doğru Ölçülür: curl ile Saf Sunucu Süresi#

Sunucunun kendi harcadığı süreyi öğrenmenin en temiz yolu, curl'ün zaman değişkenlerinden time_starttransfer ile time_pretransfer farkını almaktır. Önce biçim dosyasını hazırlayın:

cat > /tmp/ttfb.txt <<'EOF'
       dns:  %{time_namelookup}
       tcp:  %{time_connect}
       tls:  %{time_appconnect}
   istek_ok:  %{time_pretransfer}
  ilk_bayt:  %{time_starttransfer}
     toplam:  %{time_total}
EOF

Ölçümü çalıştırın:

curl -o /dev/null -s -w "@/tmp/ttfb.txt" https://ornek-site.com/

Örnek çıktı:

       dns:  0.018
       tcp:  0.049
       tls:  0.118
   istek_ok:  0.118
  ilk_bayt:  1.352
     toplam:  1.389

Burada tarayıcının göreceği TTFB 1,352 saniyedir. Ama saf sunucu süresi 1,352 − 0,118 = 1,234 saniyedir. Ağ ve TLS maliyeti sadece 118 ms. Yani sorunun %90'ı uygulamanızda, ağınızda değil.

Karşı örnek:

       dns:  0.021
       tcp:  0.181
       tls:  0.402
   istek_ok:  0.402
  ilk_bayt:  0.478
     toplam:  0.491

Bu sitede tarayıcı TTFB'si 478 ms — rapor bunu "iyileştirilmeli" diye işaretler. Oysa saf sunucu süresi yalnızca 76 ms. Buradaki sorun sunucu değil, mesafedir: TLS anlaşması tek başına 402 ms almış. Bu tabloda önbellek eklentisi kurmak hiçbir işe yaramaz; çözüm ya sunucuyu kitleye yaklaştırmak ya da bağlantı katmanını iyileştirmektir.

Ölçümü tek seferde değil, arka arkaya alın:

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://ornek-site.com/
  sleep 1
done

Beş sonucun ilki yüksek, kalanları düşükse önbellek çalışıyor demektir. Hepsi yüksekse önbellek ya kapalıdır ya da o sayfa önbelleğe alınmıyordur. curl'ün başlık, yönlendirme ve POST kullanımları için curl ile HTTP istekleri yazısına bakabilirsiniz.

Aynı sunucuda referans ölçümü#

Uygulamanın mı yoksa sunucunun mu yavaş olduğunu ayırmanın kesin yolu, aynı sunucuda düz bir dosya ölçmektir. Sunucuya küçük bir statik dosya koyun:

echo "ok" > /home/kullanici/public_html/hiztest.txt

Sonra ölçün:

curl -o /dev/null -s -w "statik: %{time_starttransfer}\n" https://ornek-site.com/hiztest.txt
curl -o /dev/null -s -w "dinamik: %{time_starttransfer}\n" https://ornek-site.com/

Statik dosya 120 ms'de, ana sayfa 1,3 saniyede geliyorsa web sunucusu ve ağ sağlıklıdır; kayıp tamamen PHP ve veritabanı tarafındadır. İkisi de yüksekse sorun daha alt katmandadır — sunucu yükü, disk veya ağ.

Tarayıcı ve Test Araçları Neden Farklı Rakam Verir#

Aynı sitenin TTFB'sini üç farklı yerde ölçüp üç farklı sonuç almanız normaldir ve sebebi ölçümün nereden yapıldığıdır.

• Tarayıcı geliştirici araçları, sizin bilgisayarınızdan sizin internet bağlantınızla ölçer. Ev interneti, VPN, iş yeri güvenlik duvarı, hatta antivirüs yazılımı bu rakama eklenir.
• Test siteleri, kendi seçtikleri veri merkezinden ölçer. Sunucunuz Türkiye'de, test aracı Avrupa'da veya Kuzey Amerika'daysa aradaki mesafe rakama yansır.
• Alan verisi (gerçek kullanıcı ölçümü), sitenizi gerçekten ziyaret eden insanların cihazlarından toplanır. Bu, en gerçekçi ama en dalgalı rakamdır.
• curl ile sunucudan ölçüm, ağ payını neredeyse sıfırlar ve saf uygulama süresini verir.

Bu dördü aynı şeyi ölçmez, dolayısıyla birbirleriyle karşılaştırılmaları da anlamsızdır. Doğru kullanım şudur: iyileştirme kararını curl ölçümüne göre verin, sonucu ise gerçek kullanıcı verisinden doğrulayın. Test sitesi skorunu ise yalnızca kendi geçmiş ölçümünüzle kıyaslayın. Bu ayrımın SEO tarafındaki karşılığını PageSpeed Insights skoru yükseltme yazısında ele aldık.

Bir de yönlendirme tuzağı var. http:// adresini ölçüyorsanız ve site https:// ile www ekine yönlendiriyorsa, ölçtüğünüz süre iki isteğin toplamıdır. Yönlendirme zincirini görmek için:

curl -sIL http://ornek-site.com/ | grep -iE "^HTTP|^location"

Üç satırlık bir zincir çıkıyorsa, ziyaretçileriniz her açılışta iki gereksiz gidiş-geliş ödüyor demektir. Yönlendirmeleri tek adıma indirmek — yani http://alan.com adresini doğrudan https://www.alan.com hedefine yollamak — tek başına birkaç yüz milisaniye kazandırabilir.

Sunucu Yanıt Süresi Kaç Olmalı#

Pratikte kullanılabilir hedefler şunlardır ve burada bahsedilen rakamlar saf sunucu üretim süresi içindir, tarayıcının gördüğü toplam TTFB için değil.

Bu aralıklar dinamik sayfalar içindir. Statik bir dosya için 100 ms bile yüksektir. Yönetici paneli sayfaları ise doğaları gereği önbelleğe alınamadığı için ön yüzden yavaş olur; onları ayrı değerlendirin.

Önemli bir uyarı: 0-50 ms aralığındaki bir sonuç genellikle sayfanın önbellekten geldiğini gösterir, uygulamanızın gerçekten o kadar hızlı olduğunu değil. Önbelleği baypas eden bir istekle kontrol edin:

curl -o /dev/null -s -w "%{time_starttransfer}\n" "https://ornek-site.com/?onbellek-kir=$RANDOM"

Bu rakam gerçek üretim sürenizdir ve önbellek bir gün devre dışı kalırsa ziyaretçilerinizin göreceği süre budur.

Yüksek TTFB'nin Gerçek Nedenleri#

Saf sunucu süresi yüksek çıktıysa, sıklık sırasına göre nedenler şunlardır.

1. Sayfa önbelleği yok. Her istekte tam bir uygulama döngüsü çalışıyorsa 30-80 veritabanı sorgusu ve yüzlerce dosya okuması yapılır. Önbellek devreye girdiğinde bu iş bir kez yapılır. Etkisi diğer bütün maddelerin toplamından büyüktür; katman katman kurulumu WordPress önbellek rehberi yazısında.
2. OPcache kapalı veya küçük. PHP dosyalarının derlenmiş biçimi bellekte tutulmuyorsa her istek aynı derlemeyi tekrarlar. PHP OPcache ayarları genelde birkaç satırlıktır ve etkisi hemen ölçülür.
3. Eski PHP sürümü. Aynı kod, güncel sürümde belirgin biçimde daha az işlem harcar. Panelden değiştirmek için PHP sürüm yönetimi yazısına bakın.
4. Veritabanı yavaşlığı. İndekssiz sorgular, şişmiş seçenek tabloları, birikmiş geçici kayıtlar. Yavaş sorgu kaydını açıp en pahalı sorguları bulmak doğru başlangıçtır; tek bir eksik indeks tek başına yüzlerce milisaniye ekleyebilir.
5. Sayfa üretimi sırasında dış API çağrısı. Bir eklenti, sayfa oluşturulurken uzak bir servise bağlanıyorsa, o servisin gecikmesi doğrudan sizin TTFB'nize eklenir. Sunucu kaynakları boş görünür ama süre yüksektir — bu grubun teşhisi en zorudur.
6. Kaynak doygunluğu. CPU veya eşzamanlı işlem limitine dayanan istekler kuyruğa girer. İşareti, sürenin yoğun saatlerde belirgin biçimde artmasıdır; panelinizdeki kaynak kullanım grafiği bu tabloyu doğrular.
7. Nesne önbelleği yokluğu. Sayfa önbelleğine alınamayan sepet, üyelik, arama gibi sayfalarda tekrar eden sorguları bellekte tutmak tek çözümdür; Redis object cache bunu sağlar.

TTFB Düşürmenin Uygulama Sırası#

Sıra önemlidir, çünkü yanlış sırada yapılan müdahaleler birbirinin etkisini gizler.

1. Mevcut değeri ölçün ve kaydedin (önbellek kırılmış hâliyle birlikte).
2. Yönlendirme zincirini sadeleştirin — bu, kod değişikliği gerektirmeyen ilk kazançtır.
3. OPcache'i açın ve bellek boyutunu yeterli verin.
4. PHP sürümünü güncelleyin, sonra tekrar ölçün.
5. Sayfa önbelleğini devreye alın ve gerçekten çalıştığını başlıklardan doğrulayın.
6. Veritabanı bakımı yapın: gereksiz kayıtları temizleyin, yavaş sorguları bulun.
7. Önbelleğe alınamayan sayfalar için nesne önbelleği ekleyin.
8. Her adımdan sonra ölçümü tekrarlayın ve tablonuza yazın.

Bu sıra, en ucuz ve en etkili müdahaleyi başa alır. Dördüncü adıma gelmeden CDN, sunucu yükseltme veya tema değişikliği düşünmeyin.

Önbelleğin Çalıştığını Kanıtlamak#

"Önbellek eklentisi kurdum" cümlesi, önbelleğin çalıştığı anlamına gelmez. Kanıtı yanıt başlıklarında aramak gerekir:

curl -sI https://ornek-site.com/ | grep -iE "cache|age|x-litespeed|x-cache"

Beklenen çıktıya örnek:

x-litespeed-cache: hit
cache-control: public, max-age=604800
age: 312

hit yerine miss görüyorsanız veya bu başlıklardan hiçbiri yoksa, istekleriniz önbelleğe uğramadan uygulamaya gidiyor demektir. Yaygın sebepler: oturum çerezi taşıyan istekler önbelleğe alınmaz, bazı sayfalar kural dışı bırakılmıştır, ya da eklenti kurulu ama sunucu tarafında etkinleştirilmemiştir. Sunucu düzeyinde önbellek yapılandırması için LiteSpeed Cache yazısı iyi bir başlangıç noktasıdır.

Bir de yaygın bir yanılgı var: önbellek eklentisi kurulunca TTFB'nin sıfıra ineceği beklenir. Önbellekten servis edilen bir sayfa bile ağ mesafesi ve TLS maliyetini ödemek zorundadır. 30 ms sunucu süresi + 120 ms bağlantı = 150 ms TTFB, mükemmel bir sonuçtur ve daha aşağısı için yapılabilecek tek şey sunucuyu ziyaretçiye yaklaştırmaktır.

Sürekli İzleme: Tek Ölçüm Yeterli Değil#

TTFB sabit bir sayı değildir; trafik, komşu yük ve arka plan görevleriyle gün içinde dalgalanır. Tek bir iyi ölçüm sizi rahatlatmasın. Basit bir izleme için sunucuda saatlik bir görev bırakabilirsiniz:

*/15 * * * * /usr/bin/curl -o /dev/null -s -w "$(date +\%F\ \%H:\%M) %{time_starttransfer}\n" https://ornek-site.com/ >> /var/log/ttfb.log

Birkaç gün sonra dosyaya bakın:

sort -k3 -n -r /var/log/ttfb.log | head -20

En yüksek yirmi ölçümün saatleri kümeleniyorsa (ör. her gün 20:00-23:00 arası), bu bir kaynak sıkışması işaretidir ve çözümü kod optimizasyonu değil kapasitedir. Dağınık ve rastgeleyse, muhtemelen sayfa üretiminde bir dış bağımlılık vardır ve o servisin kesintileri sizin sürenize yansıyordur.

Sıkça Sorulan Sorular#

TTFB kaç saniye olmalı#

Saf sunucu üretim süresi için hedef 300 milisaniyenin altıdır, 600 milisaniyenin üzeri ise iyileştirme gerektirir. Tarayıcının gördüğü toplam TTFB bu rakamın üstüne DNS, TCP ve TLS maliyetini ekler; bu yüzden yurt dışından yapılan bir ölçümde 500 ms görmek, sunucunuzun 100 ms'de cevap verdiği anlamına gelebilir. Değerlendirme yaparken hangi rakamı ölçtüğünüzü bilmek, rakamın kendisinden daha önemlidir. Önbellekten gelen sayfalarda 50 ms altı değerler normaldir ama gerçek uygulama sürenizi göstermez.

TTFB Core Web Vitals metriği mi#

Hayır, TTFB doğrudan bir Core Web Vitals metriği değildir. Google'ın kullandığı üç metrik LCP, CLS ve INP'dir. Ancak TTFB bunların hepsinden önce gerçekleştiği için yüksek bir ilk bayt süresi doğrudan LCP'yi bozar; sayfa geç başlarsa en büyük içerik de geç boyanır. Bu yüzden TTFB, ölçülmesi gereken ama tek başına hedef olarak alınmaması gereken bir ön koşuldur.

CDN kullanmak TTFB'yi düşürür mü#

CDN, önbelleğe alınabilen içerikler için TTFB'yi belirgin biçimde düşürür, dinamik sayfa üretimi için düşürmez. HTML sayfanız kenar sunucuda önbelleğe alınıyorsa ziyaretçi en yakın noktadan cevap alır ve hem ağ mesafesi hem sunucu süresi ortadan kalkar. Ancak sayfa her istekte sizin sunucunuzda üretiliyorsa, CDN yalnızca araya bir durak daha ekler ve bazı durumlarda süreyi bir miktar artırır. Kararı, önce sunucu üretim sürenizi ölçtükten sonra verin.

Önbellek eklentisi kurdum ama TTFB düşmedi, neden#

En sık sebep, isteklerin önbelleğe hiç uğramamasıdır. Oturum açmış kullanıcılar, sepette ürün bulunan ziyaretçiler ve çerez taşıyan istekler çoğu yapılandırmada önbellek dışı bırakılır; siz de kendi sitenizi giriş yapmış hâlde test ediyorsanız hep önbelleksiz sonucu görürsünüz. Yanıt başlıklarında x-cache veya benzeri bir alanda hit görüp görmediğinizi kontrol edin. Ayrıca eklenti kurulu olsa bile sunucu tarafındaki önbellek modülü etkin değilse hiçbir şey önbelleğe alınmaz.

Sunucu yanıt süresi neden gün içinde değişiyor#

Değişmesi normaldir ve genellikle yük ile ilgilidir. Paylaşımlı ortamda aynı makinedeki diğer hesapların yoğunlaşması, sizin sitenizde çalışan zamanlanmış görevler, yedekleme işlemleri ve trafik artışı sunucu süresini yükseltir. Dalgalanmanın belirli saatlerde tekrar etmesi kapasite sorununa, tamamen rastgele olması ise sayfa üretimi sırasında beklenen bir dış bağımlılığa işaret eder. Bunu ayırt etmek için birkaç gün boyunca düzenli aralıklarla ölçüm alıp saatlere göre gruplamak gerekir.

Yönetici paneli çok yavaş ama site hızlı, sebebi ne#

Yönetici paneli sayfaları önbelleğe alınamadığı için her açılışta tam bir uygulama döngüsü çalıştırır. Ön yüz önbellekten servis edilirken panel gerçek üretim sürenizi gösterir; yani panelin yavaşlığı aslında sitenizin önbelleksiz hâlinin ne kadar yavaş olduğunu söyler. Sebepler genellikle şişmiş veritabanı tabloları, panelde çalışan eklentilerin arka plan istekleri ve nesne önbelleğinin bulunmamasıdır. Panelin hızlanması için sayfa önbelleği değil, nesne önbelleği ve veritabanı bakımı gerekir.

TTFB'yi ölçerken hangi araca güvenmeliyim#

Karar vermek için curl ile sunucudan yaptığınız ölçüme, doğrulamak için gerçek kullanıcı verisine güvenin. Tarayıcı geliştirici araçları sizin bağlantınızı, test siteleri ise kendi veri merkezlerinin konumunu sonuca katar; ikisi de mutlak doğru değildir ama kendi içlerinde tutarlıdır. En sağlıklı yaklaşım, aynı aracı hem müdahale öncesi hem sonrası kullanıp farkı okumaktır. Farklı araçların rakamlarını birbiriyle karşılaştırmak yanıltıcı sonuç üretir.

Kapanış#

TTFB'yi düşürmenin sırrı gizli bir ayar değil, doğru rakamı ölçmektir. Tarayıcının gösterdiği süre içinde ağ mesafesi, TLS anlaşması ve yönlendirmeler de vardır; bunları ayırmadan yapılan her müdahale karanlıkta atış olur. curl ile saf sunucu üretim sürenizi izole ettiğinizde, yapılacak iş listesi kendiliğinden kısalır: önbellek, PHP, veritabanı ve gerekirse kapasite. Bu dördünü sırayla uygulayıp her adımdan sonra tekrar ölçerseniz, ilerlemeyi his değil rakam olarak görürsünüz.

Ölçümünüz uygulamanın değil kapasitenin sınırına dayandığınızı gösteriyorsa, kaynakları izole eden bir yapıya geçmek kalıcı çözümdür; VDS sunucu ve performans sunucu paketleri bu ihtiyacı karşılar. Önbellek, PHP ve veritabanı ayarlarını hazır gelmiş bir ortamda istiyorsanız WordPress hosting paketleri bu yapılandırmayı üstlenir. Sunucu tarafındaki ölçüm ve ince ayar işini devretmek isterseniz sunucu yönetimi hizmeti bu süreci sizin adınıza yürütür.