⏱️ E4 · Timing Sekmesi: TTFB, Waiting, Download

E4 · Timing Sekmesi: TTFB, Waiting: Timing sekmesi, bir **kargo takip sayfası** gibidir: bir request "yola çıktığında" tek bir "2.9 saniye sürdü" sayısı sana hiçbir şey ANLATMAZ,

Timing sekmesi, bir **kargo takip sayfası** gibidir: bir request "yola çıktığında" tek bir "2.9 saniye sürdü" sayısı sana hiçbir şey ANLATMAZ, ama kargo takibi gibi süreyi aşamalara bölersen ("depoda bekledi", "yolda gitti", "kapıya teslim edildi") gecikmenin TAM OLARAK nerede olduğunu görürsün. `TTFB` (Time To First Byte) = sunucunun ilk baytı göndermesi ne kadar sürdü, `Waiting` = sunucunun request'i İŞLEMESİ ne kadar sürdü (genelde en büyük dilim), `Content Download` = response verisinin İNMESİ ne kadar sürdü. Peki neden bu ayrım bu kadar önemli — "3 saniye yavaş" demek yetmez mi? Çünkü çözüm TAMAMEN farklıdır: `Waiting` büyükse suçlu SUNUCUdur (yavaş bir SQL sorgusu, N+1 problemi — geliştiriciye escalate edilir), `Content Download` büyükse suçlu VERİ BOYUTU/AĞdır (gereksiz büyük bir JSON, sıkıştırma eksikliği). Java'da bunun karşılığı bir metodun içine konan `System.currentTimeMillis()` ile yapılan elle profiling'dir — ama orada SEN segmentleri elle ölçersin, tarayıcı Timing sekmesinde bunu SENİN için otomatik yapar. QA açısından "yavaş" bir performans bug raporu Timing verisi olmadan neredeyse değersizdir — geliştirici "hangi katman yavaş?" diye sorduğunda "bilmiyorum, genel olarak yavaştı" cevabı, raporu geri gönderilmeye mahkûm eder.

Bir Request'in Üç Aşaması

Timing sekmesindeki yatay çubuk, bir request'in süresini renkli dilimlere ayırır. `TTFB` genelde küçüktür (sunucunun "aldım" demesi hızlıdır); `Waiting` request'in GERÇEKTEN işlendiği süredir — burada bir veritabanı sorgusu, bir dış servis çağrısı veya kötü bir algoritma zaman harcayabilir; `Content Download` ise büyük bir response gövdesinin (örn. binlerce bug kaydı) inmesi için geçen süredir.

Timing Çubuğu — TTFB / Waiting / Content Download

🎬 3 Saniyelik Gecikme: Ağ mı, Sunucu mu?

Bir request toplamda 2.9 saniye sürüyor — tester tek başına bu sayı ile hiçbir şey diyemez.

Timing sekmesi süreyi üçe böler. `TTFB` sadece 0.1s — sunucuya ulaşmak ve ilk response'u almak hızlı.

`Waiting` 2.7s — toplam sürenin neredeyse tamamı burada. Sunucu request'i işlerken (bir sorgu, bir hesaplama) zaman harcıyor.

`Content Download` sadece 0.1s — response verisi küçük, indirme hızlı. Ağ/veri boyutu SUÇLU DEĞİL.

Ders — 2.7s / 2.9s Waiting'e ait: gecikme AĞDA değil SUNUCUDA. Bug raporu "genel olarak yavaş" değil, "Waiting fazında 2.7s, muhtemel N+1/yavaş sorgu" diye açılmalı.

Yavaşlığın Suçlusunu Teşhis Etme Sırası

Büyükse sunucuya ulaşmak/ilk response bile gecikiyordur (ağ/DNS/sunucu yükü).

Büyükse sunucu request'i İŞLERKEN yavaş — bir sorgu/hesaplama şüphelidir, geliştiriciye escalate edilir.

Content Download'a bak…