Di Chrome 102, Anda akan melihat panel eksperimental baru, Performance Insights, di DevTools. Dalam postingan ini, kita akan membahas tidak hanya mengapa kami membuat panel baru, tetapi juga tantangan teknis yang kami hadapi dan keputusan yang telah kami buat selama ini.
Mengapa perlu membuat panel lain?
(Jika Anda belum melihatnya, kami telah memposting video tentang alasan perlunya membuat panel Insight Performa dan cara mendapatkan hasil analisis yang bisa ditindaklanjuti terkait performa situs dengan panel tersebut.)
Panel Performa yang sudah ada adalah referensi yang bagus jika Anda ingin melihat semua data untuk situs Anda di satu tempat, tetapi kami merasa hal itu bisa sedikit membingungkan. Jika Anda bukan pakar performa, sulit untuk mengetahui secara pasti apa yang harus dicari dan bagian rekaman mana yang relevan.
Masuk ke Panel Insights, tempat Anda masih dapat melihat linimasa pelacakan dan memeriksa data, serta mendapatkan daftar praktis tentang apa yang dianggap DevTools sebagai "Insight" utama yang layak digali. Insight akan mengidentifikasi beberapa masalah, misalnya permintaan pemblokiran render, perubahan tata letak, dan tugas panjang, yang semuanya dapat berdampak negatif pada performa pemuatan halaman situs dan khususnya skor Core Web Vital (CWV) situs Anda. Bersamaan dengan pelaporan masalah, Insight Performa akan memberikan saran yang dapat ditindaklanjuti untuk meningkatkan skor CWV, serta menyediakan link ke referensi dan dokumentasi lebih lanjut.
Panel ini bersifat eksperimental dan kami membutuhkan masukan Anda. Harap beri tahu kami jika Anda menemukan bug, atau memiliki permintaan fitur yang menurut Anda akan membantu saat memperbaiki performa situs.
Cara kami membuat Insight Performa
Seperti DevTools lainnya, kami membangun Insight Performa dalam TypeScript dan menggunakan komponen web, yang didukung oleh lit-html, untuk membangun antarmuka pengguna. Perbedaan Insight Performa adalah antarmuka UI utama adalah elemen canvas HTML, dan linimasa digambar pada kanvas ini. Banyak kerumitan berasal dari pengelolaan kanvas ini: tidak hanya menggambar detail yang tepat di tempat yang tepat, tetapi mengelola peristiwa mouse (misalnya: di mana pengguna mengklik kanvas? Apakah mereka mengklik acara yang telah kita gambar?) dan memastikan bahwa kita merender ulang kanvas secara efektif.
Beberapa trek di satu kanvas
Untuk situs web tertentu, ada beberapa "jalur" yang ingin kita render, masing-masing mewakili kategori data yang berbeda. Misalnya, panel Insight akan menampilkan tiga jalur secara default:
Seiring kami terus menambahkan fitur pada panel, kami berharap lebih banyak trek akan ditambahkan.
Pemikiran awal kami adalah agar setiap jalur ini merender <canvas>-nya sendiri, sehingga tampilan utama akan menjadi beberapa elemen kanvas yang ditumpuk secara vertikal. Hal ini akan menyederhanakan rendering di tingkat jalur, karena setiap trek dapat dirender secara terpisah dan tidak akan ada bahaya rendering trek di luar batasnya, tetapi sayangnya pendekatan ini memiliki dua masalah utama:
Elemen canvas mahal untuk dirender (ulang); memiliki beberapa kanvas akan lebih mahal daripada satu kanvas, meskipun kanvas tersebut lebih besar.
Merender overlay yang melintasi beberapa jalur (misalnya, garis vertikal untuk menandai peristiwa seperti waktu FCP) menjadi rumit: kita harus merender ke beberapa kanvas dan memastikan semuanya dirender bersama dan disejajarkan dengan benar.
Menggunakan satu canvas untuk seluruh UI berarti kami perlu mencari tahu cara memastikan setiap jalur dirender pada koordinat yang tepat dan tidak meluber ke jalur lain. Misalnya, jika trek tertentu memiliki tinggi 100 px, kami tidak dapat mengizinkannya merender sesuatu yang tingginya 120 px dan membuatnya masuk ke trek yang ada di bawahnya. Untuk mengatasi hal ini, kita dapat menggunakan clip. Sebelum merender setiap trek, kita menggambar persegi panjang yang mewakili jendela trek yang terlihat. Hal ini memastikan bahwa setiap jalur yang digambar di luar batas ini akan terpotong oleh kanvas.
canvasContext.beginPath();
canvasContext.rect(
trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();
Kami juga tidak ingin setiap trek mengetahui posisinya secara vertikal: setiap trek akan merender dirinya sendiri seolah-olah dirender pada (0, 0), dan kami memiliki komponen level yang lebih tinggi (yang kami sebut TrackManager) untuk mengelola posisi trek secara keseluruhan. Hal ini dapat dilakukan dengan translate, yang menerjemahkan kanvas berdasarkan posisi (x, y) tertentu. Contoh:
canvasContext.translate(0, 10); // Translate by 10px in the y direction
canvasContext.rect(0, 0, 10, 10); // draw a rectangle at (0, 0) that’s 10px high and wide
Meskipun kode rect menyetel 0, 0 sebagai posisi, keseluruhan terjemahan yang diterapkan akan menyebabkan persegi panjang dirender pada 0, 10. Hal ini memungkinkan kami mengerjakan setiap trek seolah-olah kami merender pada (0, 0), dan meminta pengelola trek kami menerjemahkan saat merender setiap trek untuk memastikan setiap trek dirender dengan benar di bawah yang sebelumnya.
Kanvas luar layar untuk trek dan sorotan
Rendering kanvas relatif mahal, dan kami ingin memastikan panel Insights tetap mulus dan responsif saat Anda menggunakannya. Terkadang, Anda tidak dapat melakukan rendering ulang seluruh kanvas: misalnya, jika Anda mengubah tingkat zoom, kita harus memulai dari awal dan merender ulang semuanya. Rendering ulang kanvas sangat mahal karena Anda tidak bisa hanya me-render ulang sebagian kecil darinya; Anda perlu menghapus seluruh kanvas dan menggambar ulang. Ini tidak seperti rendering ulang DOM karena alat dapat menghitung pekerjaan minimal yang diperlukan dan tidak menghapus semuanya dan memulai lagi.
Salah satu area masalah visual yang menjadi fokus kami adalah sorotan. Saat Anda mengarahkan kursor ke metrik di panel, kami akan menandainya di linimasa, dan juga jika Anda mengarahkan kursor ke Insight untuk peristiwa tertentu, kami akan menggambar batas biru di sekitar peristiwa tersebut.
Fitur ini pertama kali diimplementasikan dengan mendeteksi gerakan mouse di atas elemen yang memicu sorotan, lalu menggambar sorotan tersebut langsung ke kanvas utama. Masalah kita muncul saat kita harus menghapus sorotan: satu-satunya pilihan adalah menggambar ulang semuanya. Tidak mungkin untuk hanya menggambar ulang area di mana sorotan tersebut (bukan tanpa perubahan arsitektur yang besar), tetapi menggambar ulang seluruh kanvas hanya karena kita ingin menghapus batas biru di sekitar satu item terasa seperti berlebihan. Selain itu, visual ini juga tertinggal secara visual jika Anda dengan cepat mengarahkan mouse ke item yang berbeda untuk memicu beberapa sorotan secara cepat.
Untuk memperbaikinya, kami membagi UI menjadi dua kanvas di luar layar: kanvas “utama”, tempat trek dirender, dan kanvas “sorotan”, tempat sorotan digambar. Kemudian, kami merender dengan menyalin kanvas tersebut ke satu kanvas yang terlihat di layar oleh pengguna. Kita dapat menggunakan metode drawImage pada konteks kanvas, yang dapat menggunakan kanvas lain sebagai sumbernya.
Dengan melakukan hal ini, artinya menghapus sorotan tidak menyebabkan kanvas utama digambar ulang: sebagai gantinya, kita dapat membersihkan kanvas di layar, lalu menyalin kanvas utama ke kanvas yang terlihat. Tindakan menyalin kanvas tidaklah murah, tetapi biayanya mahal. Jadi, dengan memindahkan sorotan ke kanvas yang terpisah, kita akan menghindari biaya tersebut saat mengaktifkan dan menonaktifkan sorotan.
Penguraian rekaman aktivitas yang teruji secara komprehensif
Salah satu manfaat membangun fitur baru dari awal adalah Anda dapat merefleksikan pilihan teknis yang dibuat sebelumnya dan melakukan peningkatan. Salah satu hal yang ingin kami tingkatkan adalah dengan membagi kode secara eksplisit menjadi dua bagian yang hampir sepenuhnya berbeda:
Mengurai file rekaman aktivitas dan mengambil data yang diperlukan. Merender kumpulan trek.
Dengan memisahkan penguraian (bagian 1) dari tugas UI (bagian 2), kita dapat membuat sistem penguraian yang solid; setiap trace dijalankan melalui serangkaian Pengendali yang bertanggung jawab atas berbagai masalah: LayoutShiftHandler menghitung semua informasi yang diperlukan untuk Pergeseran Tata Letak dan NetworkRequestsHandler secara eksklusif menangani permintaan jaringan. Memiliki langkah penguraian eksplisit saat kami memiliki pengendali berbeda yang bertanggung jawab untuk berbagai bagian dari pelacakan juga bermanfaat: penguraian pelacakan bisa menjadi sangat rumit, dan membantu untuk berfokus pada satu masalah pada satu waktu.
Kami juga dapat menguji secara komprehensif penguraian pelacakan dengan mengambil rekaman di DevTools, menyimpannya, lalu memuatnya sebagai bagian dari rangkaian pengujian kami. Hal ini sangat bagus karena kami dapat menguji dengan trace asli, dan tidak membuat data trace palsu dalam jumlah besar yang dapat menjadi usang.
Pengujian screenshot untuk UI kanvas
Tetap pada topik pengujian, kita biasanya menguji komponen frontend dengan merendernya ke browser dan memastikannya berperilaku seperti yang diharapkan; kita dapat mengirim peristiwa klik untuk memicu update, dan menegaskan bahwa DOM yang dihasilkan komponen sudah benar. Pendekatan ini bekerja dengan baik, tetapi gagal saat mempertimbangkan rendering ke kanvas; tidak ada cara untuk memeriksa kanvas dan menentukan apa yang digambar di sana. Jadi, pendekatan kami yang biasa untuk rendering lalu pembuatan kueri tidak tepat.
Agar memiliki cakupan pengujian, kita beralih ke pengujian screenshot. Setiap pengujian mengaktifkan kanvas, merender trek yang ingin diuji, lalu mengambil screenshot elemen kanvas. Screenshot ini kemudian disimpan di codebase kami, dan pengujian mendatang akan membandingkan screenshot yang disimpan dengan screenshot yang dihasilkan. Jika screenshot berbeda, pengujian akan gagal. Kami juga menyediakan flag untuk menjalankan pengujian dan memaksa pembaruan screenshot jika kami sengaja mengubah rendering dan mengharuskan pengujian diperbarui.
Pengujian screenshot tidak sempurna dan sedikit tumpul; Anda hanya dapat menguji apakah seluruh komponen dirender seperti yang diharapkan, bukan pernyataan yang lebih spesifik, dan awalnya kami bersalah menggunakannya secara berlebihan untuk memastikan setiap komponen (HTML atau kanvas) dirender dengan benar. Hal ini memperlambat rangkaian pengujian kami secara drastis, dan menyebabkan masalah saat penyesuaian UI kecil yang hampir tidak relevan (seperti perubahan warna yang halus, atau menambahkan beberapa margin antar-item) menyebabkan beberapa screenshot gagal dan perlu diperbarui. Kami sekarang telah mengurangi penggunaan screenshot, dan menggunakannya hanya untuk komponen berbasis kanvas, dan keseimbangan ini bekerja dengan baik untuk kami sejauh ini.
Kesimpulan
Membuat panel Insight Performa baru merupakan pengalaman edukatif yang sangat menyenangkan bagi tim. Kita telah mempelajari banyak hal tentang file rekaman aktivitas, bekerja dengan kanvas, dan banyak lagi. Kami harap Anda senang menggunakan panel baru ini, dan kami tidak sabar mendengar masukan dari Anda.
Untuk mempelajari panel Insight Performa lebih lanjut, lihat Insight performa: Mendapatkan hasil analisis yang bisa ditindaklanjuti tentang performa situs Anda.
Mendownload saluran pratinjau
Pertimbangkan untuk menggunakan Chrome Canary, Dev, atau Beta sebagai browser pengembangan default Anda. Saluran pratinjau ini memberi Anda akses ke fitur DevTools terbaru, menguji API platform web tercanggih, dan menemukan masalah di situs Anda sebelum pengguna melakukannya.
Menghubungi tim Chrome DevTools
Gunakan opsi berikut untuk membahas fitur dan perubahan baru di postingan, atau hal lain yang berkaitan dengan DevTools.
- Kirim saran atau masukan kepada kami melalui crbug.com.
- Laporkan masalah DevTools menggunakan Opsi lainnya
> Bantuan > Laporkan masalah DevTools di DevTools. - Tweet di @ChromeDevTools.
- Berikan komentar di video YouTube Apa yang baru di DevTools atau video YouTube Tips DevTools.