Cara menilai performa pemuatan di lapangan dengan Navigation Timing dan Resource Timing

Pelajari dasar-dasar penggunaan Navigation dan Resource Timing API untuk menilai performa pemuatan di lapangan.

Jeremy Wagner

Dipublikasikan: 8 Oktober 2021

Jika Anda telah menggunakan throttling koneksi di panel jaringan pada alat developer browser (atau Lighthouse di Chrome) untuk menilai performa pemuatan, Anda akan mengetahui seberapa praktis alat tersebut untuk penyesuaian performa. Anda dapat mengukur dengan cepat dampak pengoptimalan performa dengan kecepatan koneksi dasar pengukuran yang konsisten dan stabil. Satu-satunya masalah adalah ini adalah pengujian sintetis, yang menghasilkan data lab, bukan data lapangan.

Pengujian sintetis tidak secara inheren buruk, tetapi tidak mewakili seberapa cepat situs Anda dimuat bagi pengguna yang sebenarnya. Cara ini memerlukan data kolom, yang dapat Anda kumpulkan dari Navigation Timing and Resource Timing API.

API untuk membantu Anda menilai performa pemuatan di lapangan

Navigation Timing dan Resource Timing adalah dua API serupa dengan tumpang-tindih yang signifikan yang mengukur dua hal yang berbeda:

  • Waktu Navigasi mengukur kecepatan permintaan untuk dokumen HTML (yaitu, permintaan navigasi).
  • Resource Timing mengukur kecepatan permintaan untuk resource yang bergantung pada dokumen seperti CSS, JavaScript, gambar, dan jenis resource lainnya.

API ini mengekspos datanya dalam buffer entri performa, yang dapat diakses di browser dengan JavaScript. Ada beberapa cara untuk membuat kueri buffering performa, tetapi cara yang umum adalah dengan menggunakan performance.getEntriesByType:

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

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

performance.getEntriesByType menerima string yang menjelaskan jenis entri yang ingin Anda ambil dari buffering entri performa. 'navigation' dan 'resource' masing-masing mengambil pengaturan waktu untuk Navigation Timing API dan Resource Timing API.

Jumlah informasi yang diberikan API ini bisa sangat melelahkan, tetapi ini adalah kunci Anda untuk mengukur performa pemuatan di lapangan, karena Anda dapat mengumpulkan waktu ini dari pengguna saat mereka mengunjungi situs Anda.

Durasi dan pengaturan waktu permintaan jaringan

Mengumpulkan dan menganalisis pengaturan waktu navigasi dan sumber daya adalah semacam arkeologi saat Anda merekonstruksi kehidupan singkat permintaan jaringan setelah fakta terjadi. Terkadang ada baiknya memvisualisasikan konsep, dan jika ada permintaan jaringan yang diperhatikan, alat developer browser Anda dapat membantu.

Pengaturan waktu jaringan seperti yang ditampilkan di DevTools Chrome. Waktu yang digambarkan adalah untuk antrean permintaan, negosiasi koneksi, permintaan itu sendiri, dan respons dalam batang berkode warna.
Visualisasi permintaan jaringan di panel jaringan Chrome DevTools

Siklus proses permintaan jaringan memiliki fase yang berbeda, seperti pencarian DNS, pembuatan koneksi, negosiasi TLS, dan sumber latensi lainnya. Pengaturan waktu ini direpresentasikan sebagai DOMHighResTimestamp. Bergantung pada browser Anda, perincian waktu dapat diturunkan hingga ke mikrodetik, atau dibulatkan ke milidetik. Sebaiknya periksa fase ini secara mendetail, dan bagaimana fase ini terkait dengan Waktu Navigasi dan Waktu Resource.

pencarian DNS

Saat pengguna membuka URL, Domain Name System (DNS) akan dikueri untuk menerjemahkan domain ke alamat IP. Proses ini mungkin memerlukan waktu yang cukup lama—bahkan waktu yang ingin Anda ukur di lapangan. Waktu Navigasi dan Resource Timing mengekspos dua pengaturan waktu terkait DNS:

  • domainLookupStart adalah saat pencarian DNS dimulai.
  • domainLookupEnd adalah saat pencarian DNS berakhir.

Menghitung total waktu pencarian DNS dapat dilakukan dengan mengurangi metrik awal dari metrik akhir:

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

Negosiasi koneksi

Faktor lain yang berkontribusi terhadap performa pemuatan adalah negosiasi koneksi, yaitu latensi yang timbul saat terhubung ke server web. Jika HTTPS terlibat, proses ini juga akan mencakup waktu negosiasi TLS. Fase koneksi terdiri dari tiga pengaturan waktu:

  • connectStart adalah saat browser mulai membuka koneksi ke server web.
  • secureConnectionStart menandai saat klien memulai negosiasi TLS.
  • connectEnd adalah saat koneksi ke server web telah dibuat.

Mengukur total waktu koneksi mirip dengan mengukur total waktu pencarian DNS: Anda mengurangi waktu mulai dari waktu akhir. Namun, ada properti secureConnectionStart tambahan yang mungkin berupa 0 jika HTTPS tidak digunakan atau jika koneksi bersifat persisten. Jika Anda ingin mengukur waktu negosiasi TLS, Anda harus memperhatikan hal tersebut:

// Quantifying total connection time
const [pageNav] = performance.getEntriesByType('navigation');
const connectionTime = pageNav.connectEnd - pageNav.connectStart;
let tlsTime = 0; // <-- Assume 0 to start with

// Was there TLS negotiation?
if (pageNav.secureConnectionStart > 0) {
  // Awesome! Calculate it!
  tlsTime = pageNav.connectEnd - pageNav.secureConnectionStart;
}

Setelah pencarian DNS dan negosiasi koneksi berakhir, pengaturan waktu yang terkait dengan pengambilan dokumen dan resource dependennya akan diterapkan.

Permintaan dan respons

Performa pemuatan dipengaruhi oleh dua jenis faktor:

  • Faktor eksternal: Faktor ini mencakup latensi dan bandwidth. Selain memilih perusahaan hosting dan mungkin CDN, mereka (sebagian besar) berada di luar kendali kami, karena pengguna dapat mengakses web dari mana saja.
  • Faktor intrinsik: Faktor intrinsik adalah hal-hal seperti arsitektur server dan sisi klien, serta ukuran resource dan kemampuan kami untuk mengoptimalkan hal-hal tersebut, yang berada dalam kendali kita.

Kedua jenis faktor ini memengaruhi performa pemuatan. Waktu yang terkait dengan faktor-faktor ini sangat penting, karena menjelaskan waktu yang diperlukan untuk mendownload resource. Navigation Timing dan Resource Timing menjelaskan performa pemuatan dengan metrik berikut:

  • fetchStart menandai saat browser mulai mengambil resource (Resource Timing) atau dokumen untuk permintaan navigasi (Navigation Timing). Ini mendahului permintaan sebenarnya, dan merupakan titik saat browser memeriksa cache (misalnya, HTTP dan instance Cache).
  • workerStart menandai saat permintaan mulai ditangani dalam pengendali peristiwa fetch pekerja layanan. Nilai ini akan menjadi 0 jika tidak ada pekerja layanan yang mengontrol halaman saat ini.
  • requestStart adalah saat browser membuat permintaan.
  • responseStart adalah saat byte pertama respons tiba.
  • responseEnd adalah saat byte terakhir respons tiba.

Dengan pengaturan waktu ini, Anda dapat mengukur beberapa aspek performa pemuatan, seperti pencarian cache dalam pekerja layanan dan waktu download:

// 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;
}

Anda juga dapat mengukur aspek lain dari latensi permintaan dan respons:

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;

Pengukuran lain yang dapat Anda lakukan

Waktu Navigasi dan Waktu Resource berguna untuk lebih dari yang diuraikan dalam contoh sebelumnya. Berikut ini beberapa situasi lain dengan pengaturan waktu relevan yang mungkin patut dicoba:

  • Pengalihan halaman: Pengalihan adalah sumber latensi tambahan yang sering diabaikan, terutama rantai pengalihan. Latensi ditambahkan dengan berbagai cara, seperti hop HTTP-ke-HTTPs, serta pengalihan 301 302/tidak disimpan dalam cache. Pengaturan waktu redirectStart, redirectEnd, dan redirectCount berguna dalam menilai latensi pengalihan.
  • Pemuatan dokumen: Di halaman yang menjalankan kode di pengendali peristiwa unload, browser harus mengeksekusi kode tersebut sebelum dapat membuka halaman berikutnya. unloadEventStart dan unloadEventEnd mengukur penghapusan dokumen.
  • Pemrosesan dokumen: Waktu pemrosesan dokumen mungkin tidak penting, kecuali jika situs Anda mengirimkan payload HTML yang sangat besar. Jika sesuai dengan situasi Anda, pengaturan waktu domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, dan domComplete mungkin sesuai untuk Anda.

Cara mendapatkan pengaturan waktu dalam kode Anda

Semua contoh yang ditampilkan sejauh ini menggunakan performance.getEntriesByType, tetapi ada cara lain untuk membuat kueri buffer entri performa, seperti performance.getEntriesByName dan performance.getEntries. Metode ini tidak masalah jika hanya diperlukan analisis ringan. Namun, dalam situasi lain, mereka dapat menyebabkan pekerjaan thread utama yang berlebihan dengan melakukan iterasi pada sejumlah besar entri, atau bahkan berulang kali melakukan polling pada buffer performa untuk menemukan entri baru.

Pendekatan yang direkomendasikan untuk mengumpulkan entri dari buffering entri performa adalah dengan menggunakan PerformanceObserver. PerformanceObserver memproses entri performa, dan menyediakannya saat ditambahkan ke buffer:

// 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
});

Metode pengumpulan pengaturan waktu ini mungkin terasa canggung jika dibandingkan dengan mengakses buffer entri performa secara langsung, tetapi sebaiknya Anda tidak mengaitkan thread utama dengan tugas yang tidak melayani tujuan penting dan yang ditampilkan kepada pengguna.

Cara menelepon ke rumah

Setelah mengumpulkan semua pengaturan waktu yang diperlukan, Anda dapat mengirimkannya ke endpoint untuk analisis lebih lanjut. Ada dua cara untuk melakukannya, yaitu dengan navigator.sendBeacon atau fetch dengan opsi keepalive yang ditetapkan. Kedua metode tersebut akan mengirimkan permintaan ke endpoint tertentu dengan cara yang tidak memblokir, dan permintaan tersebut akan diantrekan dengan cara yang lebih lama dari sesi halaman saat ini jika diperlukan:

// Check for navigator.sendBeacon support:
if ('sendBeacon' in navigator) {
  // 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());

  // Send the data!
  navigator.sendBeacon('/analytics', data);
}

Dalam contoh ini, string JSON akan tiba dalam payload POST yang dapat Anda dekode, proses, dan simpan di backend aplikasi sesuai kebutuhan.

Kesimpulan

Setelah mengumpulkan metrik, Anda dapat menentukan cara menganalisis data kolom tersebut. Saat menganalisis data {i>field<i}, ada beberapa aturan umum yang harus diikuti untuk memastikan Anda menarik kesimpulan yang bermakna:

  • Hindari rata-rata, karena tidak mewakili pengalaman pengguna mana pun, dan dapat dibelokkan oleh outlier.
  • Andalkan persentil. Dalam set data metrik performa berbasis waktu, semakin rendah semakin baik. Ini berarti bahwa ketika Anda memprioritaskan persentil rendah, Anda hanya memperhatikan pengalaman yang paling cepat.
  • Prioritaskan longtail nilai. Jika memprioritaskan pengalaman pada persentil ke-75 atau lebih tinggi, Anda akan memfokuskan perhatian pada hal yang seharusnya: pengalaman yang paling lambat.

Panduan ini tidak dimaksudkan sebagai sumber lengkap tentang Navigasi atau Resource Timing, tetapi sebagai titik awal. Berikut beberapa referensi tambahan yang mungkin berguna bagi Anda:

Dengan API ini dan data yang diberikannya, Anda akan lebih siap untuk memahami bagaimana performa pemuatan dialami oleh pengguna nyata, yang akan membuat Anda lebih percaya diri dalam mendiagnosis dan mengatasi masalah performa pemuatan di lapangan.