Diagnosis interaksi lambat di lab secara manual

Pelajari cara membawa data lapangan Anda ke lab untuk mereproduksi dan mengidentifikasi penyebab di balik interaksi yang lambat melalui pengujian manual.

Jeremy Wagner

Bagian sulit dari pengoptimalan Interaction to Next Paint (INP) adalah mencari tahu penyebab INP buruk. Ada banyak potensi penyebab, seperti skrip pihak ketiga yang menjadwalkan banyak tugas di thread utama, ukuran DOM besar, callback peristiwa yang mahal, dan penyebab lainnya.

Meningkatkan INP bisa jadi sulit. Untuk memulai, Anda harus mengetahui interaksi mana yang cenderung menyebabkan INP halaman. Jika tidak mengetahui interaksi mana di situs Anda yang cenderung paling lambat dari perspektif pengguna nyata, baca Menemukan interaksi lambat di kolom. Setelah memiliki data lapangan untuk memandu Anda, Anda dapat menguji interaksi spesifik tersebut secara manual di alat lab untuk mencari tahu mengapa interaksi tersebut lambat.

Bagaimana jika Anda tidak memiliki data lapangan?

Memiliki data lapangan sangat penting, karena dapat menghemat banyak waktu untuk mencari tahu interaksi mana yang perlu dioptimalkan. Namun, Anda mungkin berada dalam posisi yang tidak memiliki data kolom. Jika itu sesuai dengan situasi Anda, masih mungkin untuk menemukan interaksi yang lebih baik, meskipun membutuhkan lebih banyak upaya dan pendekatan yang berbeda.

Total Blocking Time (TBT) adalah metrik lab yang menilai responsivitas halaman selama pemuatan, dan memiliki korelasi yang baik dengan INP. Jika halaman Anda memiliki TBT yang tinggi, hal tersebut merupakan sinyal potensial bahwa halaman Anda mungkin tidak terlalu responsif terhadap interaksi pengguna saat halaman dimuat.

Untuk mengetahui TBT halaman, Anda dapat menggunakan Lighthouse. Jika TBT halaman tinggi, ada kemungkinan thread utama terlalu sibuk selama pemuatan halaman, dan hal tersebut dapat memengaruhi seberapa responsif halaman selama waktu penting dalam siklus proses halaman.

Untuk menemukan interaksi yang lambat setelah halaman dimuat, Anda mungkin memerlukan jenis data lain, seperti alur penggunaan umum yang mungkin sudah Anda identifikasi di analisis situs Anda. Misalnya, jika Anda mengerjakan situs web e-commerce, alur pengguna yang umum adalah tindakan yang dilakukan pengguna saat mereka menambahkan item ke keranjang belanja {i>online<i} dan melakukan pembayaran.

Terlepas dari apakah Anda memiliki data kolom atau tidak, langkah berikutnya adalah menguji dan mereproduksi interaksi lambat secara manual—karena Anda hanya dapat mereproduksi interaksi lambat yang dapat Anda perbaiki.

Mereproduksi interaksi lambat di lab

Ada sejumlah cara untuk mereproduksi interaksi lambat di lab melalui pengujian manual, tetapi berikut ini adalah framework yang dapat Anda coba.

Merekam aktivitas

Profiler performa Chrome adalah alat yang direkomendasikan untuk mendiagnosis dan memecahkan masalah interaksi yang lambat. Untuk membuat profil interaksi di profiler performa Chrome, ikuti langkah-langkah berikut:

1. Buka halaman yang ingin Anda uji.
2. Buka Chrome DevTools dan buka panel Performance.
3. Klik tombol Record di kiri atas panel untuk memulai pelacakan.
4. Lakukan interaksi yang ingin Anda pecahkan masalahnya.
5. Klik tombol Record lagi untuk menghentikan pelacakan.

Saat profiler terisi, tempat pertama yang harus dilihat adalah ringkasan aktivitas di bagian atas profiler. Ringkasan aktivitas menampilkan bilah merah di bagian atas tempat tugas panjang terjadi dalam rekaman. Dengan begitu, Anda dapat memperbesar area yang bermasalah dengan cepat.

Anda dapat fokus pada area masalah secara cepat dengan menyeret dan memilih wilayah di ringkasan aktivitas. Secara opsional, Anda dapat menggunakan fitur breadcrumb di profiler untuk membantu mempersempit linimasa dan mengabaikan aktivitas yang tidak terkait.

Setelah Anda berfokus ke tempat interaksi terjadi, jalur Interaksi membantu Anda menyejajarkan interaksi dan aktivitas yang terjadi di jalur thread utama di bawahnya:

Anda bisa mendapatkan detail tambahan tentang bagian interaksi mana yang paling lama dengan mengarahkan kursor ke iterasi di jalur interaksi:

Bagian interaksi bergaris menunjukkan jumlah waktu interaksi yang melebihi 200 milidetik, yang merupakan batas atas batas "baik" untuk INP halaman. Bagian dari interaksi yang tercantum adalah:

1. Penundaan input—divisualisasikan dengan garis kumis kiri.
2. Durasi pemrosesan—divisualisasikan dengan blok solid di antara kumis kiri dan kanan.
3. Penundaan presentasi—divisualisasikan oleh kumis kanan.

Dari sini, Anda perlu menggali lebih dalam masalah yang menyebabkan interaksi lambat, yang akan dibahas nanti dalam panduan ini.

Ekstensi Chrome Data Web

Profiler performa adalah pendekatan yang direkomendasikan untuk mendiagnosis interaksi yang lambat, tetapi perlu waktu untuk mengidentifikasi interaksi lambat jika Anda tidak mengetahui interaksi mana yang menimbulkan masalah. Salah satu pendekatan yang perlu dipertimbangkan adalah menggunakan Ekstensi Chrome Data Web. Ekstensi ini dapat digunakan untuk mencoba sejumlah interaksi dengan cepat guna menemukan interaksi yang bermasalah, sebelum Anda melanjutkan ke profiler performa.

Setelah diinstal, ekstensi Data Web akan menampilkan data interaksi di konsol DevTools jika Anda mengikuti langkah-langkah berikut:

1. Di Chrome, klik ikon ekstensi di sebelah kanan kolom URL.
2. Temukan ekstensi Data Web di menu drop-down.
3. Klik ikon di sebelah kanan untuk membuka setelan ekstensi.
4. Klik Opsi.
5. Aktifkan kotak centang Console logging di layar hasil, lalu klik Save.

Setelah mengikuti langkah-langkah ini, buka konsol di Chrome DevTools dan mulai uji interaksi yang dicurigai pada halaman. Saat Anda berinteraksi, data diagnostik akan muncul di konsol:

Meskipun ekstensi Data Web membantu mengidentifikasi interaksi yang lambat, dan memberikan beberapa detail untuk membantu Anda men-debug INP, Anda mungkin masih perlu menggunakan profiler performa untuk mendiagnosis interaksi yang lambat, karena ekstensi ini memberikan data mendetail yang Anda perlukan untuk menelusuri kode produksi situs Anda untuk menemukan penyebab di balik interaksi yang lambat.

Cara mengidentifikasi bagian mana dari interaksi yang lambat

Interaksi terdiri dari tiga bagian: penundaan input, durasi pemrosesan, dan penundaan presentasi. Cara Anda mengoptimalkan interaksi untuk menurunkan INP halaman bergantung pada bagian mana yang memerlukan waktu paling lama.

Cara mengidentifikasi penundaan input yang lama

Penundaan input dapat menyebabkan latensi interaksi yang tinggi. Penundaan input adalah bagian pertama dari interaksi. Ini adalah periode waktu sejak tindakan pengguna pertama kali diterima oleh sistem operasi hingga browser dapat mulai memproses callback pengendali peristiwa pertama dari interaksi tersebut.

Mengidentifikasi penundaan input di profiler performa Chrome dapat dilakukan dengan menemukan interaksi di jalur interaksi. Panjang whisker kiri menunjukkan bagian penundaan input interaksi, dan nilai presisinya dapat ditemukan dalam tooltip dengan mengarahkan kursor ke interaksi di profiler performa.

Penundaan input tidak pernah bernilai nol, tetapi Anda memiliki kontrol atas durasi penundaan input tersebut. Kuncinya adalah mencari tahu apakah ada pekerjaan yang berjalan di thread utama yang mencegah callback Anda berjalan sesegera mungkin.

Pada gambar sebelumnya, tugas dari skrip pihak ketiga sedang berjalan saat pengguna mencoba berinteraksi dengan halaman, sehingga memperpanjang penundaan input. Penundaan input yang diperpanjang akan memengaruhi latensi interaksi, sehingga dapat memengaruhi INP halaman.

Cara mengidentifikasi durasi pemrosesan yang lama

Callback peristiwa langsung berjalan setelah penundaan input, dan waktu yang dibutuhkan untuk menyelesaikannya dikenal sebagai durasi pemrosesan. Jika callback peristiwa berjalan terlalu lama, callback tersebut menunda browser untuk menampilkan frame berikutnya, dan dapat menambah jumlah latensi interaksi secara signifikan. Durasi pemrosesan yang lama dapat disebabkan oleh JavaScript pihak pertama atau pihak ketiga yang mahal secara komputasi, dan dalam beberapa kasus, keduanya bisa terjadi. Pada profiler performa, hal ini diwakili oleh bagian interaksi yang solid dalam jalur interaksi.

Menemukan callback peristiwa yang mahal dapat dilakukan dengan mengamati hal-hal berikut dalam rekaman aktivitas untuk interaksi tertentu:

1. Menentukan apakah tugas yang terkait dengan callback peristiwa merupakan tugas panjang. Agar dapat menemukan tugas yang berjalan lama di setelan lab dengan lebih andal, Anda mungkin perlu mengaktifkan throttling CPU di panel performa, atau menghubungkan perangkat Android tingkat menengah ke bawah dan menggunakan proses debug jarak jauh.
2. Jika tugas yang menjalankan callback peristiwa merupakan tugas yang panjang, cari entri pengendali peristiwa—misalnya,entri dengan nama seperti Event: click—dalam stack panggilan yang memiliki segitiga merah di sudut kanan atas entri.

Anda dapat mencoba salah satu strategi berikut untuk mengurangi durasi pemrosesan interaksi:

1. Lakukan pekerjaan sesedikit mungkin. Apakah semua yang terjadi dalam callback peristiwa yang mahal benar-benar diperlukan? Jika tidak, pertimbangkan untuk menghapus kode tersebut sepenuhnya jika memungkinkan, atau menunda eksekusinya di lain waktu jika Anda tidak bisa melakukannya. Anda juga dapat memanfaatkan fitur framework untuk membantu. Misalnya, fitur kenangan React dapat melewati pekerjaan rendering yang tidak perlu untuk komponen jika propertinya belum berubah.
2. Tunda pekerjaan non-rendering dalam callback peristiwa ke waktu yang akan datang. Tugas yang panjang dapat dipecah dengan membuat thread utama. Setiap kali menyerah pada thread utama, Anda mengakhiri eksekusi tugas saat ini dan memecah sisa pekerjaan menjadi tugas yang terpisah. Hal ini memberi perender kesempatan untuk memproses pembaruan pada antarmuka pengguna yang dilakukan sebelumnya di callback peristiwa. Jika Anda menggunakan React, fitur transisinya dapat melakukannya untuk Anda.

Strategi ini harus dapat membantu Anda mengoptimalkan callback peristiwa sehingga waktu yang dibutuhkan untuk menjalankannya lebih sedikit.

Cara mengidentifikasi penundaan presentasi

Penundaan input yang panjang dan durasi pemrosesan bukan satu-satunya penyebab INP buruk. Kadang-kadang pembaruan rendering yang terjadi sebagai respons terhadap kode callback peristiwa dalam jumlah kecil sekalipun bisa menjadi mahal. Waktu yang diperlukan browser untuk merender update visual ke antarmuka pengguna untuk mencerminkan hasil interaksi dikenal sebagai penundaan presentasi.

Pekerjaan rendering paling sering terdiri dari tugas-tugas seperti penghitungan ulang gaya, layout, paint, dan composite, serta diwakili oleh blok ungu dan hijau dalam flame chart profiler. Total penundaan presentasi diwakili oleh kumis kanan interaksi dalam jalur interaksi.

Dari semua kemungkinan penyebab latensi interaksi yang tinggi, penundaan presentasi bisa menjadi yang paling sulit untuk dipecahkan dan diperbaiki. Pekerjaan rendering yang berlebihan dapat disebabkan oleh hal berikut:

• Ukuran DOM yang besar. Pekerjaan rendering yang diperlukan untuk memperbarui presentasi halaman sering kali meningkat seiring dengan ukuran DOM halaman. Untuk informasi selengkapnya, baca Pengaruh ukuran DOM yang besar terhadap interaktivitas—dan tindakan yang dapat Anda lakukan terkait hal itu.
• Perubahan posisi/geometri yang dipaksa. Ini terjadi bila Anda menerapkan perubahan gaya pada elemen di JavaScript, dan kemudian langsung melakukan kueri terhadap hasil pekerjaan itu. Hasilnya adalah browser harus melakukan pekerjaan tata letak sebelum melakukan hal lain, sehingga browser bisa menampilkan gaya yang diperbarui. Untuk informasi selengkapnya dan tips untuk menghindari perubahan posisi/geometri paksa, baca Menghindari tata letak yang besar dan kompleks serta layout thrashing.
• Pekerjaan yang berlebihan atau tidak perlu di callback requestAnimationFrame. Callback requestAnimationFrame() dijalankan selama fase rendering loop peristiwa, dan harus selesai sebelum frame berikutnya dapat ditampilkan. Jika Anda menggunakan requestAnimationFrame() untuk melakukan pekerjaan yang tidak melibatkan perubahan pada antarmuka pengguna, pahami bahwa Anda dapat menunda frame berikutnya.
• Callback ResizeObserver. Callback tersebut berjalan sebelum rendering, dan dapat menunda presentasi frame berikutnya jika pekerjaan di dalamnya mahal. Seperti callback peristiwa, tunda logika apa pun yang tidak diperlukan untuk frame berikutnya.

Bagaimana jika Anda tidak dapat mereproduksi interaksi yang lambat?

Bagaimana jika data kolom Anda menunjukkan bahwa interaksi tertentu lambat, tetapi Anda tidak dapat mereproduksi masalah di lab secara manual? Ada beberapa alasan mengapa hal ini bisa terjadi.

Pertama, situasi Anda saat menguji interaksi bergantung pada koneksi hardware dan jaringan Anda. Anda mungkin menggunakan perangkat yang cepat pada koneksi cepat—tetapi itu tidak berarti pengguna Anda menggunakannya. Anda dapat mencoba salah satu dari tiga hal berikut jika ini terjadi pada Anda:

1. Jika Anda memiliki perangkat Android fisik, gunakan proses debug jarak jauh untuk membuka instance Chrome DevTools di mesin host dan cobalah untuk mereproduksi interaksi lambat di sana. Perangkat seluler sering kali tidak secepat laptop atau komputer desktop, sehingga interaksi yang lambat mungkin lebih mudah diamati pada perangkat ini.
2. Jika Anda tidak memiliki perangkat fisik, aktifkan fitur throttling CPU di Chrome DevTools.

Penyebab lainnya mungkin adalah Anda menunggu halaman dimuat sebelum berinteraksi dengannya, tetapi pengguna tidak melakukannya. Jika Anda berada di jaringan yang cepat, simulasikan kondisi jaringan yang lebih lambat dengan mengaktifkan throttling jaringan, lalu berinteraksilah dengan halaman segera setelah selesai. Anda harus melakukannya karena thread utama sering kali tersibuk selama startup, dan pengujian selama periode waktu tersebut dapat mengungkapkan apa yang dialami pengguna Anda.

Pemecahan masalah INP adalah proses iteratif

Mencari tahu penyebab latensi interaksi tinggi yang berkontribusi pada INP yang buruk membutuhkan banyak pekerjaan. Namun, jika Anda dapat mengidentifikasi penyebabnya, berarti Anda sudah setengah jalan. Dengan mengikuti pendekatan metodis untuk memecahkan masalah INP yang buruk, Anda dapat dengan andal mengetahui penyebab masalah, lalu sampai ke perbaikan yang tepat dengan lebih cepat. Untuk meninjau:

• Mengandalkan data lapangan untuk menemukan interaksi yang lambat.
• Uji interaksi kolom bermasalah secara manual di lab untuk melihat apakah interaksi tersebut dapat direproduksi.
• Identifikasi apakah penyebabnya karena penundaan input yang lama, callback peristiwa yang mahal, atau pekerjaan rendering yang mahal.
• Ulangi.

Yang terakhir dari ini adalah yang paling penting. Seperti sebagian besar pekerjaan lain yang Anda lakukan untuk meningkatkan performa halaman, memecahkan masalah dan meningkatkan INP adalah proses siklus. Setelah Anda memperbaiki satu interaksi lambat, lanjutkan ke interaksi berikutnya dan ulangi hingga Anda mulai melihat hasilnya.