Cara dan alasan kami membuat Insight Performa

Jack Franklin

Di Chrome 102, Anda akan melihat panel eksperimental baru, Insight Performa, di DevTools. Dalam postingan ini, kita tidak hanya akan membahas alasan kami mengerjakan panel baru, tetapi juga tantangan teknis yang kami hadapi dan keputusan yang kami buat selama prosesnya.

ALT_TEXT_HERE

Mengapa perlu membuat panel lain?

(Jika Anda belum melihatnya, kami memposting video tentang alasan pembuatan panel Insight Performa dan cara mendapatkan insight yang dapat ditindaklanjuti tentang performa situs Anda dengan panel tersebut.)

Panel Performa yang ada adalah sumber daya yang bagus jika Anda ingin melihat semua data untuk situs Anda di satu tempat, tetapi kami merasa bahwa data tersebut bisa sedikit membingungkan. Jika Anda bukan pakar performa, akan sulit untuk mengetahui secara pasti apa yang harus dicari dan bagian rekaman mana yang relevan.

Masuk ke Panel Insight, tempat Anda masih dapat melihat linimasa rekaman aktivitas dan memeriksa data, tetapi juga mendapatkan daftar praktis tentang apa yang dianggap DevTools sebagai “Insight” utama yang perlu diselidiki. Insight akan mengidentifikasi masalah seperti permintaan pemblokiran rendering, pergeseran tata letak, dan tugas panjang, yang semuanya dapat berdampak negatif pada performa pemuatan halaman situs Anda dan khususnya skor Data Web Inti (CWV) situs Anda. Selain menandai masalah, Analisis Performa akan memberikan saran yang dapat ditindaklanjuti untuk meningkatkan skor CWV Anda, dan memberikan link ke referensi dan dokumentasi lebih lanjut.

Link masukan di panel

Panel ini bersifat eksperimental dan kami ingin mendengar masukan Anda. Beri tahu kami jika Anda menemukan bug, atau memiliki permintaan fitur yang menurut Anda akan membantu Anda saat berupaya meningkatkan performa situs.

Cara kami membuat Insight Performa

Seperti DevTools lainnya, kami membangun Insight Performa di TypeScript dan menggunakan komponen web, yang didukung oleh lit-html, untuk membangun antarmuka pengguna. Perbedaan utama Performance Insights adalah antarmuka UI utamanya adalah elemen canvas HTML, dan linimasa digambar ke kanvas ini. Banyak kompleksitas berasal dari pengelolaan kanvas ini: tidak hanya menggambar detail yang tepat di tempat yang tepat, tetapi juga mengelola peristiwa mouse (misalnya: di mana pengguna mengklik kanvas? Apakah mereka mengklik peristiwa yang telah kita gambar?) dan memastikan bahwa kita merender ulang kanvas secara efektif.

Beberapa jalur di satu kanvas

Untuk situs tertentu, ada beberapa “jalur” yang ingin kita render, yang masing-masing merepresentasikan kategori data yang berbeda. Misalnya, panel Insight akan menampilkan tiga jalur secara default:

Seiring kami terus meluncurkan fitur di panel, kami berharap lebih banyak jalur akan ditambahkan.

Awalnya, kami berpikir bahwa setiap jalur ini akan merender <canvas>-nya sendiri, sehingga tampilan utama akan menjadi beberapa elemen kanvas yang disusun secara vertikal. Hal ini akan menyederhanakan rendering di tingkat jalur, karena setiap jalur dapat dirender secara terpisah dan tidak ada bahaya jalur dirender di luar batasnya, tetapi sayangnya pendekatan ini memiliki dua masalah utama:

Elemen canvas mahal untuk (di)render ulang; memiliki beberapa kanvas lebih mahal daripada satu kanvas, meskipun kanvas tersebut lebih besar. Merender overlay apa pun 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.

Dengan menggunakan satu canvas untuk seluruh UI, kami harus mencari tahu cara memastikan setiap jalur dirender pada koordinat yang tepat dan tidak meluap ke jalur lain. Misalnya, jika jalur tertentu memiliki tinggi 100 px, kita tidak dapat mengizinkannya merender sesuatu yang tingginya 120 px dan meluber ke jalur di bawahnya. Untuk mengatasinya, kita dapat menggunakan clip. Sebelum merender setiap jalur, kita menggambar persegi panjang yang merepresentasikan jendela jalur yang terlihat. Hal ini memastikan bahwa jalur apa pun yang digambar di luar batas ini akan dipangkas oleh kanvas.

canvasContext.beginPath();
canvasContext.rect(
    trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();

Kami juga tidak ingin setiap jalur mengetahui posisi vertikalnya: setiap jalur harus merender dirinya seolah-olah merender di (0, 0), dan kami memiliki komponen tingkat yang lebih tinggi (yang kami sebut TrackManager) untuk mengelola posisi jalur 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 setelan kode rect menetapkan 0, 0 sebagai posisi, terjemahan keseluruhan yang diterapkan akan menyebabkan persegi dirender di 0, 10. Hal ini memungkinkan kita bekerja berdasarkan jalur seolah-olah kita merender di (0, 0), dan membuat pengelola jalur menerjemahkan saat merender setiap jalur untuk memastikan setiap jalur dirender dengan benar di bawah jalur sebelumnya.

Kanvas di luar layar untuk trek dan sorotan

Rendering kanvas relatif mahal, dan kami ingin memastikan panel Insight tetap lancar dan responsif saat Anda menggunakannya. Terkadang Anda tidak dapat menghindari harus merender ulang seluruh kanvas: misalnya, jika Anda mengubah tingkat zoom, kita harus memulai lagi dan merender ulang semuanya. Render ulang kanvas sangat mahal karena Anda tidak dapat hanya merender ulang sebagian kecilnya; Anda harus menghapus seluruh kanvas dan menggambar ulang. Hal ini berbeda dengan rendering ulang DOM di mana alat dapat menghitung pekerjaan minimal yang diperlukan dan tidak menghapus semuanya lalu memulai lagi.

Salah satu area yang mengalami masalah visual adalah penyorotan. Saat Anda mengarahkan kursor ke metrik di panel, kami akan menandainya di linimasa, dan begitu juga jika Anda mengarahkan kursor ke Insight untuk peristiwa tertentu, kami akan menggambar batas biru di sekitar peristiwa tersebut.

Fitur ini pertama kali diterapkan 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 opsi adalah menggambar ulang semuanya. Tidak mungkin hanya menggambar ulang area tempat sorotan berada (tanpa perubahan arsitektur yang besar), tetapi menggambar ulang seluruh kanvas hanya karena kita ingin menghapus batas biru di sekitar satu item terasa berlebihan. Fitur ini juga tertunda secara visual jika Anda menggerakkan mouse dengan cepat ke berbagai item untuk memicu beberapa sorotan secara berurutan.

Untuk memperbaikinya, kita membagi UI menjadi dua kanvas di luar layar: kanvas “utama”, tempat trek dirender, dan kanvas “sorotan”, tempat sorotan digambar. Kemudian, kita merender dengan menyalin kanvas tersebut ke kanvas tunggal yang terlihat di layar oleh pengguna. Kita dapat menggunakan metode drawImage pada konteks kanvas, yang dapat menggunakan kanvas lain sebagai sumbernya.

Dengan melakukannya, penghapusan sorotan tidak akan menyebabkan kanvas utama digambar ulang: sebagai gantinya, kita dapat menghapus kanvas di layar, lalu menyalin kanvas utama ke kanvas yang terlihat. Tindakan menyalin kanvas tidak mahal, yang mahal adalah menggambar; jadi dengan memindahkan sorotan ke kanvas terpisah, kita menghindari biaya tersebut saat mengaktifkan dan menonaktifkan sorotan.

Penguraian rekaman aktivitas yang diuji 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 memisahkan kode secara eksplisit menjadi dua bagian yang hampir sepenuhnya berbeda:

Parse file rekaman aktivitas dan tarik data yang diperlukan. Merender sekumpulan jalur.

Dengan memisahkan penguraian (bagian 1) dari pekerjaan UI (bagian 2), kami dapat membangun sistem penguraian yang solid; setiap rekaman aktivitas dijalankan melalui serangkaian Handler yang bertanggung jawab atas berbagai masalah: LayoutShiftHandler menghitung semua informasi yang kita butuhkan untuk Pergeseran Tata Letak dan NetworkRequestsHandler secara eksklusif menangani penarikan permintaan jaringan. Memiliki langkah parsing eksplisit ini di mana kita memiliki berbagai handler yang bertanggung jawab atas berbagai bagian rekaman aktivitas juga bermanfaat: parsing rekaman aktivitas bisa menjadi sangat rumit, dan akan membantu jika kita dapat berfokus pada satu masalah dalam satu waktu.

Kami juga dapat menguji parsing rekaman aktivitas secara komprehensif dengan merekam aktivitas di DevTools, menyimpannya, lalu memuatnya sebagai bagian dari rangkaian pengujian kami. Hal ini sangat bagus karena kita dapat menguji dengan rekaman aktivitas nyata, dan tidak perlu membuat sejumlah besar data rekaman aktivitas palsu yang bisa menjadi usang.

Pengujian screenshot untuk UI kanvas

Tetap membahas topik pengujian, kami biasanya menguji komponen frontend dengan merendernya ke browser dan memastikan komponen tersebut berfungsi seperti yang diharapkan; kami dapat mengirimkan peristiwa klik untuk memicu update, dan menegaskan bahwa DOM yang dihasilkan komponen sudah benar. Pendekatan ini berfungsi dengan baik bagi kami, tetapi tidak berfungsi saat mempertimbangkan rendering ke kanvas; tidak ada cara untuk memeriksa kanvas dan menentukan apa yang digambar di sana. Jadi, pendekatan umum kita untuk merender lalu membuat kueri tidak sesuai.

Untuk memungkinkan kami memiliki beberapa cakupan pengujian, kami beralih ke pengujian screenshot. Setiap pengujian meluncurkan kanvas, merender jalur yang ingin kita uji, lalu mengambil screenshot elemen kanvas. Screenshot ini kemudian disimpan dalam codebase kami, dan uji coba mendatang akan membandingkan screenshot yang disimpan dengan screenshot yang dihasilkan. Jika screenshot berbeda, pengujian akan gagal. Kami juga menyediakan tanda untuk menjalankan pengujian dan memaksa pembaruan screenshot saat kami sengaja mengubah rendering dan perlu memperbarui pengujian.

Pengujian screenshot tidak sempurna dan sedikit tumpul; Anda hanya dapat menguji bahwa seluruh komponen dirender seperti yang diharapkan, bukan pernyataan yang lebih spesifik, dan awalnya kami bersalah karena terlalu sering menggunakannya 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 halus, atau menambahkan beberapa margin di antara item) menyebabkan beberapa screenshot gagal dan perlu diperbarui. Kami kini mengurangi penggunaan screenshot, dan menggunakannya hanya untuk komponen berbasis kanvas, dan keseimbangan ini berjalan dengan baik bagi kami sejauh ini.

Kesimpulan

Membangun panel Insight Performa baru telah menjadi pengalaman yang sangat menyenangkan dan mendidik bagi tim. Kita telah mempelajari banyak hal tentang file rekaman aktivitas, penggunaan kanvas, dan banyak lagi. Semoga Anda menikmati penggunaan panel baru ini, dan kami menantikan masukan Anda.

Untuk mempelajari panel Insight Performa lebih lanjut, lihat Insight performa: Dapatkan insight yang dapat 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, memungkinkan Anda menguji API platform web canggih, dan membantu Anda menemukan masalah di situs Anda sebelum pengguna Anda menemukannya.

Menghubungi tim Chrome DevTools

Gunakan opsi berikut untuk mendiskusikan fitur baru, update, atau hal lain yang terkait dengan DevTools.