TTFB Optimizasyonu 2026: Sunucu Yanıt Süresini LCP İçin Düşürmenin Tam Rehberi

TTFB (Time to First Byte — İlk Bayta Kadar Geçen Süre), tarayıcının bir HTTP isteği gönderdikten sonra sunucudan ilk yanıt baytını alana kadar geçen süreyi ölçer. Bu süre, Core Web Vitals'ın kritik bir bileşeni olan LCP için doğrudan bir tavan oluşturur: tarayıcı ilk baytı almadan hiçbir öğeyi render edemeyeceği için TTFB ne kadar yüksekse LCP o kadar geç başlayabilir.

TTFB yüksek olan bir sayfada LCP hedefini tutturmak matematiksel olarak güçleşir. Bu makalede TTFB'nin neden yükseldiği, her alt bileşenin nasıl tanılandığı ve uygulama katmanından CDN yapılandırmasına kadar hangi tekniklerle düşürülebileceği ele alınmaktadır. LCP optimizasyonunun diğer boyutları için ayrı bir rehbere de başvurabilirsiniz.

TTFB'nin Anatomisi ve CWV ile İlişkisi

Bir tarayıcının HTTP isteği gönderip ilk yanıt baytını almasına kadar geçen süre dört ayrı aşamadan oluşur:

1. DNS Çözümleme: Alan adının IP adresine dönüştürülmesi. Önbelleklenmiş sorguların yanıt süresi birkaç milisaniyedir; soğuk çözümleme onlarca milisaniyeye ulaşabilir.
2. TCP Bağlantı Kurulumu: İstemci ile sunucu arasında üç aşamalı el sıkışma (three-way handshake). Her gidiş-dönüş, iki uç nokta arasındaki RTT (Round Trip Time) kadar sürer.
3. TLS El Sıkışması: HTTPS bağlantılarında şifreleme parametrelerinin pazarlığı. TLS 1.3 bu aşamayı tek bir gidiş-dönüşe indirir; önceki sürümler iki gidiş-dönüş gerektirir.
4. Sunucu İşleme Süresi: Sunucunun isteği alıp yanıtın ilk baytını oluşturana kadar geçirdiği süre. Veri tabanı sorguları, kimlik doğrulama, şablonlama ve harici servis çağrıları bu süreye dahildir.

Tarayıcı bu dört aşamayı sırayla tamamladıktan sonra HTML'nin ilk baytını alır. LCP öğesi çoğunlukla bu HTML içindeki bir URL'den yüklenir; dolayısıyla TTFB ne kadar büyükse LCP o kadar geç başlayabilir. TTFB, tüm sonraki yükleme metriklerinin temelidir ve buradaki her milisaniye doğrudan LCP süresine yansır. Bu dört bileşenden en fazla iyileştirme payı, çoğu web uygulamasında sunucu işleme süresindedir — ve bu bileşen tamamen uygulama kontrolündedir.

TTFB'yi Doğru Ölçmek ve Tanılamak

TTFB'yi ölçmek için iki farklı veri kaynağı kullanılır: laboratuvar verileri (sentetik ölçümler) ve alan verisi (gerçek kullanıcı ölçümleri). Her ikisi de farklı soruları yanıtlar; birini diğerinin yerine kullanmak yanıltıcı sonuçlara yol açar.

Laboratuvar Ölçümleri

Chrome DevTools'un Network panelinde herhangi bir belge isteğine tıklayarak Timing sekmesine geçildiğinde TTFB'nin her alt bileşeni ayrı ayrı görüntülenebilir. “Waiting for server response” satırı, sunucu işleme süresini yansıtır; “Initial connection” satırı ise TCP/TLS kurulumunu gösterir. Lighthouse da sunucu yanıt süresi denetimi ile bu değeri raporlar.

Alan Verisi ile TTFB Ölçümü

Gerçek kullanıcı verisinde TTFB, Navigation Timing API üzerinden okunabilir:

const [entry] = performance.getEntriesByType('navigation');
const ttfb = entry.responseStart - entry.startTime;
console.log('TTFB:', ttfb, 'ms');

Bu değeri RUM altyapınıza göndererek URL bazında, coğrafyaya göre veya ağ türüne göre parçalayabilirsiniz. Hangi sayfalarda ya da hangi kullanıcı segmentlerinde TTFB'nin yüksek olduğunu anlamak, optimizasyon önceliklerini belirlemenin en güvenilir yoludur.

Server-Timing ile Alt Bileşen Atfı

TTFB yüksek çıktığında sorunun sunucu işleme süresinden mi yoksa ağ gecikmesinden mi kaynaklandığını anlamak için Server-Timing HTTP başlığını kullanabilirsiniz. Sunucu yanıtına şu biçimde bir başlık eklenebilir:

Server-Timing: db;dur=42, render;dur=18, cache;desc="miss"

Bu başlıklar DevTools'un Timing sekmesinde ve Navigation Timing API'de serverTiming dizisi olarak görünür. Böylece veritabanı sorgusunun mu, şablonlamanın mı yoksa harici bir servis çağrısının mı TTFB'yi şişirdiğini gerçek kullanıcı verisiyle doğrulayabilirsiniz. Tanılama olmadan yapılan optimizasyon kör bir çabaya dönüşür; önce ölçün.

Uygulama Katmanı Optimizasyonları

Sunucu işleme süresi genellikle TTFB'nin en büyük ve en düzeltilebilir payıdır. Buradaki kazanımlar önbellekten, veritabanından ve uygulama mimarisinden gelir.

Tam Sayfa Önbelleği

Kimliği doğrulanmamış kullanıcılara veya kişiselleştirilmemiş içeriğe hizmet eden sayfalar için tam sayfa önbelleği en etkili yöntemdir. Sunucu, ilk istekte sayfayı oluşturur ve sonucu önbelleğe (bellek veya disk) yazar; sonraki istekler için oluşturma sürecini tamamen atlar. Bu yaklaşımda sunucu işleme süresi neredeyse sıfıra iner çünkü yanıt hazır hâlde bekliyordur.

Sık değişen sayfalar için Cache-Control: stale-while-revalidate yönergesi, eski içeriği gösterirken arka planda önbelleği yeniler. Kullanıcı hiçbir zaman yüksek TTFB'ye maruz kalmaz; bir sonraki istek geldiğinde önbellek zaten güncellenmiş olur.

Nesne Önbelleği ve Veritabanı Sorgu Optimizasyonu

Sayfa önbelleğinin mümkün olmadığı dinamik, kişiselleştirilmiş sayfalarda dikkat veritabanına çevrilmelidir. Yaygın pratikler şunlardır:

• Sorgu önbelleği: Sık çalıştırılan, az değişen sorguların sonuçlarını Redis veya Memcached gibi bellek içi depolarda tutmak; veritabanına yapılan gidişlerin sayısını azaltır.
• N+1 sorgu tespiti: ORM'lerin sıklıkla ürettiği bu deseni tespit edip tekli JOIN veya toplu yükleme (eager loading) ile değiştirmek, liste sayfalarında onlarca gereksiz sorguyu ortadan kaldırır.
• Bağlantı havuzu (connection pooling): Her istek için yeni bir veritabanı bağlantısı açmak gecikme ekler; kalıcı bağlantı havuzları bu maliyeti tekrarlayan istekler için sıfıra indirir.
• Yavaş sorgu izleme: Veritabanı yavaş sorgu günlükleri ile uzun süren sorgular belirlenir; eksik indeksler eklenerek sorgu planı iyileştirilir.

Streaming HTML ile Aşamalı Gönderim

Geleneksel sunucu taraflı render yaklaşımında sunucu sayfayı tamamen oluşturduktan sonra gönderir. Streaming HTML ise sayfanın <head> bölümünü ve üst kısımdaki HTML'yi hazır olur olmaz gönderir; dinamik içerik hazırlanmaya devam ederken tarayıcı bu bölümü alıp harici kaynakları (CSS, fontlar, kritik görseller) indirmeye başlayabilir. Node.js'te bu yaklaşım şu biçimde uygulanabilir:

app.get('/urun/:id', async (req, res) => {
  res.setHeader('Content-Type', 'text/html; charset=utf-8');
  res.setHeader('Transfer-Encoding', 'chunked');

  // head bölümünü ve kritik kaynak ipuçlarını hemen gönder
  res.write(buildHead());

  // Veri tabanı sorgusunu beklerken tarayıcı kaynakları yükler
  const urun = await db.getUrun(req.params.id);

  res.end(renderBody(urun));
});

Bu yaklaşım ağ TTFB'sini değiştirmez; ancak tarayıcının bekleme süresini üretken bir faaliyet olan kaynak indirmeye dönüştürür. LCP öğesinin keşfedilip indirilmeye başlanması öne kayar ve bu, LCP puanını doğrudan olumlu etkiler.

CDN ve Edge Yapılandırması

CDN (İçerik Dağıtım Ağı), statik kaynakları kullanıcıya yakın sunucularda önbelleğe almanın ötesinde HTML belgeleri için de TTFB'yi düşürebilir. Kritik nokta, CDN'nin yalnızca resim ve JavaScript gibi statik dosyalar için değil, HTML belgesi için de yapılandırılmasıdır.

HTML Belgelerini CDN'de Önbelleğe Almak

Kimliği doğrulanmamış kullanıcılara yönelik sayfalar uygun Cache-Control başlıkları ile CDN'de önbelleğe alınabilir. CDN bu sayfaları kullanıcıya yakın kenar düğümünden (edge node) sunar; TTFB'deki ağ bileşeni köke yapılan tam bir gidiş-dönüş yerine kenar düğümüne olan çok daha kısa bir mesafeye iner. Ticari CDN'lerin büyük çoğunluğu bu özelliği farklı isimler altında sunar.

CDN'de Dinamik İçerik Stratejileri

Kişiselleştirilmiş yanıtlar CDN'de olduğu gibi önbelleğe alınamaz; ancak şu iki yaklaşım bu kısıtlamayı aşmaya yardımcı olur:

• Kenar fonksiyonları (edge functions): Bazı CDN platformları, çerezlerden kullanıcı tercihlerini okuyup önbelleğe alınmış bir yanıta enjekte edebilen kenar fonksiyonları sunar. Gerçek uygulama sunucusuna bağlanmaya gerek kalmadan kişiselleştirilmiş içerik sunmak bu yolla mümkün olur.
• Parçalı önbelleğe alma (fragment caching): Sayfanın kişiselleştirilmemiş bölümleri CDN'de önbelleğe alınırken kişiselleştirilmiş bileşenler istemci tarafında asenkron yüklenir. Bu sayede sayfanın çoğunluğu ağ kenarından, düşük TTFB ile sunulur.

Coğrafi Dağılım ve PoP Seçimi

CDN seçiminde, hizmet verilen kullanıcı kitlesinin coğrafi dağılımı ile CDN'nin PoP (Point of Presence — Varlık Noktası) konumları eşleştirilmelidir. Kullanıcılarınızın yoğun olduğu bölgelerde PoP'ları bulunan bir CDN, ağ kaynaklı TTFB bileşenini belirgin biçimde kısaltır. CrUX verisi ile ülke bazında P75 TTFB'yi gözlemleyerek hangi coğrafyalarda yüksek gecikme olduğunu belirleyebilir ve CDN seçimini bu verilere dayandırabilirsiniz.

Protokol Düzeyinde Optimizasyonlar

Uygulama ve CDN katmanlarının yanı sıra ağ protokolü seçimi de TTFB'nin bağlantı kurulum bileşenini etkiler. Bu optimizasyonlar genellikle yapılandırma değişikliklerinden ibaret olduğundan uygulama kodu değiştirmeden devreye alınabilir.

TLS 1.3

TLS 1.3, önceki sürümlerin iki gidiş-dönüş gerektirdiği el sıkışmasını tek bir gidiş-dönüşe indirir. Sıfır gidiş-dönüşlü yeniden bağlantı (0-RTT) özelliği, daha önce bağlanmış istemcilerin ilk isteği el sıkışmadan göndermesine olanak tanır. Modern sunucu yazılımlarının büyük çoğunluğu TLS 1.3'ü destekler; sunucu ve CDN yapılandırmanızı kontrol ederek etkin olduğundan emin olabilirsiniz.

HTTP/2 ve HTTP/3

HTTP/2, tek bir TCP bağlantısı üzerinden çoklu akış (multiplexing) sağlayarak birden fazla kaynağın eş zamanlı alınmasına olanak tanır ve bağlantı başına ek maliyeti azaltır. HTTP/3 ise TCP yerine QUIC protokolünü kullanır; paket kaybının yüksek olduğu mobil ağlarda bağlantı kesintisiz sürdürülür. QUIC aynı zamanda bağlantı kurulumu ile TLS el sıkışmasını tek bir gidiş-dönüşe birleştirerek soğuk bağlantı maliyetini düşürür. HTTP/3 desteği CDN ve modern web sunucuları aracılığıyla genellikle yapılandırma değişikliği ile etkinleştirilebilir.

HTTP/103 Early Hints

Sunucu HTML yanıtını oluşturmadan önce hangi kritik kaynakların yüklenmesi gerektiğini biliyorsa HTTP 103 Early Hints ile bu ipuçlarını önceden iletebilir. Tarayıcı bu bilgilerle HTML gelmeden önce kritik CSS, fontlar veya LCP görselini preload etmeye başlar; bu da LCP öğesinin gerçek indirme süresini öne çeker. HTTP 103'ü destekleyen CDN'ler bu başlığı kenar düğümünden iletebilir; böylece kaynak sunucu TTFB yüksek olsa bile ipuçları erken ulaşır ve tarayıcı beklerken boşta kalmaz.