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

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

Jeremy Wagner

Dipublikasikan: 8 Oktober 2021

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

Pengujian sintetis tidak buruk, tetapi tidak mewakili seberapa cepat situs Anda dimuat untuk pengguna sebenarnya. Hal ini memerlukan data lapangan, yang dapat Anda kumpulkan dari Navigation Timing dan Resource Timing API.

API untuk membantu Anda menilai performa pemuatan di lapangan

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

• Navigation Timing 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 buffer 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 buffer entri performa. 'navigation' dan 'resource' mengambil waktu untuk Navigation Timing dan Resource Timing API.

Catatan: Coba muat situs, lalu masukkan salah satu perintah di cuplikan kode sebelumnya di konsol browser Anda untuk melihat waktu sebenarnya yang diambil oleh browser Anda.

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

Masa aktif dan waktu permintaan jaringan

Mengumpulkan dan menganalisis waktu navigasi dan resource seperti arkeologi karena Anda merekonstruksi masa aktif permintaan jaringan yang singkat setelah fakta. Terkadang, hal ini membantu memvisualisasikan konsep, dan jika menyangkut permintaan jaringan, alat developer browser dapat membantu.

Visualisasi permintaan jaringan di panel jaringan Chrome DevTools

Masa aktif permintaan jaringan memiliki fase yang berbeda, seperti pencarian DNS, pembuatan koneksi, negosiasi TLS, dan sumber latensi lainnya. Waktu ini direpresentasikan sebagai DOMHighResTimestamp. Bergantung pada browser Anda, granularitas waktu dapat mencapai mikrodetik, atau dibulatkan hingga milidetik. Anda harus memeriksa fase ini secara mendetail, dan bagaimana fase ini terkait dengan Navigation Timing dan Resource Timing.

Catatan: Saat Anda membaca panduan ini, diagram waktu tersedia untuk Navigation Timing dan Resource Timing yang dapat membantu Anda memvisualisasikan urutan sumber latensi permintaan.

Pencarian DNS

Saat pengguna membuka URL, Sistem Nama Domain (DNS) akan dikueri untuk menerjemahkan domain ke alamat IP. Proses ini mungkin memerlukan waktu yang signifikan—waktu yang ingin Anda ukur di lapangan. Navigation Timing dan Resource Timing mengekspos dua waktu terkait DNS:

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

Penghitungan 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;

Perhatian: Anda tidak selalu dapat mengandalkan waktu untuk diisi. Waktu yang diberikan di kedua API akan memiliki nilai 0 dalam beberapa kasus. Misalnya, pencarian DNS dapat ditayangkan oleh cache lokal. Selain itu, waktu untuk permintaan lintas origin mungkin tidak tersedia jika origin tersebut tidak menetapkan header respons Timing-Allow-Origin.

Negosiasi koneksi

Faktor lain yang berkontribusi terhadap performa pemuatan adalah negosiasi koneksi, yaitu latensi yang terjadi saat terhubung ke server web. Jika HTTPS disertakan, proses ini juga akan mencakup waktu negosiasi TLS. Fase koneksi terdiri dari tiga 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 0 jika HTTPS tidak digunakan atau jika koneksinya persisten. Jika ingin mengukur waktu negosiasi TLS, Anda harus mengingat hal berikut:

// 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, waktu yang terkait dengan pengambilan dokumen dan resource dependennya akan berlaku.

Permintaan dan respons

Performa pemuatan dipengaruhi oleh dua jenis faktor:

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

Kedua jenis faktor memengaruhi performa pemuatan. Waktu yang terkait dengan faktor ini sangat penting, karena waktu ini menjelaskan berapa lama resource didownload. 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). Hal ini mendahului permintaan sebenarnya, dan merupakan titik saat browser memeriksa cache (misalnya, instance HTTP dan Cache instance).
• 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.

Waktu ini memungkinkan Anda 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 latensi permintaan dan respons lainnya:

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

Navigation Timing dan Resource Timing berguna untuk lebih dari yang diuraikan dalam contoh sebelumnya. Berikut beberapa situasi lain dengan waktu yang relevan yang mungkin layak untuk dijelajahi:

• Pengalihan halaman: Pengalihan adalah sumber latensi tambahan yang diabaikan, terutama rantai pengalihan. Latensi ditambahkan dalam beberapa cara, seperti hop HTTP ke HTTPs, serta pengalihan 302/301 yang tidak di-cache. Waktu redirectStart, redirectEnd, dan redirectCount berguna dalam menilai latensi pengalihan.
• Pembongkaran dokumen: Di halaman yang menjalankan kode dalam unload pengendali peristiwa, browser harus menjalankan kode tersebut sebelum dapat membuka halaman berikutnya. unloadEventStart dan unloadEventEnd mengukur pembongkaran dokumen.
• Pemrosesan dokumen: Waktu pemrosesan dokumen mungkin tidak konsekuensial kecuali jika situs Anda mengirim payload HTML yang sangat besar. Jika hal ini menggambarkan situasi Anda, waktu domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, dan domComplete mungkin menarik.

Peringatan: Waktu yang terkait dengan pembongkaran dan pemrosesan dokumen hanya tersedia di Navigation Timing, karena hanya berlaku untuk permintaan navigasi.

Cara mendapatkan 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 baik jika hanya analisis ringan yang diperlukan. Namun, dalam situasi lain, metode ini dapat memperkenalkan pekerjaan thread utama yang berlebihan dengan melakukan iterasi pada sejumlah besar entri, atau bahkan berulang kali melakukan polling buffer performa untuk menemukan entri baru.

Pendekatan yang direkomendasikan untuk mengumpulkan entri dari buffer entri performa adalah 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
});

Catatan: Menambahkan opsi buffered ke peristiwa observe pengamat performa memastikan bahwa entri performa yang ditambahkan ke buffer sebelum pembuatan instance pengamat performa dapat diamati.

Metode pengumpulan waktu ini mungkin terasa canggung jika dibandingkan dengan mengakses buffer entri performa secara langsung, tetapi lebih baik daripada mengikat thread utama dengan pekerjaan yang tidak melayani tujuan penting dan berorientasi pengguna.

Cara menghubungi server

Setelah mengumpulkan semua waktu yang diperlukan, Anda dapat mengirimkannya ke endpoint untuk analisis lebih lanjut. Dua cara untuk melakukannya adalah dengan navigator.sendBeacon atau fetch dengan opsi keepalive yang ditetapkan. Kedua metode akan mengirim permintaan ke endpoint yang ditentukan dengan cara non-pemblokiran, dan permintaan 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 metrik dikumpulkan, Anda harus mencari cara untuk menganalisis data lapangan tersebut. Saat menganalisis data lapangan, ada beberapa aturan umum yang harus diikuti untuk memastikan Anda membuat kesimpulan yang bermakna:

• Hindari nilai rata-rata, karena nilai tersebut tidak mewakili pengalaman satu pengguna pun, dan mungkin miring karena nilai ekstrem.
• Andalkan persentil. Dalam set data metrik performa berbasis waktu, nilai yang lebih rendah lebih baik. Artinya, saat Anda memprioritaskan persentil rendah, Anda hanya memperhatikan pengalaman tercepat.
• Prioritaskan nilai ekor panjang. Saat Anda memprioritaskan pengalaman pada persentil ke-75 atau lebih tinggi, Anda akan berfokus pada hal yang seharusnya: pada pengalaman yang paling lambat.

Panduan ini tidak dimaksudkan sebagai resource lengkap tentang Navigation Timing atau Resource Timing, tetapi sebagai titik awal. Berikut beberapa resource tambahan yang mungkin berguna:

• Spesifikasi Navigation Timing.
• Spesifikasi Resource Timing.
• ResourceTiming dalam Praktik.
• Navigation Timing API (MDN)
• Resource Timing API (MDN)

Dengan API ini dan data yang diberikannya, Anda akan lebih siap untuk memahami bagaimana performa pemuatan dialami oleh pengguna sebenarnya, yang akan memberi Anda lebih banyak keyakinan dalam mendiagnosis dan mengatasi masalah performa pemuatan di lapangan.