Pelajari cara membawa data lapangan Anda ke lab untuk mereproduksi dan mengidentifikasi penyebab di balik interaksi yang lambat melalui pengujian manual.
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:
- Buka halaman yang ingin Anda uji.
- Buka Chrome DevTools dan buka panel Performa.
- Klik tombol Record di kiri atas panel untuk memulai pelacakan.
- Lakukan interaksi yang ingin Anda pecahkan masalahnya.
- 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 yang muncul di dekat bagian atas panel performa Chrome DevTools. Aktivitas yang ditampilkan sebagian besar dari JavaScript yang menyebabkan tugas yang panjang, yang disorot dengan warna merah di atas flame chart.](https://web.developers.google.cn/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/a-screenshot-the-activit-2f86d26e58372.png?authuser=19&hl=id)
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 seperti yang divisualisasikan di panel performa Chrome DevTools. Jalur interaksi di atas jalur thread utama menunjukkan durasi interaksi, yang dapat disusun dengan aktivitas thread utama di bawahnya.](https://web.developers.google.cn/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/devtools-interaction.png?authuser=19&hl=id)
Anda bisa mendapatkan detail tambahan tentang bagian interaksi mana yang terpanjang dengan mengarahkan kursor ke iterasi di jalur interaksi:
![Tooltip pengarahan kursor untuk interaksi seperti yang ditampilkan di panel performa Chrome DevTools. Tooltip menunjukkan berapa banyak waktu yang dihabiskan dalam interaksi, dan di bagian mana, termasuk penundaan input interaksi, durasi pemrosesan, dan penundaan presentasi.](https://web.developers.google.cn/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/devtools-whiskers.png?authuser=19&hl=id)
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:
- Penundaan input—yang divisualisasikan oleh whisker kiri.
- Durasi pemrosesan—divisualisasikan dengan blok padat di antara whisker kiri dan kanan.
- 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:
- Di Chrome, klik ikon ekstensi di sebelah kanan kolom URL.
- Temukan ekstensi Data Web di menu drop-down.
- Klik ikon di sebelah kanan untuk membuka setelan ekstensi.
- Klik Opsi.
- 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:
![Cara log untuk INP dari ekstensi Web Vitals muncul di konsol untuk Chrome DevTools. Pencatatan log mendetail termasuk bagian interaksi mana yang memerlukan waktu terlama tersedia, serta data atribusi mendetail dari berbagai API performa.](https://web.developers.google.cn/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/web-vitals-console.png?authuser=19&hl=id)
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 seperti yang terlihat di panel performa Chrome. Awal interaksi terjadi secara signifikan sebelum callback peristiwa karena peningkatan penundaan input karena adanya timer yang diaktifkan dari skrip pihak ketiga.](https://web.developers.google.cn/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/input-delay.png?authuser=19&hl=id)
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.
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.
![Penggambaran tugas callback peristiwa di panel performa Chrome. Tooltip pengarahan kursor ke interaksi pada linimasa menunjukkan durasi pemrosesan yang lama.](https://web.developers.google.cn/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/processing-duration.png?authuser=19&hl=id)
Menemukan callback peristiwa yang mahal dapat dilakukan dengan mengamati hal berikut dalam rekaman aktivitas untuk interaksi tertentu:
- 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.
- 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:
- 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.
- 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.
![Pekerjaan rendering seperti yang divisualisasikan di panel performa Chrome DevTools. Pekerjaan rendering terjadi setelah callback kejadian untuk melukiskan bingkai berikutnya.](https://web.developers.google.cn/static/articles/manually-diagnose-slow-interactions-in-the-lab/image/presentation-delay.png?authuser=19&hl=id)
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.
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
. CallbackrequestAnimationFrame()
dijalankan selama fase rendering loop peristiwa, dan harus selesai sebelum frame berikutnya dapat ditampilkan. Jika Anda menggunakanrequestAnimationFrame()
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 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:
- 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.
- 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.