Halaman bisa selesai menampilkan gambar tetapi terasa berat saat pengunjung membuka filter. Pengujian yang hanya memuat halaman tidak otomatis menemukan masalah ini. Kamu perlu melakukan interaksi yang benar-benar memicu keluhan.
INP membantu menilai respons interaksi, tetapi sebuah angka belum menjelaskan bagian aplikasi yang lambat. Pekerjaan diagnosis dimulai dengan pertanyaan sederhana: pengguna melakukan apa, pada keadaan halaman seperti apa, lalu menunggu respons visual yang mana?
Tulis skenario sebelum membuka profiler
“Tombol lambat” belum cukup. Tulis langkah yang bisa diulang orang lain. Misalnya: buka kategori dengan 200 hasil, tunggu daftar tampil, pilih rentang harga, lalu ubah urutan dua kali. Catat perangkat, ukuran data, kondisi login, dan apakah halaman baru dimuat atau sudah lama terbuka.
Uji interaksi segera setelah halaman terlihat dan ketika halaman sudah tenang. Pekerjaan JavaScript saat startup dapat bersaing dengan input pengguna. Hasil yang lancar pada komputer developer juga belum mewakili perangkat pembaca yang lebih terbatas.
Satu rekaman interaksi adalah sampel diagnosis. Jangan menamainya sebagai nilai INP seluruh website.
Pisahkan tiga jenis waktu tunggu
Interaksi dapat diuraikan menjadi input delay sebelum callback mulai berjalan, waktu pemrosesan callback, dan presentation delay hingga frame berikutnya ditampilkan. Ketiganya membutuhkan pemeriksaan berbeda. Panduan optimasi INP.
| Bagian | Gejala pada trace | Pertanyaan berikutnya |
|---|---|---|
| Input delay | Event menunggu pekerjaan lain | Apa yang memenuhi main thread sebelum klik? |
| Processing duration | Handler bekerja lama | Perhitungan atau perubahan data apa yang dijalankan? |
| Presentation delay | Handler selesai, tampilan belum diperbarui | Apakah render dan layout terlalu mahal? |
Browser menerima input bukan berarti aplikasi langsung memprosesnya. Sebaliknya, handler cepat bukan berarti tampilan sudah merespons. Perbedaan ini membantu tim menghindari perbaikan yang hanya memindahkan biaya ke tahap berikutnya.
Contoh: filter katalog menghitung semuanya ulang
Dalam contoh ilustratif, satu klik filter memiliki input delay 70 milidetik, processing duration 260 milidetik, dan presentation delay 110 milidetik. Total latensi interaksi pada sampel tersebut adalah 440 milidetik.
Trace memperlihatkan handler menghitung ulang seluruh kombinasi produk, menyusun analitik tambahan, lalu mengganti ratusan elemen. Ada setidaknya dua dugaan: terlalu banyak pekerjaan sinkron dalam handler dan pembaruan tampilan terlalu besar.
Tim dapat menguji pemisahan pekerjaan yang tidak dibutuhkan untuk respons pertama serta pembaruan komponen yang lebih terbatas. Pilih satu perubahan terlebih dahulu. Jika seluruh solusi digabung sekaligus, kamu sulit mengetahui tindakan yang membantu dan efek sampingnya.
Tetap pastikan hasil filter benar. Respons cepat yang menampilkan jumlah atau harga salah bukan hasil yang layak dirilis.
Bedakan respons awal dan selesainya tugas
Ketika tombol mengirim permintaan ke server, antarmuka dapat memberikan respons visual lebih awal sementara proses jaringan masih berjalan. Karena itu, waktu tunggu seluruh proses bisnis tidak sama dengan latensi menuju paint berikutnya.
Ukur keduanya sesuai kebutuhan: respons antarmuka dan keberhasilan tugas. Tombol yang segera berubah menjadi “memproses” tetapi permintaannya gagal tetap membutuhkan perbaikan fungsi. INP yang membaik tidak menggantikan pengujian penyelesaian transaksi atau pengiriman formulir.
Hindari pula memindahkan seluruh pekerjaan ke belakang tanpa mempertimbangkan input berikutnya. Pekerjaan tertunda masih dapat mengganggu interaksi selanjutnya.
Gunakan worksheet per interaksi
| Kolom | Isi yang perlu dicatat |
|---|---|
| Trigger | Klik, tap, atau input yang diuji |
| Keadaan halaman | Jumlah item, status login, fase pemuatan |
| Bukti | Trace, perangkat, versi aplikasi |
| Bagian dominan | Input, processing, atau presentation |
| Dugaan penyebab | Script atau komponen yang terlihat di trace |
| Perubahan | Satu tindakan yang diuji |
| Pemeriksaan fungsi | Output benar, fokus terjaga, aksi tidak terkirim ganda |
Jika trace menunjuk script pihak ketiga, uji dampaknya dalam lingkungan pengembangan atau konfigurasi pengujian yang sesuai. Jangan menghapus fungsi penting di produksi hanya untuk memperoleh angka yang terlihat baik.
Periksa ulang rangkaian, bukan satu klik saja
Sesudah perubahan, jalankan skenario yang sama beberapa kali. Lalu coba input berurutan, data kosong, hasil banyak, dan kondisi ketika permintaan sebelumnya belum selesai. Perhatikan apakah pengguna bisa menekan ulang tombol dan menghasilkan pekerjaan ganda.
Bandingkan bagian latensi dan kebenaran hasil. Jika klik pertama membaik tetapi klik berikutnya memburuk, pekerjaan mungkin hanya bergeser waktu. Gunakan pengukuran lapangan bila tersedia untuk melihat interaksi serta perangkat yang belum terwakili oleh pengujian lokal.
Tutup tiket dengan bukti perilaku yang berubah: skenario, trace, dan hasil fungsi. Dengan demikian, pembicaraan performa berhenti menjadi keluhan umum dan berubah menjadi perbaikan yang dapat dipertanggungjawabkan.
