Kita semua telah mendengar betapa pentingnya performa. Namun, saat kita berbicara tentang performa, dan tentang cara membuat situs "cepat", apa yang dimaksud secara spesifik?
Faktanya, performa bersifat relatif:
- Situs mungkin cepat untuk satu pengguna (di jaringan cepat dengan perangkat canggih), tetapi lambat untuk pengguna lain (di jaringan lambat dengan perangkat kelas bawah).
- Dua situs mungkin selesai dimuat dalam waktu yang sama persis, tetapi salah satunya mungkin tampak dimuat lebih cepat (jika memuat konten secara bertahap, bukan menunggu hingga akhir untuk menampilkan apa pun).
- Situs mungkin tampak dimuat dengan cepat, tetapi kemudian merespons interaksi pengguna dengan lambat (atau tidak sama sekali).
Saat membahas performa, penting untuk bersikap akurat dan merujuk pada performa dalam hal metrik. Kriteria objektif yang dapat diukur secara quantitative, tetapi penting juga untuk memastikan metrik yang Anda ukur berguna.
Menentukan metrik
Secara historis, performa web telah diukur dengan peristiwa load. Namun, meskipun load adalah momen yang ditentukan dengan baik dalam siklus proses halaman, momen tersebut tidak selalu sesuai dengan hal yang dipedulikan pengguna.
Misalnya, server dapat merespons dengan halaman minimal yang langsung "dimuat", tetapi kemudian menunda pengambilan konten atau menampilkan apa pun di halaman hingga beberapa detik setelah peristiwa load diaktifkan. Halaman tersebut secara teknis memiliki waktu pemuatan yang cepat, tetapi waktu tersebut tidak sesuai dengan pengalaman pengguna saat halaman dimuat.
Selama beberapa tahun terakhir, anggota tim Chrome—berkolaborasi dengan W3C Web Performance Working Group—telah berupaya menstandarkan serangkaian API dan metrik baru yang mengukur pengalaman pengguna terhadap performa halaman web secara lebih akurat.
Untuk membantu memastikan metrik relevan bagi pengguna, kami menyusunnya berdasarkan beberapa pertanyaan penting:
| Apakah hal itu terjadi? | Apakah navigasi berhasil dimulai? Apakah server telah merespons? |
| Apakah ini berguna? | Apakah sudah cukup konten yang dirender sehingga pengguna dapat berinteraksi dengannya? |
| Apakah dapat digunakan? | Dapatkah pengguna berinteraksi dengan halaman, atau apakah halaman tersebut sibuk? |
| Apakah menyenangkan? | Apakah interaksinya lancar dan alami, tanpa jeda? |
Cara pengukuran metrik
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 lapangan: pada pengguna sungguhan yang benar-benar memuat dan berinteraksi dengan halaman
Kedua opsi ini tidak selalu lebih baik atau lebih buruk daripada yang lain—sebenarnya 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, Anda tidak dapat mengukur karakteristik performanya 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, pengujian tersebut tidak selalu mencerminkan pengalaman pengguna sebenarnya di situs Anda.
Performa situs dapat bervariasi secara drastis berdasarkan kemampuan perangkat pengguna dan kondisi jaringannya. Hal ini juga dapat bervariasi berdasarkan apakah (atau bagaimana) pengguna berinteraksi dengan halaman.
Pemuatan halaman juga tidak selalu deterministik. Misalnya, situs yang memuat konten atau iklan yang dipersonalisasi dapat mengalami karakteristik performa yang sangat berbeda dari satu pengguna ke pengguna lainnya. Pengujian lab tidak akan menangkap perbedaan tersebut.
Satu-satunya cara untuk benar-benar mengetahui performa situs Anda bagi pengguna adalah dengan benar-benar mengukur performanya saat pengguna memuat dan berinteraksi dengan situs tersebut. Jenis pengukuran ini biasanya disebut Pemantauan Pengguna Sebenarnya (RUM).
Jenis metrik
Ada beberapa jenis metrik lain yang relevan dengan cara pengguna melihat performa.
- Kecepatan pemuatan yang dirasakan: seberapa cepat halaman dapat memuat dan merender semua elemen visualnya ke layar.
- Responsivitas pemuatan: seberapa cepat halaman dapat memuat dan menjalankan 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 di halaman bergeser dengan cara yang tidak diharapkan pengguna dan berpotensi mengganggu interaksi mereka?
- Kehalusan: apakah transisi dan animasi dirender dengan kecepatan frame yang konsisten dan mengalir dengan lancar dari satu status ke status berikutnya?
Dengan semua jenis metrik performa ini, semoga jelas bahwa tidak ada satu metrik yang memadai untuk menangkap semua karakteristik performa halaman.
Metrik penting yang harus diukur
- First Contentful Paint (FCP): mengukur waktu dari saat halaman mulai dimuat hingga bagian mana pun dari konten halaman dirender di layar. (lab, lapangan)
- Largest Contentful Paint (LCP): mengukur waktu dari saat halaman mulai dimuat hingga saat blok teks atau elemen gambar terbesar dirender di layar. (lab, lapangan)
- Interaction to Next Paint (INP): mengukur latensi setiap interaksi ketuk, klik, atau keyboard yang dilakukan dengan halaman, dan—berdasarkan jumlah interaksi—memilih latensi interaksi terburuk halaman (atau mendekati tertinggi) sebagai satu nilai perwakilan untuk mendeskripsikan responsivitas keseluruhan halaman. (lab, lapangan)
- Total Blocking Time (TBT): mengukur jumlah total waktu antara FCP dan TTI, tempat thread utama diblokir cukup lama untuk mencegah responsivitas input. (lab)
- Pergeseran Tata Letak Kumulatif (CLS): mengukur skor kumulatif dari semua pergeseran tata letak tidak terduga yang terjadi antara saat halaman mulai dimuat dan saat status siklus prosesnya berubah menjadi tersembunyi. (lab, lapangan)
- Time to First Byte (TTFB): mengukur waktu yang diperlukan jaringan untuk merespons permintaan pengguna dengan byte pertama resource. (lab, lapangan)
Dalam beberapa kasus, metrik baru akan diperkenalkan untuk mencakup area yang tidak ada, tetapi dalam kasus lain, metrik terbaik adalah metrik yang disesuaikan secara khusus untuk situs Anda.
Metrik kustom
Metrik performa yang telah dibahas sebelumnya bagus untuk mendapatkan pemahaman umum tentang karakteristik performa sebagian besar situs di web. Metrik ini juga bagus untuk memiliki kumpulan metrik umum bagi situs untuk membandingkan performanya dengan pesaing.
Namun, terkadang situs tertentu memiliki karakteristik unik yang memerlukan metrik tambahan untuk mendapatkan gambaran performa yang lengkap. Misalnya, metrik LCP dimaksudkan untuk mengukur kapan konten utama halaman selesai dimuat, tetapi mungkin ada kasus saat elemen terbesar bukan 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
- Long Tasks API
- Long Animation Frames API
- Element Timing API
- Navigation Timing API
- Resource Timing API
- Waktu server
Lihat panduan tentang Metrik Kustom untuk mempelajari cara menggunakan API ini guna mengukur karakteristik performa khusus untuk situs Anda.