Ağ Waterfall Grafiği Nasıl Okunur

Bir hız testi aracının size verdiği "sayfanız 4,2 saniyede yükleniyor" cümlesi tek başına hiçbir işe yaramaz; çünkü o 4,2 saniyenin nerede harcandığını söylemez. Waterfall grafiği tam olarak bunu gösterir: sayfanın yüklenmesi sırasında yapılan her isteği, hangi sırayla başladığını, ne kadar beklediğini ve hangi aşamada takıldığını yatay çubuklar hâlinde önünüze serer. Yavaş bir sayfayı düzeltmenin en kestirme yolu, tahmin yürütmek yerine bu grafiği doğru okumaktır.

Bu rehberde bir waterfall grafiğinin anatomisini adım adım açacağım: renkli aşamaların her biri fiziksel olarak neyi ölçüyor, dikey çizgiler ne anlama geliyor, hangi desen hangi soruna işaret ediyor ve bulduğunuz sorunu nasıl düzeltiyorsunuz. Chrome DevTools, WebPageTest ve GTmetrix gibi araçların hepsi aynı temel grafiği farklı renklerle çizer; mantığı bir kez oturttuğunuzda hangi aracı kullandığınızın önemi kalmaz.

Waterfall Grafiği Neyi Gösterir#

Waterfall, adını şelale gibi kademeli inen görünümünden alır. Grafiğin dikey ekseninde istekler yükleme sırasına göre alt alta dizilir; yatay eksende ise zaman akar. Her satır tek bir ağ isteğidir: bir HTML belgesi, bir CSS dosyası, bir JavaScript paketi, bir görsel, bir yazı tipi ya da bir API çağrısı. Çubuğun sol kenarı isteğin başladığı anı, sağ kenarı bittiği anı gösterir; uzunluğu ise o isteğin toplam süresidir.

Grafiğin asıl değeri tek tek çubuklarda değil, aralarındaki ilişkidedir. İlk satır her zaman ana HTML belgesidir ve diğer her şey ondan türer. Tarayıcı HTML'i indirip ayrıştırırken içindeki link, script ve img referanslarını görür, sıraya alır ve indirmeye başlar. Bu yüzden sağlıklı bir waterfall'da ilk isteğin hemen ardından geniş bir "yelpaze" açılır: çok sayıda istek neredeyse aynı anda paralel başlar. Grafiğiniz yelpazeye değil de merdivene benziyorsa, yani her istek bir öncekinin bitmesini bekliyorsa, orada mutlaka bir bağımlılık zinciri vardır ve düzeltilecek asıl şey odur.

Bir waterfall'a bakarken cevabını aradığınız üç soru şudur: İlk baytın gelmesi neden bu kadar uzun sürdü? Görsel içeriği çizmeyi engelleyen kaç istek var? Ve hangi istekler gereksiz yere birbirini bekliyor? Bu üç soruyu cevaplayabiliyorsanız grafiği okuyabiliyorsunuz demektir. Core Web Vitals metriklerinin neredeyse tamamının kökü de bu üç sorudan birine dayanır.

Bir İstek Çubuğunun Renkli Aşamaları#

Tek bir çubuk aslında birkaç ayrı aşamanın toplamıdır ve araçlar bunları farklı renklerle boyar. Aşamaları ayırt etmeyi öğrenmek, sorunun sunucuda mı, ağda mı yoksa tarayıcıda mı olduğunu anında söyler:

Bu tablodaki en kritik satır Waiting, yani TTFB'dir (Time To First Byte). DNS, bağlantı ve TLS aşamaları ilk istekte birer kez ödenir ve genelde birkaç yüz milisaniyeyi geçmez. Ancak Waiting uzunsa sorun ağda değil, doğrudan sunucunuzun içindedir: veritabanı sorgusu yavaştır, PHP her istekte sayfayı yeniden üretiyordur ya da sunucu kaynak sıkıntısı çekiyordur.

Aşamaları komut satırından da ölçebilirsiniz; tarayıcı açmadan hızlıca bakmak için curl yeterlidir:

# Her aşamayı ayrı ayrı saniye cinsinden yazdır
curl -o /dev/null -s -w \
"DNS:      %{time_namelookup}\nBaglanti: %{time_connect}\nTLS:      %{time_appconnect}\nTTFB:     %{time_starttransfer}\nToplam:   %{time_total}\n" \
https://firmaniz.com/

Örnek bir çıktı şuna benzer:

DNS:      0.021
Baglanti: 0.048
TLS:      0.112
TTFB:     0.890
Toplam:   0.935

Bu çıktıda TLS 112 ms'de bitmiş ama TTFB 890 ms olmuş; yani sunucu cevabı hazırlamak için tek başına yaklaşık 780 ms harcamış. Burada CDN ya da görsel optimizasyonu ile uğraşmanın anlamı yok; önce sunucu tarafını hızlandırmak gerekir.

Dikey Çizgiler: DOMContentLoaded, Load, FCP ve LCP#

Waterfall grafiklerinin üzerinde dikey renkli çizgiler bulunur ve bunlar isteklerden çok daha fazlasını anlatır. Mavi çizgi genellikle DOMContentLoaded anını, kırmızı çizgi load olayını işaretler. WebPageTest gibi araçlar buna ek olarak FCP ve LCP işaretlerini de çizer. Bu çizgilerin nerede durduğu, hangi isteklerin kullanıcının gördüğü içeriği geciktirdiğini doğrudan gösterir.

Pratik okuma yöntemi şudur: FCP çizgisinin soluna düşen her istek, ilk pikselin ekrana gelmesini geciktirmiş demektir. Bu bölgede ne kadar az istek varsa o kadar iyidir. Buraya düşen tipik suçlular şunlardır: head içindeki render engelleyici CSS dosyaları, defer veya async verilmemiş betikler ve harici bir alan adından çekilen yazı tipleri. LCP çizgisinin soluna düşen istekler ise ana görselin ya da başlık bloğunun çizilmesini geciktirir; bunları ayıklamak için LCP iyileştirme rehberine bakabilirsiniz.

Bir başka önemli okuma, load çizgisinden sonra devam eden isteklerdir. Sohbet widget'ları, analiz betikleri ve reklam etiketleri genellikle burada görünür ve teknik olarak sayfa yükleme süresini etkilemezler. Ancak ana iş parçacığını meşgul ederek etkileşim gecikmesine yol açabilirler; bu ayrımı INP metriği bağlamında değerlendirmek gerekir.

Beş Tipik Waterfall Deseni ve Anlamları#

Yıllar içinde gördüğüm yavaş sitelerin neredeyse tamamı şu beş desenden birine uyuyor. Deseni tanıdığınız anda çözüm de kendiliğinden ortaya çıkıyor:

1. Tek uzun ilk çubuk. İlk HTML isteğinin Waiting aşaması saniyelerce sürüyor, diğer her şey normal. Sorun tamamen sunucu tarafındadır: sayfa önbelleği yok, veritabanı sorguları ağır ya da sunucu kapasitesi yetersiz.
2. Merdiven (istek zinciri). İstekler alt alta kademeli başlıyor, her biri bir öncekinin bitişini bekliyor. Genelde bir CSS dosyasının içinden @import ile başka bir CSS çağrılması veya bir betiğin başka bir betiği dinamik olarak yüklemesi yüzünden olur.
3. Uzun sarı/mor blok yığını. Çok sayıda farklı alan adına bağlantı kuruluyor; her biri ayrı DNS + TCP + TLS ödüyor. Üç dört harici servis kullanan sitelerde klasiktir.
4. Devasa tek çubuk. Tek bir dosya (genellikle optimize edilmemiş bir hero görseli veya 1,5 MB'lık bir JavaScript paketi) grafiğin yarısını kaplıyor.
5. Load çizgisinden sonra biten kuyruk. Sayfa görsel olarak hazır ama arka planda onlarca istek devam ediyor; mobil cihazlarda pil ve veri tüketimi sorunu yaratır.

Her deseni ayırt ederken sütun genişliklerine değil, çubuğun rengine bakın. Uzun bir çubuk mavi (indirme) ise dosya büyüktür; yeşil/sarı (bekleme) ise sunucu yavaştır. Bu ayrım, yanlış yerde saatler harcamanızı engeller.

İstek Zincirini Kırmak: preconnect ve preload#

Merdiven deseni gördüğünüzde amaç, tarayıcının bir kaynağı "keşfetmesini" beklemeden erkenden haberdar etmektir. İki temel araç vardır: preconnect bağlantıyı önceden kurar, preload dosyayı önceden indirtir. İkisini de head bölümünün üst kısmına koyarsınız:

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">
<link rel="preload" as="font" type="font/woff2" href="/fonts/inter.woff2" crossorigin>

Yukarıdaki üç satır sırasıyla şunu yapar: birinci satır yazı tipi sunucusuna bağlantıyı sayfa daha ayrıştırılırken kurar, ikinci satır LCP görselini tarayıcı HTML içinde keşfetmeden indirmeye başlar, üçüncü satır ise kritik yazı tipini erkenden alır.

Sunucu tarafında da aynı işi HTTP başlığı ile yapabilirsiniz; özellikle HTML'i düzenleyemediğiniz durumlarda kullanışlıdır:

# Nginx: kritik CSS icin erken ipucu basligi
location / {
    add_header Link "</css/kritik.css>; rel=preload; as=style" always;
}

Zincirin bir diğer klasik kaynağı CSS içindeki @import satırlarıdır. Tarayıcı ana CSS'i indirmeden içindeki @import'u göremez, dolayısıyla ikinci dosya ancak birincisi bittikten sonra başlar. Çözüm basittir: @import kullanmayın, dosyaları derleme aşamasında birleştirin ya da hepsini ayrı link etiketleriyle çağırın. Aynı mantıkla, betikleri defer ile işaretlemek ayrıştırmayı engellemelerini önler ve grafikteki merdiveni tek seferde düzleştirir.

Aynı Grafiği Farklı Araçlarda Okumak#

Chrome DevTools'un Network paneli en hızlı erişilen waterfall'dır ama en yanıltıcı olanıdır da: kendi bilgisayarınızın hızını ve önbelleğinizi ölçer. Gerçekçi bir okuma için üç ayarı mutlaka açın: Disable cache kutusunu işaretleyin, No throttling yerine "Fast 3G" veya "Slow 4G" seçin ve gizli pencerede test edin. Paneldeki ayrıntılı aşama dökümünü görmek için herhangi bir isteğin üzerine gelip Timing sekmesini açmanız yeterlidir. Bu panelin diğer yetenekleri için Chrome DevTools performans paneli yazısına bakabilirsiniz.

WebPageTest ise gerçek bir cihazda, seçtiğiniz şehirden ölçüm yapar ve waterfall'ı çok daha ayrıntılı çizer; özellikle "Connection View" görünümü hangi bağlantının ne kadar yeniden kullanıldığını gösterir. GTmetrix aynı grafiği daha sade sunar ve WordPress kullanıcıları için pratiktir; GTmetrix ile WordPress hız testi yazısında bu aracın raporunu ayrıntılı ele aldım. Üç aracın da ölçtüğü şey aynıdır, farklı olan tek şey ölçüm noktası ve ağ koşullarıdır.

Sık Yapılan Hatalar#

En sık gördüğüm hata, önbellekli tarayıcıda ölçüm yapmaktır. İkinci kez açtığınız sayfa doğal olarak hızlıdır; grafiğin gerçek hikâyesi ilk ziyarettedir. Ölçümü her zaman boş önbellekle, tercihen gizli pencerede yapın.

İkinci hata toplam süreye takılmaktır. Grafiğin sağ ucundaki büyük sayı, load olayından sonra çalışan analiz betikleri yüzünden şişebilir; oysa kullanıcı sayfayı çoktan kullanmaya başlamıştır. Toplam yerine FCP ve LCP çizgilerine bakın.

Üçüncü hata, büyük çubuğu otomatik olarak suçlu ilan etmektir. load sonrası başlayan 2 MB'lık bir video ön izlemesi grafikte korkunç görünür ama kullanıcı deneyimini hiç etkilemeyebilir. Buna karşılık FCP'den önce duran 12 KB'lık bir yazı tipi dosyası, tüm metnin görünmesini geciktirdiği için çok daha zararlıdır.

Dördüncü hata, sıkıştırmayı doğrulamadan sonuç çıkarmaktır. İndirme aşaması uzun görünüyorsa önce cevabın gerçekten sıkıştırılıp sıkıştırılmadığına bakın:

# Sunucu Brotli/gzip donuyor mu, content-encoding basligini kontrol et
curl -sI -H "Accept-Encoding: br,gzip" https://firmaniz.com/ | grep -i "content-encoding\|content-length"

Bu başlık boş dönüyorsa hiçbir görsel optimizasyonu yapmadan önce sıkıştırmayı açmanız gerekir; .htaccess ile önbellek ve sıkıştırma yazısı Apache tarafındaki ayarları adım adım anlatır.

Sıkça Sorulan Sorular#

Waterfall grafiğinde ideal TTFB kaç milisaniye olmalı#

Genel kabul gören eşik 200 ms'nin altıdır; 500 ms'ye kadar olan değerler kabul edilebilir sayılır, 800 ms üzeri ise düzeltilmesi gereken bir sorundur. Statik bir sayfa önbellekten dönüyorsa TTFB rahatlıkla 100 ms'nin altına iner. Dinamik ve kişiselleştirilmiş sayfalarda daha yüksek olması normaldir ama yine de veritabanı sorgularını ve nesne önbelleğini gözden geçirmeniz gerekir.

Grafikteki gri veya renksiz kısım ne anlama geliyor#

Çubuğun başındaki soluk ya da gri bölüm genellikle "queueing" veya "stalled" süresidir; yani istek oluşturulmuş ama tarayıcı henüz göndermemiştir. Bunun en yaygın sebebi aynı alan adına açılabilecek eşzamanlı bağlantı sınırıdır. HTTP/2 kullanan bir sunucuda bu bekleme büyük ölçüde kaybolur, çünkü tek bağlantı üzerinden çok sayıda istek paralel taşınabilir.

Waterfall'da kaç istek olması normaldir#

Sabit bir sayı yoktur ama pratik bir ölçüt verilebilir: kurumsal bir tanıtım sayfası için 40-60 istek makul, 150'nin üzeri ise fazladır. Önemli olan sayıdan çok isteklerin nereye düştüğüdür. FCP'den önce 8-10 istek varsa sorun yok; aynı bölgede 40 istek varsa ilk çizim ciddi biçimde gecikiyor demektir.

Waterfall grafiğini mobil için nasıl alırım#

DevTools'ta cihaz emülasyonunu açıp ağ kısıtlaması uygulamak hızlı bir yaklaşımdır ama gerçek sonuç vermez, çünkü işlemci farkını tam yansıtmaz. Daha doğru yöntem WebPageTest üzerinden gerçek bir mobil cihaz ve mobil bağlantı profili seçmektir. En kesin sonuç ise USB ile bağlanmış gerçek bir telefonda uzaktan hata ayıklama yaparak alınır.

İstek zincirini nasıl kontrol ederim#

Lighthouse raporundaki "Avoid chaining critical requests" bölümü zinciri ağaç yapısında listeler ve en uzun yolu gösterir. Aynı bilgiyi waterfall'da gözle de görebilirsiniz: bir çubuğun sol kenarı, bir öncekinin sağ kenarıyla hizalıysa bağımlılık vardır. Zincirin uzunluğunu kırmak için preload, preconnect ve @import kaldırma üçlüsü genellikle yeterlidir.

CDN kullanınca waterfall nasıl değişir#

CDN, statik dosyaların DNS, bağlantı ve indirme aşamalarını kullanıcıya yakın bir noktadan sunduğu için o çubuklar belirgin biçimde kısalır. Ancak ilk HTML isteğinin TTFB'si, sayfa önbelleğe alınmıyorsa değişmez; CDN dinamik içeriği hızlandırmaz. Bu ayrımı CDN mi daha iyi hosting mi yazısında ayrıntılı karşılaştırdım.

Kapanış#

Waterfall grafiği, performans işinin en dürüst aracıdır: tahmin bırakmaz, sorunun nerede olduğunu doğrudan gösterir. Aklınızda kalması gereken dört alışkanlık şu: ölçümü her zaman boş önbellekle ve gerçekçi bir ağ profiliyle yapın, çubuğun uzunluğuna değil rengine bakarak sunucu-ağ-tarayıcı ayrımını yapın, FCP ve LCP çizgilerinin soluna düşen istekleri tek tek gerekçelendirin ve merdiven desenini gördüğünüz anda zinciri preload/preconnect ile kırın.

Grafiği okuyup sorunun sunucu tarafında olduğunu gördüyseniz, çözüm çoğu zaman altyapıyı değiştirmekten geçer. Yüksek TTFB'yi kalıcı olarak düşürmek için NVMe diskli ve güçlü işlemcili VDS sunucularımızı ya da hazır ayarlı web hosting paketlerimizi inceleyebilirsiniz; ölçüm ve iyileştirme işini tamamen devretmek isterseniz sunucu yönetimi hizmetimiz bu analizi sizin yerinize yapar. Bant genişliği ihtiyacınızı kabaca hesaplamak için bant genişliği hesaplayıcı aracımız işinizi görür.