Navigasyon Zamanlaması ve Kaynak Zamanlaması ile sahada yükleme performansını değerlendirme

Bir tarayıcının geliştirici araçlarında (veya deniz feneri Chrome’da), yükleme performansını değerlendirmek için, bu araçların performans ayarı için ne kadar uygun olduğunu bilirsiniz. Tutarlı ve istikrarlı bir temel bağlantı hızı ile performans iyileştirmelerinin etkisini hızla ölçebilirsiniz. Tek sorun, bunun saha verilerini değil laboratuvar verilerini veren sentetik test olmasıdır.

Sentetik test doğası gereği değildir kötü, ancak web sitenizin gerçek kullanıcılar için ne kadar hızlı yüklendiğini temsil etmez. Bunun için Navigation Timing ve Resource Timing API’lerinden toplayabileceğiniz saha verileri gerekir.

Sahada yükleme performansını değerlendirmenize yardımcı olacak API’ler #

Gezinme Zamanlaması ve Kaynak Zamanlaması, iki farklı şeyi ölçen önemli ölçüde örtüşen iki benzer API’dir:

• Navigasyon Zamanlaması HTML belgeleri için isteklerin (yani gezinme istekleri) hızını ölçer.
• Kaynak Zamanlaması CSS, JavaScript, görseller vb. gibi belgeye bağlı kaynaklara yönelik isteklerin hızını ölçer.

Bu API’ler, verilerini bir performans giriş arabelleği, tarayıcıda JavaScript ile erişilebilir. Bir performans arabelleğini sorgulamanın birden çok yolu vardır, ancak yaygın bir yol kullanmaktır. performance.getEntriesByType:

// Get Navigation Timing entries:
performance.getEntriesByType('navigation');
// Get Resource Timing entries:
performance.getEntriesByType('resource');

performance.getEntriesByType performans giriş arabelleğinden almak istediğiniz girişlerin türünü açıklayan bir dizeyi kabul eder. 'navigation' Ve 'resource' Sırasıyla Gezinme Zamanlaması ve Kaynak Zamanlaması API’leri için zamanlamaları alın.

Bu API’lerin sağladığı bilgi miktarı çok fazla olabilir, ancak web sitenizi ziyaret ettikleri sırada kullanıcılardan bu zamanlamaları toplayabildiğiniz için, sahada yükleme performansını ölçmenin anahtarı bunlardır.

Bir ağ talebinin ömrü ve zamanlamaları #

Gezinme ve kaynak zamanlamalarını toplamak ve analiz etmek, bir ağ isteğinin kısacık ömrünü olaydan sonra yeniden inşa ettiğiniz için bir tür arkeoloji gibidir. Bazen kavramları görselleştirmeye yardımcı olur ve ağ istekleri söz konusu olduğunda, tarayıcınızın geliştirici araçları yardımcı olabilir.

Bir ağ talebinin ömrü, DNS araması, bağlantı kurulumu, TLS anlaşması vb. gibi farklı aşamalara sahiptir. Bu zamanlamalar şu şekilde temsil edilir: DOMHighResTimestamp. Tarayıcınıza bağlı olarak, zamanlamaların ayrıntı düzeyi mikrosaniyeye kadar inebilir veya milisaniyeye yuvarlanabilir. Bu aşamaları ve bunların Seyir Zamanlaması ve Kaynak Zamanlaması ile nasıl ilişkili olduğunu ayrıntılı olarak inceleyelim.

DNS araması #

Bir kullanıcı bir URL’ye gittiğinde, Etki Alanı Adı Sistemi (DNS) bir etki alanını bir IP adresine çevirmek için sorgulanır. Bu süreç önemli ölçüde zaman alabilir; hatta sahada ölçmek isteyeceğiniz süre. Gezinme Zamanlaması ve Kaynak Zamanlaması, DNS ile ilgili iki zamanlamayı ortaya çıkarır:

• domainLookupStart DNS aramasının başladığı zamandır.
• domainLookupEnd DNS aramasının sona erdiği zamandır.

Toplam DNS arama süresinin hesaplanması, başlangıç ​​metriğini bitiş metriğinden çıkararak yapılabilir:

// Measuring DNS lookup time
const [pageNav] = performance.getEntriesByType('navigation');
const totalLookupTime = pageNav.domainLookupEnd - pageNav.domainLookupStart;

Bağlantı görüşmesi #

Yükleme performansına katkıda bulunan diğer bir faktör, bir web sunucusuna bağlanırken oluşan gecikme olan bağlantı anlaşmasıdır. HTTPS söz konusuysa, bu süreç aynı zamanda TLS görüşme süresini de içerecektir. Bağlantı aşaması üç zamanlamadan oluşur:

• connectStart tarayıcının bir web sunucusuna bağlantı açmaya başladığı zamandır.
• secureConnectionStart istemci TLS anlaşmasına başladığında işaretler.
• connectEnd web sunucusuna bağlantı kurulduğu zamandır.

Toplam bağlantı süresinin ölçülmesi, toplam DNS arama süresinin ölçülmesine benzer: başlangıç ​​zamanlamasını bitiş zamanından çıkarırsınız. Ancak, ek bir secureConnectionStart olabilecek özellik 0 HTTPS kullanılmıyorsa veya bağlantı kalıcıysa. TLS görüşme süresini ölçmek istiyorsanız, şunu aklınızda tutmanız gerekir:

// Quantifying total connection time
const [pageNav] = performance.getEntriesByType('navigation');
const connectionTime = pageNav.connectEnd - pageNav.connectStart;
let tlsTime = 0; // &LT-- Assume 0 to start with
// Was there TLS negotiation?
if (pageNav.secureConnectionStart > 0) {
// Awesome! Calculate it!
tlsTime = pageNav.connectEnd - pageNav.secureConnectionStart;
}

DNS araması ve bağlantı görüşmesi sona erdiğinde, belgelerin ve bunlara bağlı kaynakların getirilmesiyle ilgili zamanlamalar devreye girer.

İstekler ve yanıtlar #

Yükleme performansı iki tür faktörden etkilenir:

• Dış faktörler: Bunlar gecikme ve bant genişliği gibi şeylerdir. Bir barındırma şirketi ve bir CDN seçmenin ötesinde, kullanıcılar web’e her yerden erişebildiğinden, bunlar (çoğunlukla) bizim kontrolümüz dışındadır.
• İçsel faktörler: Bunlar, sunucu ve istemci tarafı mimarileri, kaynak boyutu ve kontrolümüz dahilinde olan bu şeyleri optimize etme yeteneğimiz gibi şeylerdir.

Her iki faktör türü de yükleme performansını etkiler. Bu faktörlerle ilgili zamanlamalar, kaynakların indirilmesinin ne kadar sürdüğünü açıkladıkları için hayati önem taşır. Hem Gezinme Zamanlaması hem de Kaynak Zamanlaması, yükleme performansını aşağıdaki ölçümlerle açıklar:

• fetchStart tarayıcının bir gezinme isteği için bir kaynak (Kaynak Zamanlaması) veya bir belge (Navigasyon Zamanlaması) getirmeye başladığını işaretler. Bu, gerçek istekten önce gelir ve tarayıcının önbellekleri (örneğin, HTTP ve Cache örnekler).
• workerStart bir istek, bir hizmet çalışanının içinde işlenmeye başladığında işaretler fetch olay işleyicisi. Bu olacak 0 geçerli sayfayı hiçbir hizmet çalışanı kontrol etmediğinde.
• requestStart tarayıcının istekte bulunduğu zamandır.
• responseStart yanıtın ilk baytının geldiği zamandır.
• responseEnd yanıtın son baytının geldiği zamandır.

Bu zamanlamalar, bir hizmet çalışanı içinde önbellek araması gibi yükleme performansının birden çok yönünü ölçmenize olanak tanır. Ve indirme süresi:

// Cache seek plus response time of the current document
const [pageNav] = performance.getEntriesByType('navigation');
const fetchTime = pageNav.responseEnd - pageNav.fetchStart;
// Service worker time plus response time
let workerTime = 0;
if (pageNav.workerStart > 0) {
workerTime = pageNav.responseEnd - pageNav.workerStart;
}

İstek/yanıt gecikmesinin diğer yönlerini de ölçebilirsiniz:

const [pageNav] = performance.getEntriesByType('navigation');
// Request time only (excluding redirects, DNS, and connection/TLS time)
const requestTime = pageNav.responseStart - pageNav.requestStart;
// Response time only (download)
const responseTime = pageNav.responseEnd - pageNav.responseStart;
// Request + response time
const requestResponseTime = pageNav.responseEnd - pageNav.requestStart;

Yapabileceğiniz diğer ölçümler #

Navigasyon Zamanlaması ve Kaynak Zamanlaması, yukarıdaki örneklerin ana hatlarından daha fazlası için yararlıdır. Keşfetmeye değer olabilecek ilgili zamanlamaları olan diğer bazı durumlar şunlardır:

• Sayfa yönlendirmeleri: Yönlendirmeler, özellikle yönlendirme zincirleri olmak üzere gözden kaçan ek gecikme kaynağıdır. Gecikme, HTTP’den HTTP’ye atlamalar ve 302/önbelleğe alınmamış 301 yönlendirmeleri gibi çeşitli şekillerde eklenir. bu redirectStart, redirectEndVe redirectCount zamanlamalar, yönlendirme gecikmesinin değerlendirilmesinde yardımcı olur.
• Belge boşaltma: Kod çalıştıran sayfalarda unload olay işleyicisitarayıcının bir sonraki sayfaya gitmeden önce bu kodu çalıştırması gerekir. unloadEventStart Ve unloadEventEnd belge boşaltmayı ölçün.
• Belge oluşturuluyor: Web siteniz çok büyük HTML yükleri göndermediği sürece belge işleme süresi önemli olmayabilir. Bu, durumunuzu açıklıyorsa, domInteractive, domContentLoadedEventStart, domContentLoadedEventEndVe domComplete zamanlamalar ilginizi çekebilir.

Uygulama kodunda zamanlamaları alma #

Şimdiye kadar gösterilen tüm örneklerde kullanım performance.getEntriesByTypeancak performans giriş arabelleğini sorgulamanın başka yolları da vardır, örneğin performance.getEntriesByName Ve performance.getEntries. Bu yöntemler, yalnızca ışık analizine ihtiyaç duyulduğunda uygundur. Ancak diğer durumlarda, çok sayıda girişi yineleyerek veya hatta yeni girişler bulmak için performans arabelleğini tekrar tekrar yoklayarak aşırı ana iş parçacığı çalışmasına neden olabilirler.

Performans giriş arabelleğinden girişleri toplamak için önerilen yaklaşım, bir PerformanceObserver. PerformanceObserver performans girişlerini dinler ve ara belleğe eklendikçe bunları sağlar:

// Create the performance observer:
const perfObserver = new PerformanceObserver((observedEntries) => {
// Get all resource entries collected so far:
const entries = observedEntries.getEntries();
// Iterate over entries:
for (let i = 0; i  entries.length; i++) {
// Do the work!
}
});
// Run the observer for Navigation Timing entries:
perfObserver.observe({
type: 'navigation',
buffered: true
});
// Run the observer for Resource Timing entries:
perfObserver.observe({
type: 'resource',
buffered: true
});

Bu zamanlama toplama yöntemi, performans giriş arabelleğine doğrudan erişmeye kıyasla garip gelebilir, ancak kritik ve kullanıcıya yönelik bir amaca hizmet etmeyen işle ana iş parçacığını birbirine bağlamak tercih edilir.

eve telefon etmek #

İhtiyacınız olan tüm zamanlamaları topladıktan sonra, daha fazla analiz için bunları bir uç noktaya gönderebilirsiniz. Bunu yapmanın iki yolu, navigator.sendBeacon veya bir fetch ile keepalive seçenek ayarlamak. Her iki yöntem de, belirli bir uç noktaya engellemesiz bir şekilde istek gönderir ve istek, gerekirse geçerli sayfa oturumunu geride bırakacak şekilde kuyruğa alınır:

// Caution: If you have lots of performance entries, don't
// do this. This is an example for illustrative purposes.
const data = JSON.stringify(performance.getEntries()));
// The endpoint to transmit the encoded data to
const endpoint = '/analytics';
// Check for fetch keepalive support
if ('keepalive' in Request.prototype) {
fetch(endpoint, {
method: 'POST',
body: data,
keepalive: true,
headers: {
'Content-Type': 'application/json'
}
});
} else if ('sendBeacon' in navigator) {
// Use sendBeacon as a fallback
navigator.sendBeacon(endpoint, data);
}

Bu örnekte, JSON dizesi bir POST Gerektiğinde bir uygulama arka ucunda kodunu çözebileceğiniz ve işleyebileceğiniz/depolayabileceğiniz yük.

Sarma #

Metrikleri topladıktan sonra, bu saha verilerini nasıl analiz edeceğinizi bulmak size kalmıştır. Saha verilerini analiz ederken, anlamlı sonuçlar çıkardığınızdan emin olmak için izlemeniz gereken birkaç genel kural vardır:

• Ortalamalardan kaçınınherhangi bir kullanıcının deneyimini temsil etmedikleri ve aykırı değerler tarafından çarpıtılabileceği için.
• Yüzdelik dilimlere güvenin. Zamana dayalı performans ölçümlerinin veri kümelerinde, daha düşük olan daha iyidir. Bu, düşük yüzdelik dilimlere öncelik verdiğinizde yalnızca en hızlı deneyimlere dikkat ettiğiniz anlamına gelir.
• Uzun değerler kuyruğuna öncelik verin. 75. persentil veya daha yüksek seviyedeki deneyimlere öncelik verdiğinizde, odağınızı ait olduğu yere, yani en yavaş deneyimlere koyuyorsunuz.

Bu kılavuz, Navigasyon veya Kaynak Zamanlaması konusunda ayrıntılı bir kaynak olmayıp, bir başlangıç ​​noktası olmayı amaçlamaktadır. Yararlı bulabileceğiniz bazı ek kaynaklar aşağıda verilmiştir:

Bu API’ler ve sağladıkları verilerle, yükleme performansının gerçek kullanıcılar tarafından nasıl deneyimlendiğini anlamak için daha donanımlı olacaksınız, bu da sahada yükleme performansı sorunlarını teşhis etme ve ele alma konusunda size daha fazla güven verecektir.