Dipublikasikan: 04 April 2025
Memperbaiki masalah performa di dunia nyata berarti menjembatani kesenjangan antara lingkungan pengembangan dan beragam pengalaman performa pengguna. Dalam postingan ini, kita akan melihat fitur baru di Chrome DevTools yang membantu Anda lebih banyak mendasarkan keputusan proses debug performa pada data nyata, bukan tebakan.
Melakukan kalibrasi ekspektasi
Mulai Chrome 134, DevTools menyertakan kalibrasi throttling CPU, alat baru untuk menghilangkan ketidakpastian dalam memilih tingkat throttling CPU yang tepat. Jalankan kalibrasi sekali, dan DevTools akan membuat preset throttling "perangkat seluler kelas bawah" dan "perangkat seluler kelas menengah" untuk Anda, khusus untuk mesin pengembangan Anda.
Ketidakcocokan umum dalam pekerjaan performa web adalah, sebagai developer, kita sering mem-build situs di perangkat desktop yang cepat, sementara banyak pengguna menggunakan perangkat seluler yang lebih sederhana. Melacak masalah performa dapat menjadi rumit jika hanya terjadi pada perangkat dengan CPU yang jauh lebih lambat.
Standar emasnya adalah proses debug jarak jauh di perangkat seluler sungguhan, tetapi selama hampir satu dekade, Chrome juga telah mendukung throttle CPU untuk siklus iterasi yang cepat dan ringan selama pengembangan.
Namun, tingkat throttling CPU mana yang harus Anda pilih? 4x? 20x? Bagaimana Anda tahu mana yang paling cocok dengan jenis perangkat yang Anda ketahui mengunjungi situs Anda? Dan bagaimana kecepatan mesin Anda sendiri mengubah keputusan tersebut, baik Anda menggunakan workstation kelas atas atau menggunakan Chromebook berusia 8 tahun saat bepergian?
Proses kalibrasi throttling
Saat panel Performa dibuka, setelan Lingkungan memiliki drop-down untuk menetapkan tingkat throttling CPU. Jika belum pernah menjalankan kalibrasi, Anda akan melihat dua opsi yang dinonaktifkan di bagian "Preset terkalibrasi" di menu drop-down, dan opsi Kalibrasi… di bagian paling bawah.
Dengan memilih opsi ini, Anda akan diarahkan ke preset throttling CPU di Setelan (Anda juga dapat langsung membukanya).
- Klik tombol Kalibrasi
- Klik Lanjutkan saat Anda diberi tahu bahwa Anda akan keluar dari halaman saat ini untuk sementara
- Benchmark cepat akan berjalan untuk mengukur kecepatan komputer Anda saat ini, dan kalibrasi selesai
Opsi throttling kini akan diisi dengan preset yang dikalibrasi untuk perangkat tingkat rendah dan menengah.
Kedua preset ini seharusnya cukup untuk sebagian besar kasus penggunaan pengembangan, dan kami umumnya merekomendasikan preset "tingkat menengah" karena cocok dengan perangkat seluler "biasa" yang terlihat di web. Jika Anda mengetahui bahwa banyak pengguna memiliki perangkat yang lebih lambat atau masalah performa hanya biasanya terjadi untuk pengguna tersebut, opsi "tingkat rendah" harus cukup lambat untuk menangkap bahkan perangkat kelas bawah long tail.
Terakhir, jika Anda merasa ada yang salah dengan kalibrasi atau mesin lokal Anda telah berubah, Anda dapat melakukan kalibrasi ulang melalui drop-down throttling atau di setelan, yang akan menjalankan ulang benchmark dan memperbarui preset.
Cara kerja throttling CPU di DevTools
Jika Anda pernah penasaran dengan cara kerja throttling CPU di DevTools, idenya relatif mudah. Saat Anda mengaktifkan throttling untuk tab, Chrome akan meluncurkan thread throttling terpisah yang mengganggu dan menangguhkan thread utama tab untuk burst singkat yang sering terjadi. Tujuannya adalah untuk menangguhkan thread utama cukup lama sehingga durasi tugas tertentu meningkat dengan faktor throttling.
Misalnya, pada throttling CPU 4x, thread utama akan ditangguhkan sekitar 75% dari waktu, yang membuat pekerjaan thread utama memerlukan waktu empat kali lebih lama untuk diselesaikan.
Manfaat pendekatan ini adalah sebagian besar transparan untuk bagian Chrome lainnya; tidak ada kode khusus yang diperlukan untuk memperlambat JavaScript, atau tata letak, atau setiap jenis pekerjaan lainnya yang perlu dilakukan browser. Semua pekerjaan pada thread utama memerlukan waktu lebih lama karena thread itu sendiri hanya diizinkan untuk dieksekusi dalam sebagian kecil waktu.
Saat throttling CPU bertindak seperti perangkat seluler sungguhan
Akibatnya, banyak jenis pekerjaan yang terikat CPU seluler disimulasikan dengan baik oleh throttling CPU. Misalnya, jika interaksi memicu JavaScript dan tata letak, interaksi tersebut memiliki peluang besar untuk dieksekusi dengan sangat mirip dengan cara eksekusi di perangkat seluler.
Pertimbangkan tugas yang dipicu oleh klik tombol, yang menjalankan JavaScript untuk menambahkan elemen baru ke DOM, yang kemudian mengharuskan browser menjalankan penghitungan Gaya dan Tata Letak untuk memosisikan konten baru:
Dengan preset throttling CPU "perangkat seluler kelas menengah" yang dikalibrasi (3,7x pada mesin pengembangan ini), interaksi terlihat sangat mirip, tetapi durasinya meningkat secara signifikan, menjadi tugas yang lama:
Menguji interaksi yang sama di perangkat tingkat menengah yang sebenarnya menggunakan proses debug jarak jauh akan menghasilkan hasil yang sangat mirip, baik dalam bentuk maupun durasi rekaman aktivitas interaksi. Karena tugas ini sebagian besar terikat CPU di thread utama (menjalankan kode JavaScript halaman serta kode gaya dan tata letak Chrome), throttling yang dikalibrasi secara akurat membuat ulang performa seluler yang sebenarnya:
Saat Anda mungkin masih ingin menguji di perangkat seluler sungguhan
Meskipun sangat berguna, throttling CPU tidak dapat menyimulasikan semua aspek hardware seluler. Di ponsel, kecepatan disk lebih lambat, bandwidth memori lebih terbatas, dan throttling termal dapat diaktifkan kapan saja untuk mengurangi kecepatan eksekusi.
Batasan throttling yang umum melibatkan pekerjaan yang intensif menggunakan GPU. GPU seluler dan desktop berbeda secara arsitektur, dan Chrome menjalankan operasi GPU dalam proses terpisah dari thread utama halaman. Akibatnya, throttling CPU DevTools tidak menyentuh proses GPU (yang merupakan hal terbaik, karena akan memengaruhi responsivitas DevTools itu sendiri dan seluruh browser).
Proses menggambar, pengomposisian, dan gaya visual yang rumit dan penuh efek adalah masalah performa umum yang mungkin terlihat baik di mesin pengembangan, tetapi tiba-tiba lambat di perangkat seluler. Selain itu, Anda mungkin tidak menyadari bahwa ada masalah saat mencoba membuat ulang masalah di komputer pengembangan.
Pertimbangkan interaksi yang sama seperti sebelumnya (mengklik dan menambahkan banyak elemen ke DOM), hanya kali ini elemen baru diberi gaya dengan jumlah box-shadow dan filter blur yang berat GPU yang berlebihan.
Bentuk awal dan durasi interaksi terlihat serupa, tetapi ada proses gambar thread utama baru yang panjang di bagian akhirnya untuk efek yang ditambahkan:
Pada ponsel kelas menengah yang sebenarnya, bagian thread utama dari interaksi terlihat sangat mirip dengan simulasi, termasuk cat tambahan, tetapi kemudian proses GPU yang liar tampaknya melakukan pekerjaan dalam jumlah besar sebelum hasil interaksi dapat muncul di layar:
Pekerjaan GPU memperpanjang interaksi sebesar 300 milidetik lagi, dan merupakan pekerjaan yang hampir tidak ada sama sekali untuk GPU laptop, bahkan dengan throttling CPU (thread utama) yang diaktifkan.
Ada beberapa kasus lain yang juga memiliki kelemahan emulasi yang signifikan, seperti pemuatan halaman dengan dependensi mendalam, yang memiliki interaksi antara throttling jaringan simulasi, komunikasi antarproses, dan mengakses cache disk dan memori.
Pastikan untuk menguji di perangkat seluler sungguhan pada suatu waktu. Selain itu, jika Anda tidak dapat membuat ulang masalah di lab pada komputer desktop yang ditunjukkan oleh data lapangan memengaruhi pengguna seluler, cobalah proses debug jarak jauh dengan perangkat sungguhan untuk melihat apakah ada perbedaan yang Anda lewatkan.
Peningkatan proses debug berbasis data lainnya
Beberapa fitur baru lainnya baru-baru ini diluncurkan untuk membantu mempermudah penetapan setelan dan keputusan proses debug berdasarkan pengguna sebenarnya.
Jika Anda telah mengaktifkan data kolom, panel Performa akan memberikan saran tentang throttling berdasarkan pengguna persentil ke-75 seperti yang diukur oleh Laporan Pengalaman Pengguna Chrome (CrUX), dan tampilan metrik real-time akan memberi tahu Anda jika metrik yang diukur secara lokal berbeda dari data kolom. Hal ini telah dibahas secara mendetail dalam postingan sebelumnya tentang cara memasukkan data Data Web Inti dunia nyata ke DevTools.
Salah satu tambahan barunya adalah Insight panel performa di sidebar kini juga akan memberi tahu Anda jika metrik yang diukur dalam rekaman aktivitas tidak cocok dengan yang dialami pengguna di dunia nyata.
Mengaktifkan data lapangan juga akan memungkinkan penggunaan Data Web Inti persentil ke-75 untuk membantu menentukan urutan tampilan insight di sidebar. Misalnya, jika pengguna Anda biasanya memiliki Largest Contentful Paint (LCP) yang bagus, tetapi Interaction to Next Paint (INP) yang buruk, insight yang membantu meningkatkan INP akan cenderung berada di bagian atas daftar.
Terakhir, jika Anda pernah beralih bolak-balik di antara beberapa rekaman aktivitas, atau memuat rekaman aktivitas dari disk, akan sulit untuk mengingat dengan tepat setelan throttling dan emulasi seluler yang Anda gunakan di setiap rekaman aktivitas. Drop-down pemilihan rekaman aktivitas di bagian atas panel Performa kini menampilkan informasi emulasi untuk setiap rekaman aktivitas.
Berhenti, kalibrasi, dan dengarkan
Pada akhirnya, kita perlu mendasarkan keputusan proses debug pada dunia nyata: dimulai dengan data lapangan dari analisis dan laporan pengguna untuk menemukan masalah, lalu membuat ulang pengalaman pengguna tersebut di lab untuk diagnosis. Penambahan DevTools baru ini akan membantu mempermudah proses tersebut.
Kalibrasi throttling CPU dan pemberitahuan tentang pengalaman lapangan dan lab yang berbeda membantu mengurangi ketidakpastian apakah Anda berada di jalur yang benar atau tidak dan memungkinkan perkiraan performa dunia nyata yang lebih konsisten. Dengan menghilangkan tebakan dari konfigurasi dan menyoroti potensi perbedaan, DevTools bertujuan untuk membantu Anda menghabiskan lebih banyak waktu untuk berfokus pada perbaikan masalah performa yang sebenarnya yang memengaruhi pengguna.
Punya ide untuk peningkatan lainnya atau saran untuk fitur baru? Beri tahu kami.