TTFB, yanıt süresi ve gecikme: her biri neyi ölçer

Her terim ne anlama gelir

Genellikle gidiş-dönüş süresi olarak raporlanan ağ gecikmesi, bir paketin aralarında hiçbir uygulama işi olmadan sunucuya gidip gelmesinin süresidir. Fiziksel mesafe, atlama sayısı ve rotanın kalitesi tarafından belirlenir. Kodunuzda yaptığınız hiçbir şey bunu değiştirmez.

İlk bayta kadar geçen süre (TTFB), istemcinin isteği başlattığı andan yanıtın ilk baytının ona ulaştığı ana kadar ölçülür. Bu aralık DNS aramasını, TCP bağlantısını, TLS el sıkışmasını, isteğin yolda geçirdiği süreyi, sunucunun bir yanıt üretmek için yaptığı her şeyi ve dönüş yolculuğunu içerir. Bu yüzden TTFB her zaman bir gidiş-dönüşten büyüktür, genellikle birkaç katı kadar.

Yanıt süresi üçü arasında en gevşek tanımlı olandır. Çoğu izleme aracı bunu isteğin tamamlanma süresi için kullanır: ilk paketten yanıt gövdesinin son baytına kadar. Bazı araçlar bunu TTFB'nin eş anlamlısı olarak kullanır. "Yanıt süresi" etiketli iki sayıyı karşılaştırmadan önce her aracın saati nerede durdurduğunu kontrol edin.

Her biri nasıl ölçülür

Gecikme, ping'in gönderdiği bir ICMP echo isteğinden gelir, veya ICMP engellendiğinde TCP el sıkışmasının süresinin ölçülmesinden gelir. TTFB ve toplam süre HTTP istemcisinin kendisinden gelir. Tek bir curl çağrısı tüm sınırları yazdırır:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Her değer isteğin başlangıcından itibaren kümülatiftir, bu yüzden bunları süre olarak değil sınır olarak okursunuz. Bir aşamanın uzunluğunu elde etmek için bir öncekini çıkarın.

Aracınız size hangi sayıyı gösteriyor

Her araç aynı isteğin farklı bir dilimini raporlar, ki bir sitenin iki ölçümünün uyuşmamasının olağan nedeni de budur:

• ping yalnızca gidiş-dönüş gecikmesini raporlar, hiçbir sunucu işi dahil değildir
• curl -w yukarıda listelenen her sınırı raporlar, ki bu da sayılar uyuşmadığında onu referans yapar
• Tarayıcı geliştirici araçları TTFB'yi isteğin bekleme aşaması olarak gösterir, altındaki indirme aşamasından ayrı
• Lighthouse ve PageSpeed, belge isteği için TTFB olan sunucu yanıt süresini raporlar
• Çalışma süresi monitörleri, tanımı ürüne göre değişen ve kontrolün çalıştığı yerden itibaren bağlantı kurulumunu da içeren bir yanıt süresi raporlar
• Gerçek kullanıcı izlemesi, gerçek ağlardaki gerçek ziyaretçiler üzerinden toplanan alan TTFB'sini raporlar

İyi bir sayı neye benzer

Gecikme coğrafya tarafından sınırlanır. Tek bir metropol alanı içinde 30 ms altı normaldir, bir kıta içinde 50 ile 100 ms, kıtalar arasında ise 150 ile 250 ms. Mesafenin çok üzerinde ölçülen bir rota, yavaş bir sunucudan çok kötü bir yolu işaret eder.

TTFB için web.dev, 800 ms veya altını iyi, 1,8 saniyenin üzerini ise kötü sayar; Lighthouse'un sunucu yanıt süresi denetimi ise 600 ms üzerinde başarısız olmaya başlar. Belge isteği için 600 ms altını, önbelleğe alınmış veya statik olarak sunulan her şey için ise 200 ms'yi hedef olarak alın.

Toplam yanıt süresi gönderdiğiniz şeyin boyutuna bağlıdır, bu yüzden evrensel bir rakam yoktur. Normal bir günde kendi taban değerinizi ölçün ve ondaki değişimi mutlak sayı yerine sinyal olarak ele alın.

Aradaki farkları okumak

Tek tek sayılar, aralarındaki mesafeden daha az önemlidir, çünkü her fark farklı bir alt sistemi işaret eder:

• TTFB eksi gidiş-dönüş gecikmesi, kabaca sunucunun düşünmeye harcadığı süredir. Eğer bu büyük kısımsa, sorun uygulama kodu, yavaş bir sorgu veya soğuk bir önbellektir
• Bağlantı eksi DNS araması, TCP el sıkışması için bir gidiş-dönüştür. Ölçtüğünüz gecikmeden çok daha büyükse, ağ yolu tıkanmış veya yanlış yönlendirilmiştir
• TLS eksi bağlantı, el sıkışma maliyetidir; genellikle bir veya iki ekstra gidiş-dönüş, ve büyük bir değer sertifika zinciri veya oturum devam ettirme sorunlarını işaret eder
• Toplam eksi TTFB aktarım süresidir. Eğer bu baskınsa, yanıt çok büyüktür veya bağlantı çok yavaştır, ve hiçbir sunucu ayarı yardımcı olmaz
• Tek başına DNS araması önbelleğe alındıktan sonra birkaç milisaniye olmalıdır. Sürekli yavaş bir arama bir çözümleyici veya yetkili isim sunucusu sorunudur, web sunucusu sorunu değil

Aynı okuma, yalnızca tek bir konum yavaş olduğunda tersine de işler. Her yerde eşit sunucu düşünme süresi, farkın tamamen gecikme ve aktarımda yaşanması, sunucunun sorunsuz olduğu ama rotanın olmadığı anlamına gelir. Uygulamaya dokunmadan önce kontrolü birkaç yerden çalıştırın.

Tek bir yerde ölçmek

Bu sayıları bir sayfa için elle bir araya getirmeden görmek için, sayfayı dış bir konumdan yükleyen ve yüklemeyi aşamalarına ayıran sayfa hızı testini çalıştırın. Sunucu yanıt süresi rehberi, aynı ölçümü komut satırından kapsar. Tek bir çalıştırma size yalnızca o anı anlatır, bu yüzden sayı önemliyse üzerine zamanlanmış bir kontrol koyun: HostTracker, 158 şehirdeki 300'den fazla kontrol noktasından her kontrolde yanıt süresini ölçer, ki bu da tek bir okumayı bir gerilemeyi fark edebileceğiniz bir taban değere dönüştürür. Daha fazla tanım için izleme kavramları bölümüne bakın.