Metrik performa yang berfokus pada pengguna

Philip Walton

Kita semua pernah mendengar betapa pentingnya performa. Namun, saat berbicara tentang performa—dan tentang membuat situs menjadi "cepat"—apa sebenarnya yang kami maksud?

Yang benar adalah performa itu relatif:

• Situs mungkin cepat untuk satu pengguna (pada jaringan cepat dengan perangkat canggih), tetapi lambat untuk pengguna lainnya (pada jaringan lambat dengan perangkat kelas bawah).
• Dua situs dapat selesai dimuat dalam waktu yang sama persis, tetapi salah satunya mungkin tampak dimuat lebih cepat (jika situs dimuat secara bertahap, bukan menunggu hingga selesai untuk menampilkan apa pun).
• Situs mungkin muncul untuk dimuat dengan cepat, tetapi kemudian merespons interaksi pengguna dengan lambat (atau tidak sama sekali).

Jadi, ketika berbicara tentang performa, yang penting harus tepat dan merujuk pada performa dalam hal kriteria objektif yang dapat diukur secara kuantitatif. Kriteria ini dikenal sebagai metrics.

Namun, hanya karena metrik didasarkan pada kriteria objektif dan dapat diukur secara kuantitatif, bukan berarti pengukuran tersebut berguna.

Menentukan metrik

Secara historis, performa web telah diukur dengan peristiwa load. Namun, meskipun load adalah momen yang didefinisikan dengan baik dalam siklus proses halaman, momen tersebut belum tentu berkaitan dengan apa pun yang menjadi perhatian pengguna.

Misalnya, server dapat merespons dengan halaman minimal yang segera "dimuat", tetapi kemudian menunda pengambilan konten dan menampilkan apa pun di halaman hingga beberapa detik setelah peristiwa load diaktifkan. Meskipun halaman tersebut secara teknis memiliki waktu pemuatan yang cepat, waktu tersebut tidak sama dengan pengalaman pemuatan halaman yang sebenarnya dialami pengguna.

Selama beberapa tahun terakhir, anggota tim Chrome—yang berkolaborasi dengan W3C Web Performance Working Group—telah berupaya menstandarkan serangkaian API dan metrik baru yang lebih akurat untuk mengukur pengalaman pengguna terhadap performa halaman web.

Untuk membantu memastikan metrik tersebut relevan bagi pengguna, kami membingkainya dengan beberapa pertanyaan utama:

Cara metrik diukur

Metrik performa umumnya diukur dengan salah satu dari dua cara berikut:

• Di lab: menggunakan alat untuk menyimulasikan pemuatan halaman di lingkungan yang konsisten dan terkontrol
• Di kolom: pada pengguna sungguhan yang benar-benar memuat dan berinteraksi dengan halaman

Tak satu pun dari opsi ini yang lebih baik atau lebih buruk daripada yang lain—faktanya, Anda biasanya ingin menggunakan keduanya untuk memastikan performa yang baik.

Di laboratorium

Menguji performa di lab sangat penting saat mengembangkan fitur baru. Sebelum fitur dirilis dalam produksi, karakteristik performanya tidak dapat diukur pada pengguna sungguhan. Jadi, mengujinya di lab sebelum fitur dirilis adalah cara terbaik untuk mencegah regresi performa.

Di lapangan

Di sisi lain, meskipun pengujian di lab adalah proxy yang wajar untuk performa, hal ini tidak selalu mencerminkan pengalaman semua pengguna di situs Anda.

Performa situs dapat sangat bervariasi berdasarkan kemampuan perangkat pengguna dan kondisi jaringannya. Hal ini juga dapat bervariasi berdasarkan apakah (atau cara) pengguna berinteraksi dengan halaman.

Selain itu, pemuatan halaman mungkin tidak bersifat determenistik. Misalnya, situs yang memuat konten atau iklan yang dipersonalisasi mungkin mengalami karakteristik performa yang sangat berbeda dari satu pengguna ke pengguna lainnya. Pengujian lab tidak akan menangkap perbedaan tersebut.

Satu-satunya cara untuk mengetahui performa situs Anda bagi pengguna adalah dengan benar-benar mengukur performanya saat pengguna tersebut memuat dan berinteraksi dengan situs tersebut. Jenis pengukuran ini umumnya disebut sebagai Real User Monitoring—atau disingkat RUM.

Jenis metrik

Ada beberapa jenis metrik lain yang relevan dengan persepsi pengguna terhadap performa.

• Kecepatan pemuatan yang dirasakan: seberapa cepat halaman dapat memuat dan merender semua elemen visualnya ke layar.
• Kecepatan respons pemuatan: seberapa cepat halaman dapat memuat dan mengeksekusi kode JavaScript yang diperlukan agar komponen dapat merespons interaksi pengguna dengan cepat
• Responsivitas runtime: setelah pemuatan halaman, seberapa cepat halaman dapat merespons interaksi pengguna.
• Stabilitas visual: apakah elemen pada halaman berubah dengan cara yang tidak diharapkan pengguna dan berpotensi mengganggu interaksi mereka?
• Kehalusan: apakah transisi dan animasi dirender pada kecepatan frame yang konsisten dan mengalir dengan lancar dari satu status ke status berikutnya?

Dengan semua jenis metrik performa di atas, mudah-mudahan jelas bahwa tidak ada satu metrik yang cukup untuk menangkap semua karakteristik performa sebuah halaman.

Metrik penting untuk diukur

• First Contentful Paint (FCP): mengukur waktu dari saat halaman mulai dimuat hingga saat bagian konten halaman dirender di layar. (lab, kolom)
• Largest Contentful Paint (LCP): mengukur waktu dari saat halaman mulai dimuat hingga blok teks atau elemen gambar terbesar dirender di layar. (lab, kolom)
• Penundaan Input Pertama (FID): mengukur waktu dari saat pengguna pertama kali berinteraksi dengan situs Anda (saat mereka mengklik link, mengetuk tombol, atau menggunakan kontrol kustom yang didukung JavaScript) hingga saat browser benar-benar dapat merespons interaksi tersebut. (kolom)
• Interaction to Next Paint (INP): mengukur latensi setiap ketukan, klik, atau interaksi keyboard yang dilakukan pada halaman, dan—berdasarkan jumlah interaksi—memilih latensi interaksi terburuk pada halaman (atau mendekati yang tertinggi) sebagai nilai representatif tunggal untuk mendeskripsikan responsivitas halaman secara keseluruhan. (lab, kolom)
• Total Blocking Time (TBT): mengukur jumlah total waktu antara FCP dan TTI saat thread utama diblokir cukup lama untuk mencegah responsivitas input. (lab)
• Pergeseran Tata Letak Kumulatif (CLS): mengukur skor kumulatif semua pergeseran tata letak tidak terduga yang terjadi antara saat halaman mulai dimuat dan saat status siklus proses-nya berubah menjadi tersembunyi. (lab, kolom)
• Time to First Byte (TTFB): mengukur waktu yang diperlukan jaringan untuk merespons permintaan pengguna dengan byte pertama resource. (lab, kolom)

Meskipun daftar ini mencakup metrik yang mengukur banyak dari berbagai aspek performa yang relevan bagi pengguna, daftar ini tidak mencakup semuanya. Misalnya, responsivitas dan kelancaran runtime saat ini tidak tercakup.

Dalam beberapa kasus, metrik baru akan diperkenalkan untuk mencakup area yang tidak ada, tetapi dalam kasus lain, metrik terbaik adalah metrik yang secara khusus disesuaikan dengan situs Anda.

Metrik kustom

Metrik performa yang tercantum di atas berguna untuk mendapatkan pemahaman umum tentang karakteristik performa pada sebagian besar situs di web. Performa Maksimal juga bagus untuk memiliki sekumpulan metrik umum bagi situs untuk membandingkan performanya dengan pesaing.

Namun, terkadang situs tertentu bersifat unik sehingga memerlukan metrik tambahan agar dapat memberikan gambaran performa lengkap. Misalnya, metrik LCP dimaksudkan untuk mengukur kapan konten utama halaman telah selesai dimuat, tetapi mungkin ada kasus saat elemen terbesar bukan merupakan bagian dari konten utama halaman sehingga LCP mungkin tidak relevan.

Untuk mengatasi kasus tersebut, Web Performance Working Group juga telah menstandarkan API tingkat rendah yang dapat berguna untuk menerapkan metrik kustom Anda sendiri:

• User Timing API
• API Tugas Panjang
• Element Timing API
• Navigation Timing API
• Resource Timing API
• Waktu server

Lihat panduan di Metrik Kustom untuk mempelajari cara menggunakan API ini guna mengukur karakteristik performa khusus untuk situs Anda.