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 dalam mengoptimalkan Interaction to Next Paint (INP) adalah mencari tahu penyebab INP yang buruk. Ada banyak kemungkinan penyebabnya, seperti skrip pihak ketiga yang menjadwalkan banyak tugas di thread utama, ukuran DOM besar, callback peristiwa yang mahal, dan penyebab lainnya.

Meningkatkan INP tidaklah mudah. Untuk memulai, Anda harus mengetahui interaksi mana yang cenderung berkaitan dengan INP halaman. Jika tidak mengetahui interaksi mana di situs Anda yang cenderung paling lambat dari perspektif pengguna sungguhan, baca Menemukan interaksi lambat di lapangan. Setelah memiliki data lapangan untuk memandu Anda, Anda dapat menguji interaksi spesifik tersebut secara manual di alat lab untuk mengetahui mengapa interaksi tersebut lambat.

Bagaimana jika Anda tidak memiliki data {i>field<i}?

Memiliki data lapangan sangat penting, karena menghemat banyak waktu Anda untuk mencoba mencari tahu interaksi mana yang perlu dioptimalkan. Namun, Anda mungkin berada di posisi di mana Anda tidak memiliki data {i>field<i}. Jika situasi tersebut menggambarkan situasi Anda, Anda masih dapat menemukan interaksi yang perlu ditingkatkan, meskipun memerlukan lebih banyak upaya dan pendekatan yang berbeda.

Total Blocking Time (TBT) adalah metrik lab yang menilai responsivitas halaman selama pemuatan, dan berkorelasi baik dengan INP. Jika halaman Anda memiliki TBT yang tinggi, hal ini 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 tersebut dalam siklus proses halaman.

Untuk menemukan interaksi yang lambat setelah halaman dimuat, Anda mungkin memerlukan jenis data lain, seperti alur penggunaan umum yang mungkin telah Anda identifikasi di analisis situs Anda. Jika Anda bekerja di situs e-commerce, misalnya, alur pengguna yang umum adalah tindakan yang dilakukan pengguna saat mereka menambahkan item ke keranjang belanja online dan melakukan check out.

Baik Anda memiliki data kolom atau tidak, langkah berikutnya adalah menguji dan mereproduksi interaksi yang lambat secara manual—karena Anda hanya dapat memperbaiki interaksi lambat jika dapat mereproduksi interaksi yang lambat.

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 Performa.
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 perekaman aktivitas.

Saat profiler diisi, tempat pertama yang akan dilihat harus ringkasan aktivitas di bagian atas profiler. Ringkasan aktivitas menampilkan panel merah di bagian atas tempat tugas yang berjalan lama terjadi dalam rekaman. Tindakan ini memungkinkan Anda memperbesar dengan cepat area masalah.

Ringkasan aktivitas di bagian atas profiler performa Chrome. Tugas yang lama disorot dengan warna merah di atas flame chart aktivitas. Dalam hal ini, pekerjaan pembuatan skrip yang signifikan bertanggung jawab untuk sebagian besar pekerjaan dalam tugas yang panjang.

Anda dapat dengan cepat fokus pada area masalah dengan menarik dan memilih wilayah di ringkasan aktivitas. Anda juga 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 akan membantu Anda menyejajarkan interaksi dan aktivitas yang terjadi di jalur thread utama di bawahnya:

Interaksi yang dibuat profil di profiler performa di DevTools Chrome. Pelacakan Interaksi menampilkan serangkaian peristiwa yang sesuai dengan interaksi klik. Entri pelacakan Interaksi mencakup seluruh tugas yang bertanggung jawab untuk mendorong interaksi.

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

Tooltip yang muncul saat interaksi di jalur interaksi pada panel performa diarahkan ke atas. Tooltip menampilkan jumlah waktu yang dihabiskan di setiap bagian interaksi.

Bagian bergaris dari interaksi menggambarkan berapa lama waktu interaksi melebihi 200 milidetik, yang merupakan batas atas dari status "baik" nilai minimum untuk INP halaman. Bagian dari interaksi yang tercantum adalah:

1. Penundaan input—yang divisualisasikan oleh whisker kiri.
2. Durasi pemrosesan—divisualisasikan dengan blok padat di antara whisker kiri dan kanan.
3. Penundaan presentasi—yang divisualisasikan dengan whisker kanan.

Dari sini, kita akan mendalami masalah yang menyebabkan interaksi lambat, yang nanti akan dibahas dalam panduan ini.

Ekstensi Chrome Web Vitals

Performance profiler adalah pendekatan yang direkomendasikan untuk mendiagnosis interaksi yang diketahui lambat, tetapi mungkin perlu waktu untuk mengidentifikasi interaksi lambat jika Anda tidak mengetahui interaksi mana yang bermasalah. Salah satu pendekatan yang perlu dipertimbangkan adalah menggunakan Ekstensi Chrome Web Vitals. Ekstensi ini dapat digunakan untuk mencoba sejumlah interaksi dengan cepat guna menemukan interaksi yang bermasalah, sebelum Anda berpindah ke performance profiler.

Setelah diinstal, ekstensi Web Vitals 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 Konsol logging di layar yang dihasilkan, 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:

Ekstensi Web Vitals dapat mencatat data mendetail untuk interaksi yang berkontribusi pada INP halaman ke konsol di Chrome DevTools.

Meskipun ekstensi Web Vitals 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 menyediakan data mendetail yang Anda perlukan untuk melihat kode produksi situs Anda untuk menemukan penyebab di balik interaksi yang lambat.

Cara mengidentifikasi bagian interaksi mana 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 banyak.

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 untuk interaksi tersebut.

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

Penundaan input tidak boleh nol, tetapi Anda dapat mengontrol durasi penundaan input. Kuncinya adalah mencari tahu apakah ada tugas yang berjalan di thread utama yang mencegah callback Anda berjalan sesegera mungkin.

Penundaan input disebabkan oleh tugas yang diaktifkan oleh timer dari skrip pihak ketiga. Bagian kiri whisker dalam interaksi yang ditampilkan di jalur interaksi memvisualisasikan penundaan input.

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

Baca untuk mempelajari lebih lanjut: Untuk informasi selengkapnya tentang cara mengatasi penundaan input yang lama, baca cara mengidentifikasi dan mengurangi penundaan input.

Cara mengidentifikasi durasi pemrosesan yang lama

Callback peristiwa berjalan segera setelah penundaan input, dan waktu yang diperlukan untuk menyelesaikannya dikenal sebagai durasi pemrosesan. Jika callback peristiwa berjalan terlalu lama, callback tersebut akan menunda browser untuk menampilkan frame berikutnya, dan dapat menambahkan secara signifikan ke latensi total interaksi. Durasi pemrosesan yang lama dapat disebabkan oleh JavaScript pihak pertama atau pihak ketiga yang mahal secara komputasi, dan dalam beberapa kasus, keduanya. Di profiler performa, hal ini diwakili oleh bagian interaksi yang solid dalam jalur interaksi.

Callback peristiwa yang berjalan sebagai respons terhadap interaksi klik, seperti yang ditampilkan di profiler performa di Chrome DevTools. Perhatikan durasi pemrosesan yang tinggi.

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

1. Menentukan apakah tugas yang terkait dengan callback peristiwa merupakan tugas yang panjang. Untuk menampilkan tugas yang berjalan lama di setelan lab dengan lebih andal, Anda mungkin perlu mengaktifkan throttling CPU di panel performa, atau menghubungkan perangkat Android tingkat rendah hingga menengah dan menggunakan proses debug jarak jauh.
2. Jika tugas yang menjalankan callback peristiwa adalah tugas yang panjang, cari entri pengendali peristiwa—misalnya,entri dengan nama seperti Event: click—di tumpukan 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 seminimal mungkin. Apakah semua yang terjadi dalam callback peristiwa yang mahal benar-benar diperlukan? Jika tidak, pertimbangkan untuk menghapus kode tersebut sepenuhnya jika memungkinkan, atau tunda eksekusinya ke waktu mendatang jika Anda tidak bisa melakukannya. Anda juga dapat memanfaatkan fitur framework untuk membantu Anda. Misalnya, fitur memoisasi React dapat melewati tugas rendering yang tidak perlu untuk suatu komponen jika propertinya tidak berubah.
2. Tunda pekerjaan non-rendering di callback peristiwa ke waktu berikutnya. Tugas yang berjalan lama dapat dipecah dengan menghasilkan ke thread utama. Setiap kali menyerah pada thread utama, Anda akan mengakhiri eksekusi tugas saat ini dan memecah sisa pekerjaan menjadi tugas yang terpisah. Tindakan ini memberikan kesempatan kepada perender untuk memproses pembaruan antarmuka pengguna yang dilakukan sebelumnya dalam callback peristiwa. Jika Anda menggunakan React, fitur transisinya dapat melakukannya untuk Anda.

Strategi ini seharusnya dapat membantu Anda mengoptimalkan callback peristiwa sehingga callback peristiwa membutuhkan lebih sedikit waktu untuk dijalankan.

Cara mengidentifikasi penundaan presentasi

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

Penting: Panduan performa rendering adalah referensi yang baik untuk memahami cara browser merender halaman. Masa pakai piksel lebih mendalam tentang cara kerja rendering di browser berbasis Chromium.

Tugas rendering seperti yang ditampilkan di profiler performa Chrome. Kumis kanan memvisualisasikan durasi penundaan presentasi.

Pekerjaan rendering sering kali terdiri dari tugas-tugas seperti penghitungan ulang gaya, tata letak, cat, dan komposit, serta diwakili oleh blok berwarna ungu dan hijau dalam flame chart profiler. Total penundaan presentasi diwakili oleh whisker kanan interaksi di jalur interaksi.

Penting: Saat membuat profil interaksi lambat karena pekerjaan rendering yang mahal, Anda harus mengaktifkan kotak centang Screenshots di bagian atas profiler performa. Hal ini akan membantu Anda menyejajarkan update ke antarmuka pengguna dengan tugas rendering yang sesuai di thread utama.

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

• Ukuran DOM besar. Pekerjaan rendering yang diperlukan untuk memperbarui presentasi halaman sering kali bertambah seiring dengan ukuran DOM halaman. Untuk informasi selengkapnya, baca Pengaruh ukuran DOM besar terhadap interaktivitas—dan tindakan yang dapat Anda lakukan terkait hal ini.
• Perubahan posisi/geometri yang dipaksa. Hal ini terjadi saat Anda menerapkan perubahan gaya ke elemen dalam JavaScript, dan kemudian langsung melakukan kueri hasil dari pekerjaan tersebut. Hasilnya adalah bahwa browser harus melakukan pekerjaan tata letak sebelum melakukan hal lain, sehingga browser bisa mengembalikan gaya yang telah diperbarui. Untuk informasi selengkapnya dan tips untuk menghindari perubahan posisi/geometri paksa, baca Menghindari tata letak yang besar dan kompleks serta thrashing tata letak.
• 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.

Penting: Pemecahan masalah dapat menjadi lebih mudah dengan mengaktifkan eksperimen Linimasa: inisiator peristiwa di Chrome DevTools. Mengaktifkan eksperimen ini akan menggambar panah dari tugas penghitungan ulang gaya apa pun ke tugas JavaScript yang memulainya. Untuk mengaktifkan eksperimen ini, buka setelan Chrome DevTools, klik Experiments di menu sebelah kiri, lalu klik kotak centang berlabel Linimasa: event inisiator, lalu mulai ulang DevTools.

Bagaimana jika Anda tidak dapat mereproduksi interaksi yang lambat?

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

Pertama, situasi Anda saat menguji interaksi bergantung pada perangkat keras dan koneksi jaringan Anda. Anda mungkin menggunakan perangkat cepat dengan koneksi cepat—tetapi itu bukan berarti pengguna Anda memakainya. Anda dapat mencoba salah satu dari tiga hal berikut jika ini berlaku untuk Anda:

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

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

Pemecahan masalah INP adalah proses berulang

Mencari tahu apa yang menyebabkan latensi interaksi tinggi yang berkontribusi pada INP yang buruk membutuhkan banyak upaya—tetapi jika Anda dapat menjabarkan penyebabnya, Anda sudah setengah jalan. Dengan mengikuti pendekatan metodis untuk memecahkan masalah INP yang buruk, Anda dapat dengan andal menemukan penyebab masalah, dan mendapatkan perbaikan yang lebih cepat. Untuk meninjau:

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

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