Time to First Byte değeriniz neden yavaş ve bunun için ne yapmalı

TTFB’nin gerçekte ne ölçtüğüyle başlayın

Genellikle TTFB olarak kısaltılan Time to First Byte, tarayıcının bir kaynak istemesi ile yanıtın ilk baytını alması arasındaki süredir.

Bu bir sunucu metriği gibi görünür, ancak yalnızca bir sunucu metriği değildir. TTFB birkaç adımı içerir:

• Hostname zaten çözümlenmemişse DNS araması
• TCP bağlantı kurulumu
• HTTPS için TLS müzakeresi
• İsteğin sunucuya veya CDN edge’e gidiş süresi
• Sunucuda kuyruğa alınma ve işlenme
• Yanıtın tarayıcıya geri dönüş süresi

Bu nedenle yüksek TTFB, backend’inizin yavaş olduğu anlamına gelebilir. Aynı zamanda kullanıcının origin’den uzak olduğu, CDN’inizin yanlış yapılandırıldığı, cache’inizin sürekli miss verdiği veya sunucunuzun ne göndereceğine karar vermek için fazla zaman harcadığı anlamına da gelebilir.

Bu önemlidir çünkü TTFB yükleme zincirinin başlangıcına yakındır. HTML belgesi geç gelirse tarayıcı CSS, JavaScript, font ve görselleri de geç keşfeder. Mükemmel front-end optimizasyonunuz olabilir; ancak ilk belge yanıtı 1,5 saniye sürüyorsa site yine de yavaş hissedilir.

Yavaş TTFB için sınır nedir?

Her siteye, bölgeye ve mimariye uyan evrensel bir sayı yoktur. Yine de pratik eşikler yardımcı olur.

Google’ın web.dev rehberi, iyi bir TTFB’yi 800 ms altı olarak sınıflandırır; 800–1800 ms iyileştirme gerektirir, 1800 ms üzeri ise zayıf kabul edilir. Kullanıcıya yakın sunulan ve iyi cache’lenen bir pazarlama sayfasında çoğu zaman bundan çok daha iyisini yapabilirsiniz. Dinamik iş yapan karmaşık, kimliği doğrulanmış bir dashboard için kabul edilebilir sayı daha yüksek olabilir, ancak yine de açıklanabilir olmalıdır.

Önemli alışkanlık, sayıyı segmentlere ayırmaktır. 900 ms’lik global ortalama TTFB, CDN edge’inize yakın kullanıcılar için 150 ms’lik bir yanıtı ve başka bir bölgedeki kullanıcılar için 2200 ms’lik bir yanıtı gizleyebilir. Benzer şekilde ana sayfanız iyi olabilirken arama, kategori veya oturum açılmış sayfalar sessizce acı verici olabilir.

Birden fazla yerden ölçün

TTFB’yi tek bir Lighthouse çalıştırmasına göre teşhis etmeyin. Lighthouse faydalıdır, ancak tek bir ortamdan yapılan tek bir testtir. Yorumlamaya yeni başlıyorsanız, paniğe kapılmadan bir Lighthouse raporunun nasıl okunacağına dair sakin bir okumayla başlayın — ana ders, lab sinyallerini saha gerçekliğinden ayırmaktır.

TTFB için en az üç görünüme ihtiyacınız vardır:

1. Tarayıcı geliştirici araçları

Network panelini açın, cache devre dışıyken yeniden yükleyin ve ana belge isteğini inceleyin. Zamanlama kırılımı DNS, bağlantı, TLS, bekleme ve indirme aşamalarını gösterir. “Bekleme” aşaması çoğu kişinin backend süresi derken kastettiği şeydir; ancak upstream latency’yi de içerebilir.

2. Birden çok bölgeden sentetik testler

Kullanıcılarınıza yakın ve uzak konumlardan testler çalıştırın. TTFB bir bölgede düşük, başka bir bölgede yüksekse uygulama kodunu yeniden yazmadan önce coğrafyadan, CDN yönlendirmesinden, origin konumundan veya cache kapsamından şüphelenin.

3. Gerçek kullanıcı izleme veya sunucu logları

Saha verisi, gerçek kullanıcıların cihazlar, ağlar ve oturumlar genelinde ne deneyimlediğini söyler. Sunucu logları ise origin’in bir yanıtı hızlı üretip üretmediğini gösterebilir. İstemci tarafından gözlemlenen TTFB ile origin işleme süresi arasındaki fark, çoğu zaman CDN ve ağ sorunlarının ortaya çıktığı yerdir.

Yavaş TTFB’nin olağan nedenleri

HTML’iniz cache’lenmiyor

Bu, içerik sitelerinde ve ecommerce sitelerinde en yaygın sorundur. Statik asset’ler agresif biçimde cache’lenir; ancak tarayıcının önce ihtiyaç duyduğu şey olan HTML belgesi her istekte yeniden üretilir.

Bazen bu gereklidir. Çoğu zaman değildir.

Herkese açık bir sayfa günde birkaç kez değişiyorsa, muhtemelen her anonim ziyaretçi için taze bir veritabanı render’ı gerektirmemelidir. Uygun yerlerde full-page caching, edge caching, static generation veya stale-while-revalidate desenlerini kullanın.

Yanıt header’larında Cache-Control, CDN-Cache-Status, Age, Vary ve Set-Cookie gibi sinyalleri kontrol edin. Her ziyaretçiye benzersiz cookie gönderen bir sayfa, yanlışlıkla kendini cache’lenemez hâle getirebilir. Bu katmanı anlamlandırmak için pratik bir yola ihtiyacınız varsa, production’da redirect ve HTTP header’larını debug etme rehberimizdeki aynı debug alışkanlıkları doğrudan TTFB çalışmasına uygulanır.

CDN’iniz yalnızca asset’leri cache’liyor

Birçok ekip bir CDN ekler ve performans işinin bittiğini varsayar. Ancak CDN yalnızca görselleri, CSS’i ve JavaScript’i sunuyorsa, ilk HTML isteği hâlâ tek bir origin sunucuya kadar gidebilir.

Yerel kullanıcıları olan yerel bir işletme sitesi için bu sorun olmayabilir. Uluslararası bir kitle için değildir. Kullanıcı origin’den ne kadar uzaktaysa, backend işi daha başlamadan o kadar fazla latency ödersiniz.

TTFB için iyi CDN yapılandırması genellikle şunları gerektirir:

• Güvenli olduğu yerlerde herkese açık HTML’i cache’lemek
• Kimliği doğrulanmış veya kişiselleştirilmiş sayfalar için kasıtlı bypass kurallarına saygı göstermek
• Cache’i gereğinden fazla bölen gereksiz Vary header’larından kaçınmak
• Cache’i tamamen devre dışı bırakmak yerine cache purging veya revalidation kullanmak
• Edge konumlarının her isteği iletmek yerine gerçekten hit sunduğunu doğrulamak

CDN sihir değildir. Bir cache ve yönlendirme katmanıdır. Ona öyle davranın.

Sunucunuz yanıt vermeden önce çok fazla iş yapıyor

Yavaş bir backend yolu birçok küçük gecikmeden kaynaklanabilir: veritabanı sorguları, API çağrıları, template rendering, feature flag kontrolleri, kimlik doğrulama, kişiselleştirme, loglama ve cold start’lar.

En kötü desen, seri bağımlılık işidir. Örneğin:

1. Sayfa verisini al
2. Sonra ilgili ürünleri al
3. Sonra fiyatlandırmayı al
4. Sonra bir öneri servisini çağır
5. Sonra HTML’i render et

Her adım bir öncekini beklerse TTFB hızla büyür. Bağımsız işleri paralelleştirin, kritik olmayan çağrıları ilk yanıttan çıkarın ve maliyetli sonuçları cache’leyin.

Faydalı bir kural: Kullanıcı sonucu hemen göremiyor veya kullanamıyorsa, muhtemelen ilk baytı bloklamamalıdır.

Veritabanı sorguları yavaş veya öngörülemez

Veritabanları sık sık TTFB sorunlarına neden olur çünkü development ortamında iyi, gerçek trafik altında kötü davranırlar. Eksik index’ler, büyük join’ler, N+1 sorguları, lock contention ve aşırı büyük sonuç kümeleri “sunucu yavaş” olarak görünür.

Burada tahmin etmeyin. Yavaş istekler için sorgu sürelerini yakalayın. Yalnızca ortalamalara değil, p95 ve p99’a bakın. Genellikle 120 ms’de yanıt veren ama ara sıra 4 saniye bloklanan tek bir sayfa bile kötü kullanıcı deneyimi yaratır.

Yaygın düzeltmeler şunlardır:

• Index eklemek veya düzeltmek
• N+1 sorgu desenlerini kaldırmak
• Okuma ağırlıklı veriyi cache’lemek
• Büyük sorguları sayfalara bölmek
• Raporlama veya analytics sorgularını request time’dan uzaklaştırmak
• Downstream çağrılar için makul timeout’lar belirlemek

Uygulamanızda cold start’lar var

Serverless ve containerized platformlar mükemmel olabilir, ancak trafik patlamalı olduğunda veya bölgeler yetersiz provision edildiğinde cold start’lar TTFB’ye zarar verebilir.

Boşta kalma süresinden sonraki ilk isteğiniz sonraki isteklerden çok daha yavaşsa, cold start’ları araştırın. Latency’ye duyarlı route’lar için provisioned concurrency, daha küçük bundle’lar, daha az başlangıç bağımlılığı, daha sıcak function’lar veya farklı bir deployment şekli gerekebilir.

Bu serverless’a karşı bir argüman değildir. Runtime modelinin görünmez olduğunu varsaymaya karşı bir argümandır.

Redirect’ler ilk isteği boşa harcıyor

Redirect, tarayıcı nihai belgeyi almadan önce başka bir request-response döngüsü ekler. Eski linkler için http://’den https://’ye tek bir redirect kaçınılmaz olabilir, ancak zincirler israftır.

Yaygın zincirler şunları içerir:

• http://example.com → https://example.com → https://www.example.com
• protokol normalizasyonundan sonra trailing slash normalizasyonu
• cache lookup’tan önce geo veya dil redirect’leri
• birkaç URL üzerinden sıçrayan eski kampanya linkleri

Mümkün olduğunda kaynak linkleri düzeltin, redirect kurallarını birleştirin ve canonical URL’leri doğrudan yapın. Redirect süresi nihai istek için her zaman TTFB olarak raporlanmayabilir, ancak kullanıcı yine de bunun bedelini öder.

Pratik bir debug sırası

TTFB yavaş göründüğünde bu sırayı kullanın. Bu, cache ve yönlendirme davranışını doğrulamadan uygulama kodunu optimize etme şeklindeki yaygın hatadan kaçınır.

Step 1: Tüm sayfayı değil, ana belgeyi test edin

HTML belgesinin isteğini bulun. Toplam TTFB’yi ve zamanlama kırılımını kaydedin. Tarayıcı cache’i ile ve cache olmadan tekrarlayın. İlgiliyse herkese açık bir sayfayı, dinamik bir sayfayı ve oturum açılmış bir sayfayı test edin.

Step 2: Bölgeleri karşılaştırın

Aynı URL’yi birkaç coğrafi konumdan çalıştırın. Yavaş bölgeler origin’e olan mesafeyle ilişkiliyse CDN ve edge caching’e öncelik verin. Her bölge yavaşsa backend işleme ve origin kapasitesine bakın.

Step 3: Yanıt header’larını inceleyin

Cache header’larını, cookie’leri, Age değerini, CDN durumunu ve Vary değerini arayın. Eksik Age header’ı veya tekrarlanan cache miss’leri ipucudur. Herkese açık HTML’de geniş bir Vary: Cookie header’ı çoğu zaman cache katilidir.

Step 4: Origin zamanlamasını kontrol edin

Server timing instrumentation ekleyin. Server-Timing header’ı veritabanı süresi, render süresi ve upstream API süresi gibi backend aşamalarını açığa çıkarabilir. Basit etiketler bile faydalıdır:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

Artık tarayıcı zamanlamalarınız, sunucunun gerçek iş için 300 ms harcayıp harcamadığını veya gecikmenin isteğiniz uygulamanıza ulaşmadan önce mi yaşandığını gösterebilir.

Step 5: Doğrulanmış en büyük gecikmeyi düzeltin

Bu kulağa bariz gelir, ancak ekipler çoğu zaman ölçülmüş olanı değil, aşina oldukları şeyi düzeltir. Cache miss’leri baskınsa caching’i düzeltin. Veritabanı baskınsa sorguları düzeltin. Global kullanıcılar için TLS ve bağlantı kurulumu baskınsa yönlendirmeyi, CDN kapsamını veya origin coğrafyasını düzeltin.

Front-end işi hâlâ önemlidir. Fontlar, görseller ve JavaScript, HTML geldikten sonra ne olacağını etkiler. Ancak hızlı bir ilk yanıtın yerine geçmezler. Render performansı üzerinde de çalışıyorsanız, web fontları birçok sitede hâlâ en kolay kazanımlardan biridir çünkü belge geldikten sonra metnin ne kadar hızlı kullanılabilir hâle geldiğini etkilerler.

Genellikle işe yarayan düzeltmeler

Herkese açık HTML’i edge’de cache’leyin

Pazarlama sayfaları, dokümantasyon, bloglar, landing page’ler ve kategori sayfaları için edge caching çoğu zaman en büyük TTFB iyileştirmesidir. İçerik sık değişiyorsa kısa TTL’ler kullanın. Cache arka planda yenilenirken biraz stale içerik kabul edilebiliyorsa stale-while-revalidate kullanın.

Kişiselleştirmeye dikkat edin. Bir sayfa para birimine, dile, login durumuna veya experiment grubuna göre değişiyorsa bu varyantları açıkça tanımlayın. Yanlışlıkla oluşan kullanıcı başına varyasyon cache verimliliğini yok eder.

Kritik olmayan işi request path’in dışına taşıyın

E-posta gönderimi, analytics zenginleştirme, öneri üretimi, webhook çağrıları ve ağır loglama ilk baytı nadiren bloklamalıdır. Bunları queue’lara koyun veya yanıt başlatıldıktan sonra çalıştırın.

Backend bağımlılık zincirlerini azaltın

Bağımsız çağrıları paralelleştirin. Yavaş API’lerden gelen yanıtları cache’leyin. Timeout’lar belirleyin. Faydalı ama zorunlu olmayan servisler için fallback içerik tasarlayın.

Yavaş bir öneri widget’ı tüm ürün sayfasını geciktirmemelidir.

Compute’u kullanıcılara yaklaştırın

Kullanıcılarınız global ve origin’iniz tek bir bölgedeyse latency yapısaldır. CDN caching, herkese açık içerik için bunun büyük bölümünü gizleyebilir. Dinamik içerik için bölgesel deployment’ları, uygun route’lar için edge rendering’i veya API’leri kitleye yaklaştırmayı değerlendirin.

Redirect’leri sıkıcı tutun

URL’leri tek hop’ta canonicalize edin. Kullanıcıların ve crawler’ların doğrudan nihai hedefe gitmesi için internal link’leri güncelleyin. Eski kampanya URL’lerini ve platform migration’larını denetleyin. Redirect’ler çalıştığında görünmez oldukları için kolayca göz ardı edilir, ancak yine de zaman maliyeti yaratırlar.

Ne yapmamalı

Her route için mükemmel bir TTFB sayısının peşinden koşmayın. Gerçek hesaplama yapan kimliği doğrulanmış bir rapor, cache’lenmiş bir blog yazısı gibi davranmaz.

Ortalama TTFB’yi tek metriğiniz olarak kullanmayın. Percentile’lar önemlidir. Coğrafya önemlidir. Sayfa tipi önemlidir.

CDN’in HTML’inizi cache’lediğini varsaymayın. Doğrulayın.

Ve TTFB’yi ürün kararlarından ayrı ele almayın. Kişiselleştirme, experimentation, gerçek zamanlı inventory ve üçüncü taraf servislerin hepsinin latency maliyetleri vardır. Bazıları buna değer. Bazıları yalnızca alışkanlıktır.

<!-- tool-cta:start -->

💡 Bunu deneyin: TTFB’yi teşhis ederken, Get Headers önbellek durumunu, sunucu zamanlamalarını ve gecikmenin nereden kaynaklandığını sıkça açıklayan yönlendirmeleri ortaya çıkarır.

<!-- tool-cta:end -->

Planın sakin versiyonu

Yavaş TTFB, onu belirsiz bir “sunucu problemi” olarak ele almayı bıraktığınızda genellikle düzeltilebilir. Belge isteğini ölçün. Bölgeye ve sayfa tipine göre segmentlere ayırın. Header’ları inceleyin. İstemci zamanlamasını origin zamanlamasıyla karşılaştırın. Sonra doğrulanmış en büyük darboğazı düzeltin.

Çoğu sitenin egzotik mimariye ihtiyacı yoktur. Daha az kaçınılabilir cache miss’e, daha az bloklayan backend işine, daha temiz redirect’lere ve ilk bayt gönderilmeden önce neyin mutlaka olması gerektiğine dair daha net bir fikre ihtiyaçları vardır.