Kita semua pernah mendengar betapa pentingnya performa. Namun, ketika membahas performa dan cara membuat situs "cepat", apa yang dimaksud dengan 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 dapat selesai dimuat dalam waktu yang sama persis, tetapi salah satunya mungkin tampak dimuat lebih cepat (jika situs memuat konten secara bertahap, bukan menunggu sampai akhir menampilkan apa pun).
- Situs mungkin tampak dimuat dengan cepat, tetapi kemudian merespons dengan lambat (atau tidak merespons sama sekali) terhadap interaksi pengguna.
Saat berbicara tentang performa, pastikan untuk akurat dan merujuk pada performa dalam hal metrics. Kriteria objektif yang dapat diukur secara kuantitatif, tetapi juga penting untuk memastikan metrik yang Anda ukur berguna.
Menentukan metrik
Sebelumnya, performa web telah diukur dengan peristiwa load. Namun, meskipun load adalah momen yang didefinisikan dengan baik dalam siklus proses halaman, momen tersebut tidak selalu sesuai dengan apa pun yang menjadi perhatian pengguna.
Misalnya, server dapat merespons dengan halaman minimal yang segera "dimuat", tetapi kemudian menunda pengambilan konten atau menampilkan apa pun di halaman hingga beberapa detik setelah peristiwa load diaktifkan. Halaman seperti itu secara teknis memiliki waktu muat yang cepat, tetapi waktu tersebut tidak sesuai dengan pengalaman pengguna saat memuat halaman.
Selama beberapa tahun terakhir, anggota tim Chrome—bekerja sama dengan W3C Web Performance Working Group—telah berupaya menstandarkan kumpulan API dan metrik baru yang lebih akurat dalam mengukur pengalaman pengguna terkait performa halaman web.
Untuk membantu memastikan metrik relevan bagi pengguna, kami membingkainya dengan beberapa pertanyaan penting:
| Apakah ada? | Apakah navigasi berhasil dimulai? Sudahkah server merespons? |
| Apakah ini bermanfaat? | Apakah ada cukup konten yang dirender sehingga pengguna dapat berinteraksi dengan konten tersebut? |
| Apakah dapat digunakan? | Apakah pengguna dapat berinteraksi dengan halaman, atau apakah halaman sedang sibuk? |
| Apakah menyenangkan? | Apakah interaksinya lancar dan alami, tanpa jeda? |
Cara metrik diukur
Metrik performa umumnya diukur dengan salah satu dari dua cara berikut:
- Di lab: menggunakan alat untuk menyimulasikan pemuatan halaman dalam lingkungan yang konsisten dan terkontrol
- Di lapangan: pada pengguna nyata yang benar-benar memuat dan berinteraksi dengan halaman
Tak satu pun dari opsi ini yang lebih baik atau lebih buruk daripada yang lain—bahkan, Anda biasanya ingin menggunakan keduanya untuk memastikan kinerja yang baik.
Di laboratorium
Menguji performa di lab sangat penting ketika mengembangkan fitur baru. Sebelum fitur dirilis dalam produksi, karakteristik performanya tidak dapat diukur pada pengguna sungguhan. Jadi, mengujinya di lab sebelum fitur ini dirilis adalah cara terbaik untuk mencegah regresi performa.
Di lapangan
Di sisi lain, meskipun pengujian di lab adalah proxy yang wajar untuk performa, pengujian ini tidak selalu mencerminkan pengalaman pengguna yang sebenarnya di situs Anda.
Performa situs dapat sangat bervariasi berdasarkan kemampuan perangkat pengguna dan kondisi jaringannya. Jumlah ini juga dapat bervariasi berdasarkan apakah (atau bagaimana) pengguna berinteraksi dengan halaman.
Pemuatan halaman juga tidak selalu menentukan. Misalnya, situs yang memuat konten atau iklan yang dipersonalisasi dapat memiliki karakteristik performa yang sangat berbeda antara satu pengguna dengan pengguna lainnya. Uji 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. Jenis pengukuran ini biasanya disebut Pemantauan Pengguna Nyata (RUM).
Jenis metrik
Ada beberapa jenis metrik lain yang relevan dengan cara pengguna mempersepsi performa.
- Persepsi kecepatan pemuatan: seberapa cepat halaman dapat memuat dan merender semua elemen visualnya ke layar.
- Responsivitas beban: seberapa cepat halaman dapat memuat dan mengeksekusi kode JavaScript yang diperlukan agar komponen dapat merespons interaksi pengguna dengan cepat
- Responsivitas runtime: setelah halaman dimuat, 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?
- Kelancaran: apakah transisi dan animasi dirender pada kecepatan frame yang konsisten dan mengalir dengan lancar dari satu status ke status berikutnya?
Dengan mempertimbangkan semua jenis metrik performa ini, diharapkan sudah jelas bahwa tidak ada satu pun metrik yang cukup untuk menangkap semua karakteristik performa halaman.
Metrik penting untuk diukur
- First Contentful Paint (FCP): mengukur waktu dari saat halaman mulai dimuat hingga saat ada bagian konten halaman yang dirender di layar. (lab, kolom)
- Largest Contentful Paint (LCP): mengukur waktu dari saat halaman mulai dimuat hingga saat blok teks atau elemen gambar terbesar dirender di layar. (lab, kolom)
- Interaction to Next Paint (INP): mengukur latensi setiap ketukan, klik, atau interaksi keyboard yang dilakukan dengan halaman, dan—berdasarkan jumlah interaksi—memilih latensi interaksi terburuk halaman (atau mendekati tertinggi) sebagai satu nilai representatif untuk menjelaskan responsivitas halaman secara keseluruhan. (lab, kolom)
- Total Waktu Pemblokiran (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 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)
Dalam beberapa kasus, metrik baru akan diperkenalkan untuk mencakup area yang belum ada, tetapi dalam kasus lain, metrik terbaik adalah metrik yang secara khusus disesuaikan dengan situs Anda.
Metrik kustom
Metrik kinerja yang dibahas sebelumnya berguna untuk mendapatkan pemahaman umum tentang karakteristik kinerja sebagian besar situs di web. Metrik ini juga bagus karena memiliki kumpulan metrik umum untuk situs guna membandingkan performa mereka terhadap pesaing.
Namun, ada kalanya situs tertentu bersifat unik dalam beberapa hal sehingga memerlukan metrik tambahan agar dapat memperoleh gambaran performa lengkap. Misalnya, metrik LCP dimaksudkan untuk mengukur kapan konten utama suatu 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 menstandardisasi 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 tentang Metrik Kustom untuk mempelajari cara menggunakan API ini guna mengukur karakteristik performa khusus untuk situs Anda.