Cara dan alasan kami membuat Insight Performa

Jack Franklin

Pada Chrome 102, Anda akan melihat panel eksperimental baru, Performance Insights, di DevTools. Dalam postingan ini, kita tidak hanya akan membahas alasan kami menyusun panel baru, tetapi juga tantangan teknis yang kami hadapi dan keputusan yang telah kami buat selama ini.

ALT_TEXT_HERE

Mengapa perlu membuat panel lain?

(Jika Anda belum melihatnya, kami telah memposting video tentang alasan membuat panel Analisis Performa dan cara mendapatkan insight yang bisa ditindaklanjuti tentang performa situs Anda dengan panel tersebut.)

Panel Performa yang ada adalah referensi yang bagus jika Anda ingin melihat semua data untuk situs Anda di satu tempat, tetapi kami merasa bahwa panel tersebut mungkin sedikit membingungkan. Jika Anda bukan pakar performa, akan sulit untuk mengetahui dengan tepat 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 dipelajari. Insight akan mengidentifikasi masalah seperti permintaan pemblokiran rendering, pergeseran tata letak, dan tugas yang lama, 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 bisa 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 mendapatkan masukan dari Anda. Beri tahu kami jika Anda menemukan bug, atau memiliki permintaan fitur yang menurut Anda akan membantu Anda saat meningkatkan performa situs.

Cara kami membuat Insight Performa

Seperti DevTools lainnya, kami mem-build Performance Insights di TypeScript dan menggunakan komponen web, yang didukung oleh lit-html, untuk mem-build antarmuka pengguna. Perbedaan Performance Insights adalah antarmuka UI utama adalah elemen canvas HTML, dan linimasa digambar ke kanvas ini. Banyak kompleksitas yang 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, masing-masing mewakili kategori data yang berbeda. Misalnya, panel Insight akan menampilkan tiga jalur secara default:

Dan seiring kami terus menghadirkan fitur di panel, kami berharap lebih banyak trek yang 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 jalur dapat dirender secara terpisah dan tidak akan ada bahaya rendering jalur di luar batasnya, tetapi sayangnya pendekatan ini memiliki dua masalah utama:

Elemen canvas mahal untuk dirender (ulang); memiliki beberapa kanvas 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 sejajar dengan benar.

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

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

Kita juga tidak ingin setiap jalur harus mengetahui posisinya secara vertikal: setiap jalur harus merender sendiri seolah-olah merender di (0, 0), dan kita memiliki komponen tingkat yang lebih tinggi (yang kita sebut TrackManager) untuk mengelola keseluruhan posisi jalur. Hal ini dapat dilakukan dengan translate, yang menerjemahkan kanvas dengan 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 menetapkan 0, 0 sebagai posisi, terjemahan keseluruhan yang diterapkan akan menyebabkan persegi panjang dirender di 0, 10. Hal ini memungkinkan kita bekerja berdasarkan jalur seolah-olah kita merender di (0, 0), dan meminta 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 render ulang seluruh kanvas: misalnya, jika Anda mengubah tingkat zoom, kita harus memulai lagi dan merender ulang semuanya. Rendering ulang kanvas sangat mahal karena Anda tidak bisa merender ulang sebagian kecil saja; Anda perlu menghapus seluruh kanvas dan menggambar ulang. Hal ini berbeda dengan rendering ulang DOM, yaitu alat dapat menghitung pekerjaan minimum yang diperlukan dan tidak menghapus semuanya dan memulai lagi.

Salah satu area yang mengalami masalah visual adalah sorotan. Saat Anda mengarahkan kursor ke metrik di panel, kami akan menandainya di linimasa, dan demikian pula 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 pada elemen yang memicu sorotan, lalu menggambar sorotan tersebut langsung ke kanvas utama. Masalahnya muncul saat kita harus menghapus sorotan: satu-satunya opsi adalah menggambar ulang semuanya. Kita tidak dapat menggambar ulang area tempat sorotan berada (tidak tanpa perubahan arsitektur yang besar), tetapi menggambar ulang seluruh kanvas hanya karena kita ingin menghapus batas biru di sekitar satu item terasa berlebihan. Tindakan ini juga akan mengalami kelambatan visual jika Anda menggerakkan mouse dengan cepat ke berbagai item untuk memicu beberapa sorotan secara berurutan.

Untuk memperbaikinya, kami 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 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 ini, menghapus 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 itu murah, karena gambarnya mahal. Jadi dengan memindahkan sorotan ke kanvas terpisah, kita menghindari biaya tersebut saat menyalakan dan mematikan sorotan.

Penguraian trace yang diuji secara komprehensif

Salah satu manfaat membuat fitur baru dari awal adalah Anda dapat merenungkan pilihan teknis yang dibuat sebelumnya dan melakukan peningkatan. Salah satu hal yang ingin kami tingkatkan adalah dengan memisahkan kode secara eksplisit menjadi dua bagian yang hampir sepenuhnya berbeda:

Mengurai file rekaman aktivitas dan mengambil data yang diperlukan. Merender kumpulan trek.

Memisahkan penguraian (bagian 1) dari pekerjaan UI (bagian 2) memungkinkan kita membuat sistem penguraian yang solid; setiap rekaman aktivitas dijalankan melalui serangkaian Pemroses yang bertanggung jawab atas masalah yang berbeda: LayoutShiftHandler menghitung semua informasi yang kita perlukan untuk Pergeseran Tata Letak dan NetworkRequestsHandler secara eksklusif menangani pengambilan permintaan jaringan. Memiliki langkah penguraian eksplisit ini dengan pengendali yang berbeda yang bertanggung jawab atas berbagai bagian rekaman aktivitas juga bermanfaat: penguraian rekaman aktivitas bisa menjadi sangat rumit, dan hal ini membantu kita dapat berfokus pada satu masalah dalam satu waktu.

Kami juga dapat menguji penguraian rekaman aktivitas secara komprehensif dengan mengambil rekaman di DevTools, menyimpannya, lalu memuat rekaman tersebut sebagai bagian dari rangkaian pengujian kami. Hal ini sangat bagus karena kita dapat menguji dengan rekaman aktivitas yang sebenarnya, dan tidak membuat data rekaman aktivitas palsu dalam jumlah besar yang dapat menjadi usang.

Pengujian screenshot untuk UI kanvas

Dengan tetap berada pada topik pengujian, kita biasanya menguji komponen frontend dengan merendernya ke dalam browser dan memastikan komponen tersebut berperilaku seperti yang diharapkan; kita dapat mengirimkan peristiwa klik untuk memicu update, dan menyatakan bahwa DOM yang dihasilkan komponen sudah benar. Pendekatan ini berfungsi dengan baik untuk kita, tetapi gagal saat mempertimbangkan rendering ke kanvas; tidak ada cara untuk memeriksa kanvas dan menentukan apa yang digambar di sana. Jadi, pendekatan rendering dan kueri yang biasa kita lakukan tidak sesuai.

Agar dapat memiliki beberapa cakupan pengujian, kami beralih ke pengujian screenshot. Setiap pengujian akan mengaktifkan kanvas, merender jalur yang ingin diuji, lalu mengambil screenshot elemen kanvas. Screenshot ini kemudian disimpan di codebase kami, dan pengujian selanjutnya 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 memerlukan pembaruan pengujian.

Pengujian screenshot tidak sempurna dan sedikit kasar; Anda hanya dapat menguji apakah seluruh komponen dirender seperti yang diharapkan, bukan pernyataan yang lebih spesifik, dan pada 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 tweak UI kecil yang hampir tidak relevan (seperti perubahan warna yang halus, atau menambahkan beberapa margin di antara item) menyebabkan beberapa screenshot gagal dan memerlukan pembaruan. Kami sekarang telah mengurangi penggunaan screenshot, dan menggunakannya hanya untuk komponen berbasis kanvas, dan keseimbangan ini telah berjalan dengan baik bagi kami sejauh ini.

Kesimpulan

Membuat panel Insight Performa yang baru merupakan pengalaman edukatif yang sangat menyenangkan bagi tim. Kita telah mempelajari banyak hal tentang file rekaman aktivitas, menggunakan kanvas, dan banyak lagi. Semoga Anda menikmati penggunaan panel baru ini, dan kami tidak sabar ingin mendengar masukan Anda.

Untuk mempelajari panel Insight Performa lebih lanjut, lihat Insight performa: Dapatkan insight yang bisa ditindaklanjuti tentang performa situs Anda.

Mendownload saluran pratinjau

Sebaiknya gunakan 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 sebelum pengguna melakukannya.

Hubungi tim Chrome DevTools

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