Yavaş Sunucu Yanıtı (TTFB): Önce Ölç, Sonra Nedeni Düzelt

TTFB (time to first byte), tarayıcının ya da botun, sunucun sayfayı göndermeye başlayana kadar beklediği süre. Yavaşsa en sık sebep şu: sayfa önbellekten gelmiyor, her istekte sıfırdan üretiliyor. Soğuk başlangıçla birkaç kez ölç, önbelleğin gerçekten devreye girip girmediğine bak ve hosting değiştirmeyi düşünmeden önce önbelleği düzelt.

TTFB'nin içinde ne var, ne yok?

web.dev tanımı şöyle: "the time between starting navigating to a page and when the first byte of a response begins to arrive" (TTFB). Bu pencereye yönlendirmeler, DNS çözümleme, bağlantı ve TLS kurulumu ve sunucunun cevabı hazırlarken harcadığı süre giriyor. Eşik de aynı sayfada: "Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds."

TTFB bir Core Web Vital değil. web.dev, diğer metrikler iyiyse "iyi" TTFB eşiğini tutturmanın şart olmadığını açıkça söylüyor. Yine de önemli, çünkü LCP dahil sonraki her aşama onu bekliyor. LCP, INP, CLS ve reklamların yarattığı kaymalar için AdSense mobil uyumluluk ve hız rehberine bak; bu sayfa sunucu tarafında kalıyor.

AdSense'in yayımlanmış bir TTFB şartı yok. Asıl risk erişilebilirlik: yavaş cevap veren ya da yük altında zaman aşımına düşen sunucu, "site kapalı veya kullanılamıyor" reddini üreten sunucudur (site kapalı rehberi). Google yavaş siteyi daha az da tarıyor: "If the site slows down (latency increases or response times become longer) ... the limit goes down and Google crawls less" (tarama bütçesi).

Approvalens bunu nasıl ölçüyor?

access.slow_server tek bir isteğe dayanıyor: taramanın başındaki ana sayfa isteği. İstek kendi sunucumuzdan, masaüstü Chrome kullanıcı aracısıyla, çerezsiz başlayarak ve Accept-Encoding olarak gzip ve deflate göndererek yapılıyor. İsteği gönderdiğimiz andan yanıt başlıkları gelene kadar geçen süreyi, yönlendirmelerden sonraki son adres için ölçüyoruz. Önceki yönlendirme adımları bu sayıya dahil değil; onlar için yönlendirme zinciri ve döngüsü rehberine bak.

Yanıt başlıklarına kadar süre	Sonuç
1.500 ms ya da daha az	Geçti, süre gösterilir
1.500 ms üstü	Uyarı
3.500 ms üstü	Kritik

Sunucu 15 saniye boyunca hiçbir şey göndermezse istek zaman aşımına uğrar ve ana sayfa erişilemez sayılır. Aynı ana sayfa yanıtına iki kontrol daha bakıyor: HTML yaklaşık 20 KB'tan büyük olup Content-Encoding başlığı olmadan geliyorsa tech.compression, ana sayfa HTML'i 1 MB'ı geçiyorsa seo.html_size çıkıyor. Taramanın geri kalanı metodoloji sayfasında.

Tek yerden alınmış tek örnek bir anlık görüntü, ortalama değil. Senin ölçtüğün sayı çok iyi ya da çok kötü olabilir ve ikisi de dürüst olabilir:

Tarama 2.400 ms, sen 200 ms görüyorsan genelde sen sıcak önbelleğe denk gelmişsindir, biz gelmemişizdir. Bu yine de bazı gerçek ziyaretçilerin ve botların yavaş sürümü aldığı anlamına gelir.

Kendin ölç

curl aşamaları ayrı ayrı verir. Değerler baştan itibaren birikerek sayılır; yani ttfb zaten DNS, bağlantı ve TLS süresini içerir. Arka arkaya üç kez çalıştır:

$ for i in 1 2 3; do curl -s -o /dev/null -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n' https://ornekblog.com/; done
dns 0.014  connect 0.052  tls 0.109  ttfb 2.318  total 2.402
dns 0.001  connect 0.038  tls 0.093  ttfb 0.204  total 0.251
dns 0.001  connect 0.037  tls 0.090  ttfb 0.196  total 0.243

Bu örnek çıktı tipik önbellek desenini gösteriyor: ilk istek sayfayı üretti (yaklaşık 2,2 sn sunucu süresi), sonraki ikisi önbellekten geldi. Üçü de yavaşsa bu adres için çalışan bir önbellek hiç yok demektir.

Chrome DevTools'ta Network panelini aç, sayfayı yenile, belge isteğine tıkla ve Timing sekmesine geç. Chrome'un "Waiting for server response" dediği satır (eski sürümlerde "Waiting (TTFB)") sunucunun düşünme süresi artı bir gidiş-dönüş.

Gerçek kullanıcı verisi için PageSpeed Insights, Chrome'da yeterli veri varsa TTFB'yi saha verileri bölümünde "the experimental metric Time to First Byte (TTFB)" olarak gösteriyor; 800 ms ve altı iyi, 1.800 ms üstü kötü (PSI belgeleri). Yeni sitelerde çoğu zaman saha verisi henüz olmuyor.

Google tarafını görmek için Search Console'da Ayarlar → Tarama istatistikleri raporu, sitenden çekilen tüm kaynakların ortalama yanıt süresini gösteriyor (Tarama İstatistikleri). Görseller, betikler ve sayfalar karışık olduğu için mutlak değere değil eğilime bak. Ücretsiz Googlebot erişim kontrolü aracımız ana sayfanı tarayıcı, telefon, Googlebot, Mediapartners-Google ve AdsBot olarak çeker ve her biri için toplam yanıt süresini gösterir. Google satırları tarayıcı satırından sürekli belirgin şekilde yavaşsa, bir şey botlara farklı davranıyor.

Önbellek gerçekten devrede mi?

Bir şey değiştirmeden önce yanıt başlıklarını oku:

$ curl -sI https://ornekblog.com/ | grep -iE '^(cache-control|set-cookie|age|cf-cache-status|x-nextjs-cache)'
cache-control: no-cache, must-revalidate, max-age=0
set-cookie: PHPSESSID=8f2c41d0a7; path=/
cf-cache-status: DYNAMIC

Üç satırda üç sorun. no-cache önbelleklere sayfayı yeniden kullanmamalarını söylüyor, anonim ziyaretçiye verilen oturum çerezi genelde önbelleği durduruyor, Cloudflare'in DYNAMIC cevabı da isteğin önbelleğe uygun bulunmadığı ve önbelleğe hiç bakılmadan sunucuya gittiği anlamına geliyor (Cloudflare önbellek durumları). İkinci istekte görmek istediğin şey HIT ya da sayfa önbelleğinin kendi "hit" başlığı.

Sonra önbelleklerin sık atladığı durumları dene: giriş yapmış kullanıcı çerezine benzeyen bir çerez ekle (-H 'Cookie: wordpress_logged_in_test=1'), adrese ?utm_source=test ekle ve isteği bir de -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' ile tekrarla. Hangi varyant sürekli yavaşsa önbelleğinin kapsamadığı yol odur.

Düzeltmeler, bizim baktığımız sırayla

1. Sayfa önbelleğini aç. WordPress belgeleri sayfa önbelleğini, yazıları "as static files" olarak sunmak diye tarif ediyor ve oldukça sabit sayfalarda performansı yüzlerce kat artırabileceğini söylüyor (WordPress önbellek). Hostingin hazır bir önbellek sunuyorsa onu, sunmuyorsa tek bir önbellek eklentisini kullan. İki tane değil: aynı sitede iki sayfa önbelleğinin sorununu ayıklamak zor.

2. CDN'in HTML'i önbelleğe almasına izin ver. "The Cloudflare CDN does not cache HTML or JSON by default" (varsayılan önbellek davranışı); yani Cloudflare'de olmak tek başına TTFB'yi hızlandırmıyor. Eligible for cache seçili bir Cache Rule bunu değiştirebilir. Ama Cloudflare varsayılan olarak Set-Cookie taşıyan yanıtı önbelleğe almaz; giriş yapmış kullanıcılar, sepet ve yönetim yolları için de önbelleği atlaman gerekir. Bu riskli geliyorsa sunucudaki sayfa önbelleğine güven. Aynı paneldeki güvenlik duvarı ayarları için Cloudflare ve AdSense engeli rehberine bak.

3. Gereksiz önbellek atlamalarını kapat. Her ziyaretçiye çerez yazan bir eklenti, bot kullanıcı aracılarını içeren bir "önbelleğe alma" listesi ya da kendini Googlebot diye tanıtan her isteğe ekstra iş yapan bir güvenlik katmanı, istekleri yavaş şeride iter.

4. Yavaş eklentiyi ya da sorguyu bul. Boştaki sunucuda bile önbelleksiz istekler yavaşsa iş kendisi ağırdır. Bir test kopyasında eklentileri tek tek kapatıp her seferinde önbelleksiz bir isteği ölç ya da hangi bileşenin en çok veritabanı sorgusu çalıştırdığını gösteren bir sorgu profilleme eklentisi kullan. WordPress tarafındaki diğer temizlik için WordPress ile AdSense onayı rehberine bak.

5. PHP'yi güncelle. WordPress "PHP version 8.3 or greater" öneriyor ve eski sürümlerin resmi destek ömrünün bittiğini hatırlatıyor (gereksinimler). Geçiş genelde hosting panelinde bir açılır menü; önce test kopyasında dene.

6. Okura yaklaş ya da araya önbellek koy. web.dev'in TTFB rehberi hostingle başlıyor, paylaşımlı hostingin genelde daha yavaş olduğunu belirtiyor ve CDN'lerin kaynakları "on servers that are physically closer to your users" sakladığını anlatıyor (TTFB'yi iyileştirme). Okurlarının çoğu Türkiye'deyse ve sunucu başka bir kıtadaysa, önbelleksiz her istek bu mesafenin bedelini öder.

7. Next.js: mümkünse statik üret. Bir rota cookies(), headers() ya da searchParams gibi istek anı API'lerini kullandığında dinamik hâle gelir. next build çıktısı her rotayı ○ (Static) ya da ƒ (Dynamic) diye işaretler. Seyrek değişen bir blog yazısı için zamana bağlı yenileme sayfayı statik tutar:

// app/blog/[slug]/page.tsx
export const revalidate = 3600 // en fazla saatte bir yeniden üret

Cache Components açıksa karşılığı 'use cache' ile birlikte cacheLife('hours'). x-nextjs-cache başlığı HIT, STALE, MISS ya da REVALIDATED döner; önbelleğin cevap verip vermediğini buradan görürsün.

Sıkıştırma ve HTML ağırlığı

Bunlar TTFB'nin kendisini değiştirmez ama ilk bayttan hemen sonra olanları belirler.

Sıkıştırmayı, sıkıştırma teklif eden bir istekle kontrol et:

$ curl -sI -H 'Accept-Encoding: gzip, deflate, br' https://ornekblog.com/ | grep -i '^content-encoding'
content-encoding: br

content-encoding satırı yoksa HTML sıkıştırılmadan gitmiş demektir. Google'ın botları gzip, deflate ve Brotli (br) destekliyor (Google tarayıcıları). Bizim taramamız yalnızca gzip ve deflate teklif ediyor; Brotli ile sıkıştırıp gzip yedeği olmayan bir sunucu bu yüzden işaretlenir. Brotli'nin yanında gzip'i de açmak hem bizim için hem eski istemciler için sorunu çözer.

Boyut tarafında Googlebot "crawls the first 2MB of a supported file type" ve bu sınır sıkıştırılmamış veriye uygulanıyor (Googlebot). Bizim 1 MB'lık seo.html_size notumuz erken uyarı niyetinde. Sık görülen sebepler: HTML'e base64 olarak gömülmüş görseller, satır içi SVG ikon setleri, sayfa oluşturucunun her blokta tekrarlanan işaretlemesi ve 50 yazının tamamını listeleyen bir ana sayfa. Ana sayfayı sayfalara böl, gömülü dosyaları ayrı dosyalara taşı.

Önbellek ve sıkıştırma yerine oturduğunda ücretsiz tarama ana sayfayı bizim tarafımızdan yeniden ölçer, karşılaştırabilirsin.

Sık sorulan sorular

AdSense onayı için TTFB kaç olmalı?

Yayımlanmış bir sayı yok. Gerçek ziyaretçiler için web.dev'in 0,8 saniyesini hedefle ve sitenin hiç zaman aşımına düşmediğinden emin ol. Approvalens 1,5 saniyenin üstünü uyarı, 3,5 saniyenin üstünü kritik sayar.

Hosting firmam sunucunun hızlı olduğunu söylüyor. TTFB neden yavaş?

Çoğu zaman darboğaz donanım değil. Her istekte PHP açılıyor, bütün eklentiler yükleniyor ve veritabanı sorgulanıyorsa hızlı sunucu da zaman harcar. Farkı görmek için curl ile önbellekli ve önbelleksiz bir isteği karşılaştır.

Cloudflare bütün HTML'imi önbelleğe almalı mı?

Ancak giriş yapmış kullanıcılar, onay bekleyen yorumlar, sepet ve yönetim yolları için önbelleği atlıyorsan ve anonim ziyaretçiye hiçbir şey çerez yazmıyorsa. Yoksa ziyaretçiler başkası için üretilmiş sayfaları görebilir. İlk adım olarak sunucudaki sayfa önbelleği daha güvenli.

CDN tek başına TTFB'yi düzeltir mi?

HTML için, CDN onu önbelleğe alacak şekilde ayarlanmadıysa hayır. Görseller, CSS ve JavaScript varsayılan olarak faydalanır; HTML belgesi yine her seferinde senin sunucundan gelir.