Menganalisis performa runtime

Performa runtime adalah performa halaman Anda saat dijalankan, bukan saat dimuat. Tutorial ini menunjukkan cara menggunakan panel Performa Chrome DevTools untuk menganalisis performa runtime. Terkait model RAIL, keterampilan yang Anda pelajari dalam tutorial ini berguna untuk menganalisis fase Respons, Animasi, dan Tidak Ada Aktivitas pada halaman Anda.

Mulai

Dalam tutorial ini, Anda akan membuka DevTools di halaman yang aktif dan menggunakan panel Performa untuk menemukan bottleneck performa di halaman.

1. Buka Google Chrome dalam Mode Samaran. Mode Samaran memastikan Chrome berjalan dalam kondisi yang bersih. Misalnya, jika Anda sudah menginstal banyak ekstensi, ekstensi tersebut mungkin menimbulkan derau dalam pengukuran performa Anda.

2. Muat halaman berikut di jendela Samaran Anda. Ini adalah demo yang akan Anda buat profil. Laman ini menampilkan sekumpulan kotak biru kecil yang bergerak naik dan turun.

   https://googlechrome.github.io/devtools-samples/jank/

3. Tekan Command+Option+I (Mac) atau Control+Shift+I (Windows, Linux) untuk membuka DevTools.

   

   Gambar 1. Demo di sebelah kiri, dan DevTools di kanan

Menyimulasikan CPU seluler

Perangkat seluler memiliki daya CPU yang jauh lebih sedikit daripada desktop dan laptop. Setiap kali membuat profil halaman, gunakan Throttling CPU untuk menyimulasikan performa halaman Anda di perangkat seluler.

1. Di DevTools, klik tab Performa.
2. Pastikan kotak centang Screenshots diaktifkan.
3. Klik Setelan Tangkapan . DevTools menampilkan setelan yang terkait dengan cara kamera merekam metrik performa.

4. Untuk CPU, pilih 2x pelambatan. DevTools melakukan throttle pada CPU sehingga 2 kali lebih lambat dari biasanya.

   

   Gambar 2. Throttling CPU, digarisbatasi dengan warna biru

Menyiapkan demo

Sulit untuk membuat demo performa runtime yang berfungsi secara konsisten untuk semua pembaca situs ini. Bagian ini memungkinkan Anda menyesuaikan demo untuk memastikan pengalaman Anda relatif konsisten dengan screenshot dan deskripsi yang Anda lihat dalam tutorial ini, terlepas dari penyiapan khusus Anda.

1. Terus klik Add 10 sampai kotak biru bergerak lebih lambat dari sebelumnya. Pada komputer kelas atas, mungkin diperlukan waktu sekitar 20 klik.

2. Klik Optimalkan. Kotak biru akan bergerak lebih cepat dan lebih halus.

3. Klik Batalkan Pengoptimalan. Kotak biru bergerak lebih lambat dan dengan lebih banyak jank lagi.

Merekam performa runtime

Saat Anda menjalankan versi halaman yang dioptimalkan, kotak biru akan bergerak lebih cepat. Why is that? Kedua versi seharusnya memindahkan setiap kotak dengan jumlah ruang yang sama dalam waktu yang sama. Ambil rekaman di panel Performa untuk mempelajari cara mendeteksi bottleneck performa pada versi yang tidak dioptimalkan.

1. Di DevTools, klik Record . DevTools menangkap metrik performa saat halaman berjalan.

   

   Gambar 3: Membuat profil halaman

2. Tunggu beberapa detik.

3. Klik Stop. DevTools berhenti merekam, memproses data, lalu menampilkan hasilnya di panel Performa.

   

   Gambar 4: Hasil profil

Wow, itu adalah jumlah data yang sangat banyak. Jangan khawatir, semuanya akan Anda mengerti.

Menganalisis hasil

Setelah merekam performa halaman, Anda dapat mengukur seberapa buruk performa halaman dan menemukan penyebabnya.

Menganalisis frame per detik

Metrik utama untuk mengukur performa animasi adalah frame per detik (FPS). Pengguna akan senang jika animasi berjalan pada 60 FPS.

1. Lihat diagram FPS. Setiap kali Anda melihat batang merah di atas FPS, artinya kecepatan frame turun sangat rendah sehingga mungkin membahayakan pengalaman pengguna. Secara umum, makin tinggi panel hijau, makin tinggi FPS.

   

   Gambar 5: Diagram FPS, digarisbawahi dengan warna biru

2. Di bawah diagram FPS, Anda akan melihat diagram CPU. Warna dalam diagram CPU sesuai dengan warna di tab Summary, di bagian bawah panel Performance. Fakta bahwa diagram CPU penuh warna berarti CPU mencapai batas maksimum selama perekaman. Setiap kali Anda melihat CPU maksimal habis untuk waktu yang lama, adalah tanda untuk menemukan cara untuk melakukan lebih sedikit pekerjaan.

   

   Gambar 6: Diagram CPU dan tab Ringkasan, digarisbawahi dengan warna biru

3. Arahkan kursor ke diagram FPS, CPU, atau NET. DevTools akan menampilkan screenshot halaman pada saat itu. Gerakkan mouse ke kiri dan ke kanan untuk memutar ulang rekaman. Ini disebut scrubbing, dan berguna untuk menganalisis perkembangan animasi secara manual.

   

   Gambar 7: Melihat screenshot halaman sekitar tanda 2.000 md rekaman

4. Di bagian Bingkai, arahkan kursor ke salah satu kotak hijau. DevTools menampilkan FPS untuk frame tertentu. Setiap frame mungkin jauh di bawah target 60 FPS.

   

   Gambar 8: Mengarahkan kursor ke atas frame

Tentu saja, dengan demo ini, terlihat jelas bahwa performa halaman tersebut tidak baik. Namun, dalam skenario sebenarnya, hal ini mungkin tidak terlalu jelas, sehingga memiliki semua alat ini untuk melakukan pengukuran akan sangat berguna.

Bonus: Buka pengukur FPS

Alat praktis lainnya adalah pengukur FPS, yang memberikan perkiraan real-time untuk FPS saat halaman berjalan.

1. Tekan Command+Shift+P (Mac) atau Control+Shift+P (Windows, Linux) untuk membuka Menu Command.
2. Mulai ketik Rendering di Menu Command dan pilih Show Rendering.

3. Pada tab Rendering, aktifkan FPS Meter. Overlay baru akan muncul di kanan atas area pandang Anda.

   

   Gambar 9: Pengukur FPS

4. Nonaktifkan FPS Meter, lalu tekan Escape untuk menutup tab Rendering. Anda tidak akan menggunakannya dalam tutorial ini.

Menemukan bottleneck

Sekarang setelah Anda mengukur dan memverifikasi bahwa animasi tidak berperforma baik, pertanyaan berikutnya yang harus dijawab adalah: mengapa?

1. Perhatikan tab ringkasan. Jika tidak ada peristiwa yang dipilih, tab ini akan menampilkan perincian aktivitas. Halaman menghabiskan sebagian besar waktunya untuk rendering. Karena performa adalah seni melakukan lebih sedikit pekerjaan, tujuan Anda adalah mengurangi jumlah waktu yang dihabiskan untuk melakukan pekerjaan rendering.

   

   Gambar 10: Tab Ringkasan, dengan garis batas warna biru

2. Luaskan bagian Utama. DevTools menampilkan flame chart aktivitas di thread utama, dari waktu ke waktu. Sumbu x mewakili rekaman, dari waktu ke waktu. Setiap bilah mewakili sebuah peristiwa. Batang yang lebih lebar berarti peristiwa tersebut memerlukan waktu lebih lama. Sumbu y mewakili stack panggilan. Jika Anda melihat peristiwa ditumpuk di atas satu sama lain, berarti peristiwa yang lebih tinggi menyebabkan peristiwa yang lebih rendah.

   

   Gambar 11: Bagian Utama, digarisbawahi dengan warna biru

3. Ada banyak data dalam rekaman. Perbesar satu peristiwa Animation Frame Fired dengan mengklik, menahan, dan menarik mouse ke Overview, yang merupakan bagian yang mencakup diagram FPS, CPU, dan NET. Bagian Utama dan tab Ringkasan hanya menampilkan informasi untuk bagian rekaman yang dipilih.

   

   Gambar 12: Memperbesar peristiwa Animation Frame Fired tunggal

4. Perhatikan segitiga merah di kanan atas peristiwa Animation Frame Fired. Setiap kali Anda melihat segitiga merah, ada peringatan bahwa mungkin ada masalah terkait peristiwa ini.

5. Klik peristiwa Animation Frame Fired. Tab Ringkasan sekarang menampilkan informasi tentang peristiwa tersebut. Perhatikan link pengungkapan. Mengklik tombol tersebut akan menyebabkan DevTools menandai peristiwa yang memulai peristiwa Animation Frame Fired. Perhatikan juga link app.js:94. Dengan mengkliknya, Anda akan diarahkan ke baris yang relevan dalam kode sumber.

   

   Gambar 13: Informasi selengkapnya tentang peristiwa Animation Frame Fired

6. Di bagian peristiwa app.update, ada sejumlah peristiwa ungu. Jika lebih lebar, gambar akan tampak seolah-olah ada segitiga merah di atasnya. Klik salah satu peristiwa Tata Letak berwarna ungu sekarang. DevTools menyediakan informasi selengkapnya tentang peristiwa di tab Summary. Bahkan, ada peringatan tentang perubahan posisi/geometri paksa (kata lain untuk tata letak).

7. Di tab Summary, klik link app.js:70 di bagian Layout Forced. DevTools mengarahkan Anda ke baris kode yang memaksa tata letak.

   

   Gambar 13: Baris kode yang menyebabkan tata letak paksa

Fiuh! Banyak hal yang harus dipelajari, tetapi sekarang Anda memiliki fondasi yang kuat dalam alur kerja dasar untuk menganalisis performa runtime. Bagus sekali.

Bonus: Menganalisis versi yang dioptimalkan

Dengan menggunakan alur kerja dan alat yang baru saja Anda pelajari, klik Optimize pada demo untuk mengaktifkan kode yang dioptimalkan, melakukan pencatatan performa lagi, lalu menganalisis hasilnya. Dari peningkatan kecepatan frame hingga pengurangan peristiwa di flame chart bagian Utama, Anda dapat melihat bahwa versi aplikasi yang dioptimalkan melakukan lebih sedikit pekerjaan, sehingga menghasilkan performa yang lebih baik.

Langkah berikutnya

Fondasi untuk memahami performa adalah model RAIL. Model ini mengajarkan metrik performa yang paling penting bagi pengguna Anda. Lihat Mengukur Performa Dengan Model RAIL untuk mempelajari lebih lanjut.

Agar lebih nyaman dengan panel Performa, coba praktikkan hasilnya. Coba buat profil halaman Anda sendiri dan analisis hasilnya. Jika ada pertanyaan tentang hasilnya, buka pertanyaan Stack Overflow yang diberi tag dengan google-chrome-devtools. Sertakan screenshot atau tautan ke halaman yang dapat direproduksi, jika memungkinkan.

Untuk menjadi ahli dalam kinerja waktu proses, Anda harus mempelajari cara browser menerjemahkan HTML, CSS, dan JS menjadi piksel pada layar. Tempat terbaik untuk memulai adalah Ringkasan Performa Rendering. Anatomi Bingkai membahas secara lebih mendetail.

Terakhir, ada banyak cara untuk meningkatkan performa runtime. Tutorial ini berfokus pada satu bottleneck animasi tertentu untuk memberi Anda tur yang terfokus melalui panel Performa, tetapi ini hanyalah salah satu dari banyak bottleneck yang mungkin Anda temui. Rangkaian tersisa dalam rangkaian Performa Rendering memiliki banyak tips bagus untuk meningkatkan berbagai aspek performa runtime, seperti:

• Mengoptimalkan Eksekusi JS
• Mengurangi Cakupan dan Kompleksitas Penghitungan Gaya
• Menghindari Tata Letak Besar dan Kompleks serta Layout Thrashing
• Menyederhanakan Kompleksitas Paint dan Mengurangi Area Paint
• Tetap Berpegang pada Properti Khusus Compositor dan Kelola Jumlah Lapisan
• Melakukan Debounce pada Pengendali Input Anda