İlk byte gecikmesi (Time to First Byte) sıkça yanlış noktada aranır. Sunucuya "yavaş" etiketi yapıştırılıp donanım yükseltilir. Oysa bekleyişin asıl kaynağı yavaş çalışan bir mikroservis, gereksiz bir veritabanı JOIN işlemi, gereğinden uzun bir yönlendirme zinciri veya hatalı proxy yapılandırmasıdır. TTFB'yi sahiden düşürmek istiyorsanız, gecikmenin tam olarak nerede biriktiğini parçalarına ayırmalısınız.

Bu metrik bilhassa içerik yoğun servislerde can damarıdır. HTML gövdesi istemciye geç ulaştığında, tarayıcının parsing süreci askıya alınır. CSS keşfi, görsel yüklemeleri ve LCP oluşumu doğrudan sekteye uğrar. TTFB, bir sayfanın nihai kalite skoru değildir; ancak süreçteki reaksiyonların başlama kronometresini devreye sokan eşiktir.

İlk byte gecikmesi neden tüm işleyişi kilitler?

TTFB, kullanıcının tıklama anından donanım ağ sekmesinde beliren ilk veri paketine kadar ölçülen boşluktur. Ekran bu evrede beyaz veya hareketsizdir. Tarayıcı DOM'u inşa etmeye başlamak için ham HTML yanıtının paketlerini bekler. Kaynağa erişmek uzadıkça, önbellekten çekilecek varlıklara değin her şey kuyrukta kalır.

Benzer biçimde Core Web Vitals süzgecinden geçirildiğinde, backend geç yanıt döndürürse hero görselinizin veya kritik fontunuzun tarayıcıya kendini tanıtma anı gecikir. Render zincirinin geriye doğru yığılmasını sağlayan mimari pürüzlerin en net izlendiği nokta burasıdır.

Yarım saniyenin altındaki (tercihen 200 ms ve altı) TTFB pürüzsüz sayılırken, sunucu bir tam saniyeyi bulduğu an kullanıcı "sayfa koptu" algısına kapılıp sekmeyi silme eşiğine geçer. Uygulama tarafında her kod bloğu hatasız görünürken trafiğin yarı yarıya düşmesinin arkasındaki teknik kayıp TTFB kaynaklı olabilir.

Diğer bir gerçek: Önbellekleme stratejisi CDN entegrasyonuyla yalnızca yüzeysel URL'lerde işe yarar. Düzenli cache alan bir ana sayfanız saniyesinde açılabilir, ancak üye profili, kompleks arama sonuçları veya veritabanı dinamik sorgusu çalışan sekmelerde TTFB doğrudan origin donanımın ve kod hiyerarşisinin işlem gücüne dönecektir.

Mimaride fatura yalnızca web sunucusuna kesilmez

Kullanıcının yaptığı yalın bir GET isteği arka planda geniş bir dağıtım döngüsüne girer. İstek Nginx veya IIS gibi karşılayıcıya düşer, iş mantığı ayağa kalkar, JWT ile oturum doğrulanır, ilgili servis üzerinden veritabanı işlemi yürütülür, Redis gibi RAM üstü cacheler yoklanır, dış servis mikroservislere HTTP atılır ve şablon motoru nihai HTML'yi birbirine diker.

Örnek bir senaryoda dağılım; Nginx transferi (10 ms), Kimlik doğrulama (80 ms), yoğun SQL (280 ms), dış API (200 ms) ve HTML renderlama (50 ms) şeklindeyse skor hemen 620 milisaniyeye tırmanır.

// Sunucu aşağıdakine benzer bir Server-Timing header değeri verebilir
Server-Timing: auth;dur=80, sql;dur=280, api;dur=200, render;dur=50

Eğer böyle detaylı parçalama yapabiliyorsanız, darboğazın worker sayısında olmadığını yakalarsınız. Düğüm noktası açıkça dış API ve SQL birleştirmesidir. Bu sorunu optimize etmek sistemin konfigürasyonuyla değil, kod katmanının elden geçirilmesiyle (algoritmik iyileştirmeyle) mümkün olur.

Dinamik ekran iş yükü

Modern frameworkler ve SSR (Server Side Rendering) sistemleri veriyi derlemeden önce veritabanındaki şemaları ve blok konumlarını hesaplar. İstek anında oluşturulan arayüz ağır derleniyorsa ilk satır istemciye geç iner.

Buna karşılık ekipler genelde CSS ve JS dosyalarını küçültüp (minify edip) sorunu aşmaya çalışır. Evet minify kaynaklar faydalıdır, ancak temel karkas gecikiyorsa o kaynaklara sıra geç gelecektir. PageSpeed Insights raporundaki "Reduce initial server response time" metni CSS tabanlı değil doğrudan SQL, PHP, Node vs. tabanlı bir arka operasyon yetersizliğinden bahseder.

Tarayıcı önbellekleme kurallarıyla sitenin görsellerini aylarca tarayıcıda tutsanız dahi, sunucunuz sayfanın temel iskeletini her defasında kullanıcı adı bazında veya sepetteki son veri bazında yeniden paketliyorsa o darboğaz aşılamaz. İdeal çözüm; kimlikten bağımsız jenerik blokları (menü, footer vb.) en hızlı katmandan yanıtlamak, kişiselleşmesi gereken noktaları ise sonradan AJAX/Hydration yoluyla istemcide bağlamaktır.

Kritik eşik: "Sürekli tam sayfa önbellek basacağız" teorisiyle oturum tokenleri veya sepet bakiye verileri tek tipe indirgenmemelidir. Performans verilerine koşarken, güvenlik ve kullanım tutarlılığı kaybedilebilir.

Görünmeyen proxy zinciri atlamaları

Bazı problemler arka uç (backend) kodundan tamamen bağımsızdır. Bir alan adı sorgusundan başlayıp, DNS atlamalarına, gereksiz WAF güvenlik şifrelemelerindeki soğuk TLS el sıkışmalarına (handshakes) varan fazladan bir yönlendirme merdiveni saptanabilir.

HTTP'den HTTPS'e, akabinde "www" veya Cloudflare gibi köprü katmanlarına zıplayan bir bağlantı, PHP ya da Node sürecine ulaşmadan kafadan ekstra 200-300 milisaniye kaybedebilir. Testleri curl -w komutlarıyla veya bir site analiz altyapısıyla çalıştırıp, gecikmenin uygulamanın içinden mi yoksa DNS-Routing üzerinden mi döndüğünü teyit etmek elzemdir.

Yükleme sürelerinin analizinde gecikmeleri HTTP logları, APM (Application Performance Monitoring) araçları veya ilişkisel veritabanlarının yavaş sorgu loglarından izleyin. Karar anında Server-Timing spesifikasyonundan ve log korelasyonundan beslenmek yanılgıları bitirir.

Önbellek, kuyruk ve soğuk başlangıç aynı metriğe yansır

TTFB tarafında gözden kaçan en önemli ayrımlardan biri, aynı URL'nin her istekte aynı yolu izlememesidir. Bir içerik sayfası misafir kullanıcı için kenar önbellekten (edge cache) 70 milisaniyede dönebilir; aynı sayfa oturum çerezi taşıyan kullanıcıda uygulama katmanına kadar inip 600 milisaniyeye çıkabilir. Bu yüzden yalnızca "bu sayfa hızlı" veya "bu sayfa yavaş" demek eksiktir. Hangi kullanıcı tipinde, hangi başlıklarla, hangi çerez setiyle önbelleğin devre dışı kaldığını anlamak gerekir. Özellikle sorgu parametreleri, takip çerezleri ve kişiselleştirme başlıkları kontrolsüz çoğaldığında cache anahtarları patlar ve sistem neredeyse her isteği yeniymiş gibi işler.

Bir diğer pratik sorun da soğuk başlangıçtır. PHP-FPM worker'larının sık sık yeniden doğduğu, Node süreçlerinin düşük trafikte uykuya alındığı ya da veritabanı bağlantı havuzunun yetersiz kurulduğu sistemlerde ilk istek düzenli biçimde daha yavaş gelir. Kod düzgün olsa bile süreç ayağa kalkarken sınıf yükleme, bağlantı açma, çevresel değişken çözme ve ilk sorgu hazırlama maliyeti birikir. Özellikle panel, raporlama veya seyrek ziyaret edilen rota gruplarında bu davranış net görülür. Böyle bir senaryoda çözüm yalnızca daha güçlü sunucu kiralamak değildir; worker ömrünü, bağlantı havuzu boyutunu ve uygulama başlangıç maliyetini birlikte ele almak gerekir.

Kuyruklanma etkisi de TTFB'yi bozan sessiz faktörlerden biridir. Trafik arttığında işlemci değil eşzamanlılık modeli tıkanabilir. Örneğin sekiz worker'lı bir uygulamada her istek üçüncü taraf API'den senkron veri bekliyorsa, dokuzuncu kullanıcı doğrudan sıraya girer. Kullanıcı bunu "site açılmıyor" diye hisseder; oysa ana sorun ağ hattı değil, bloklayan iş akışıdır. Bu tür durumlarda yavaş e-posta gönderimi, rapor üretimi, PDF hazırlama veya dış servis doğrulaması gibi ağır işler yanıt döndürme hattından çıkarılıp arka plan kuyruğuna alınmalıdır. HTML iskeleti önce gelmeli, kritik olmayan işler sonra tamamlanmalıdır.

Doğru teşhis için aynı sayfayı tek bir sayı ile değil, birkaç senaryo ile ölçmek gerekir: soğuk istek, sıcak istek, önbellek isabeti olan istek, çerezli istek, botsuz gerçek kullanıcı isteği. Origin loglarındaki sürelerle Server-Timing başlıklarını yan yana koyduğunuzda hangi katmanın yükü taşıdığını çok daha net görürsünüz. Ancak o zaman "CDN ekleyelim", "SQL sadeleştirelim" veya "SSR yükünü parçalara ayıralım" gibi kararlar veri temelli hale gelir. TTFB iyileştirmesi çoğu zaman tek bir ayar değil, istek yolculuğundaki her katmanın ne kadar süre tuttuğunu dürüstçe görme işidir.

Hızlı bir yanıttan yola çıkan parçaların tarayıcı ortamında ne tür DOM blokajlarına dönüştüğünü incelemek için critical CSS metriklerini okumaya devam edebilirsiniz.