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 telah menggunakan throttling koneksi di panel jaringan di alat developer browser (atau Lighthouse di Chrome) untuk menilai performa pemuatan, Anda tahu betapa praktisnya alat tersebut untuk melakukan penyesuaian performa. Anda dapat dengan cepat mengukur 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 buffer entri performa. 'navigation' dan 'resource' masing-masing mengambil pengaturan waktu untuk Navigation Timing API dan Resource Timing API.

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

Durasi dan pengaturan waktu permintaan jaringan

Mengumpulkan dan menganalisis waktu navigasi dan resource mirip dengan arkeologi karena Anda merekonstruksi masa aktif singkat permintaan jaringan setelah kejadian. 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 pengaturan waktu dapat sampai ke mikrodetik, atau dibulatkan ke milidetik. Anda perlu memeriksa fase ini secara mendetail, dan bagaimana kaitannya dengan Waktu Navigasi dan Resource Timing.

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. Navigation Timing dan Resource Timing menampilkan 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 pada performa pemuatan adalah negosiasi koneksi, yaitu latensi yang terjadi 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 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, pengaturan waktu yang terkait dengan pengambilan dokumen dan resource dependennya akan diterapkan.

Permintaan dan respons

Performa pemuatan dipengaruhi oleh dua jenis faktor:

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

Kedua jenis faktor tersebut memengaruhi performa pemuatan. Waktu yang terkait dengan faktor-faktor ini sangat penting, karena menjelaskan waktu yang diperlukan untuk mendownload resource. Waktu Navigasi dan Waktu Resource 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 beberapa situasi lain dengan pengaturan waktu yang relevan yang mungkin perlu dipelajari:

  • Pengalihan halaman: Pengalihan adalah sumber latensi tambahan yang sering diabaikan, terutama rantai pengalihan. Latensi ditambahkan dengan sejumlah cara, seperti hop HTTP-ke-HTTPs, serta pengalihan 302/301 yang tidak di-cache. Pengaturan waktu redirectStart, redirectEnd, dan redirectCount membantu dalam menilai latensi pengalihan.
  • Penghapusan 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 berdampak kecuali jika situs Anda mengirim 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 buffering entri performa, seperti performance.getEntriesByName dan performance.getEntries. Metode ini tidak masalah jika hanya diperlukan analisis ringan. Namun, dalam situasi lain, hal ini dapat menyebabkan pekerjaan thread utama yang berlebihan dengan melakukan iterasi pada sejumlah besar entri, atau bahkan berulang kali melakukan polling pada buffering 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
});

Metode pengumpulan waktu ini mungkin terasa canggung jika dibandingkan dengan mengakses langsung buffer entri performa, tetapi lebih baik mengaitkan thread utama dengan pekerjaan yang tidak memiliki tujuan penting dan bagi 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 akan mengirim permintaan ke endpoint yang ditentukan dengan cara yang tidak memblokir, 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 mengumpulkan metrik, Anda dapat menentukan cara menganalisis data kolom tersebut. Saat menganalisis data lapangan, 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.
  • Mengandalkan persentil. Dalam set data metrik performa berbasis waktu, semakin rendah semakin baik. Artinya, saat memprioritaskan persentil rendah, Anda hanya memperhatikan pengalaman tercepat.
  • Prioritaskan longtail nilai. Saat Anda memprioritaskan pengalaman di persentil ke-75 atau lebih tinggi, Anda menempatkan fokus pada tempatnya: pada pengalaman yang paling lambat.

Panduan ini tidak dimaksudkan sebagai referensi 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 disediakannya, 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.