JavaScript sering kali merupakan pemicu perubahan visual. Kadang-kadang itu langsung melalui manipulasi gaya, dan kadang-kadang perhitungannya yang akan mengakibatkan perubahan visual, seperti mencari atau menyortir beberapa data. JavaScript yang berjalan lama atau jelek pengaturan waktunya bisa menjadi penyebab umum masalah performa, dan Anda harus berusaha meminimalkan dampaknya sebisa mungkin.
Mengubah DOM, melalui penambahan dan penghapusan elemen, pengubahan atribut, class, atau animasi, semuanya akan menyebabkan browser menghitung ulang gaya elemen dan, dalam banyak kasus, menata ulang (atau mengubah posisi/geometri) halaman, atau bagiannya. Proses ini disebut penghitungan gaya terkomputasi.
Bagian pertama gaya komputasi adalah membuat seperangkat pemilih yang cocok, yang pada dasarnya browser akan mencari tahu class, pemilih pseudo, dan ID mana yang diterapkan pada elemen tertentu.
Bagian kedua dari proses ini melibatkan pengambilan semua aturan gaya dari pemilih yang cocok dan mencari tahu gaya akhir apa yang dimiliki elemen.
Ringkasan
- Bagaimana pengurangan biaya penghitungan gaya dapat menurunkan latensi interaksi.
- Kurangi kerumitan pemilih; gunakan metodologi yang berfokus pada kelas (misalnya, BEM).
- Kurangi jumlah elemen yang harus dihitung dalam penghitungan gaya.
Mengatur gaya waktu penghitungan ulang dan latensi interaksi
Interaction to Next Paint (INP) adalah metrik performa runtime yang berfokus pada pengguna yang menilai responsivitas keseluruhan halaman terhadap input pengguna. Saat latensi interaksi dinilai oleh metrik ini, metrik ini mengukur waktu mulai dari saat pengguna berinteraksi dengan halaman, hingga browser menggambar frame berikutnya yang menunjukkan update visual terkait yang dilakukan pada antarmuka pengguna.
Komponen signifikan dari interaksi adalah waktu yang diperlukan untuk menggambar {i>frame<i} berikutnya. Pekerjaan rendering yang dilakukan untuk menampilkan bingkai berikutnya terdiri dari banyak bagian, termasuk penghitungan gaya halaman yang terjadi tepat sebelum pekerjaan tata letak, penggambaran, dan pengomposisian. Meskipun artikel ini hanya berfokus pada biaya penghitungan gaya, perlu ditekankan bahwa mengurangi bagian mana pun dari fase rendering yang melekat pada interaksi akan mengurangi total latensi—termasuk penghitungan gaya.
Kurangi kerumitan pemilih
Dalam kasus yang paling sederhana, Anda dapat mereferensikan sebuah elemen di CSS hanya dengan class:
.title {
/* styles */
}
Namun, seiring perkembangan project, hal ini mungkin akan menghasilkan CSS yang lebih kompleks, sehingga Anda mungkin akan menemukan pemilih yang terlihat seperti ini:
.box:nth-last-child(-n+1) .title {
/* styles */
}
Untuk mengetahui bagaimana gaya ini diterapkan pada halaman, browser harus bertanya secara efektif "apakah ini elemen dengan class title yang memiliki induk yang kebetulan merupakan turunan ke-n plus 1 elemen dengan class box?" Mencari tahu hal ini dapat memerlukan banyak waktu, bergantung pada pemilih yang digunakan serta browser yang dimaksud. Perilaku pemilih yang dimaksud dapat diubah menjadi class:
.final-box-title {
/* styles */
}
Anda dapat membawa masalah dengan nama class, tetapi tugas tersebut menjadi jauh lebih sederhana untuk browser. Pada versi sebelumnya, untuk mengetahui, misalnya, bahwa elemen tersebut adalah yang terakhir dari jenisnya, browser harus terlebih dahulu mengetahui segalanya tentang semua elemen lainnya dan apakah ada elemen berikutnya yang akan menjadi nth-last-child, yang mungkin lebih mahal daripada sekadar mencocokkan pemilih dengan elemen karena class-nya cocok.
Mengurangi jumlah elemen yang ditata gayanya
Pertimbangan performa lainnya—yang biasanya merupakan faktor lebih penting untuk banyak pembaruan gaya—adalah banyaknya volume pekerjaan yang perlu dilakukan saat elemen berubah.
Dalam istilah umum, kasus terburuk untuk biaya penghitungan gaya elemen yang dihitung adalah jumlah elemen yang dikalikan dengan jumlah pemilih, karena setiap elemen perlu diperiksa setidaknya sekali terhadap setiap gaya untuk melihat kecocokannya.
Penghitungan gaya sering kali dapat ditargetkan ke beberapa elemen secara langsung, bukan membuat validasi halaman secara keseluruhan. Di browser modern, hal ini cenderung tidak menjadi masalah karena browser tidak perlu memeriksa semua elemen yang berpotensi terpengaruh oleh perubahan. Di sisi lain, browser lama tidak selalu dioptimalkan untuk tugas tersebut. Jika memungkinkan, Anda harus mengurangi jumlah elemen yang dibuat tidak valid.
Ukur biaya penghitungan ulang gaya
Salah satu cara untuk mengukur biaya rekalkulasi gaya adalah dengan menggunakan panel performa di Chrome DevTools. Untuk memulai, buka DevTools, buka tab berlabel Performa, tekan rekam, dan lakukan interaksi dengan halaman. Saat berhenti merekam, Anda akan melihat hasil seperti gambar di bawah:
Strip di bagian atas adalah miniatur flame chart yang juga memetakan frame per detik. Semakin dekat aktivitas ke bagian bawah strip, semakin cepat frame yang digambar oleh browser. Jika Anda melihat flame chart menyejajarkan di bagian atas dengan strip merah di atasnya, berarti Anda memiliki pekerjaan yang menyebabkan frame jangka panjang.
Jika Anda memiliki frame yang berjalan lama selama interaksi seperti men-scroll, maka harus diselidiki lebih lanjut. Jika Anda memiliki blok ungu besar, perbesar aktivitas dan pilih tugas apa pun yang diberi label Recalculate Style untuk mendapatkan informasi selengkapnya tentang pekerjaan penghitungan ulang gaya yang mungkin mahal.
Dalam contoh ini, ada pekerjaan penghitungan ulang gaya yang berjalan lama yang memerlukan waktu lebih dari 25 milidetik.
Jika Anda mengklik acara itu sendiri, Anda akan diberikan stack panggilan. Jika pekerjaan rendering disebabkan oleh interaksi pengguna, tempat di JavaScript yang bertanggung jawab untuk memicu perubahan gaya akan disebutkan. Selain itu, Anda juga mendapatkan jumlah elemen yang terpengaruh oleh perubahan—lebih dari 900 elemen dalam kasus ini—dan berapa lama waktu yang diperlukan untuk melakukan pekerjaan penghitungan gaya. Anda dapat menggunakan informasi ini untuk mulai mencoba menemukan perbaikan di kode Anda.
Menggunakan Blok, Elemen, Pengubah
Pendekatan untuk coding seperti BEM (Block, Element, Modifier) sebenarnya memasukkan manfaat performa pencocokan pemilih di atas, karena merekomendasikan agar segala sesuatu memiliki satu class, dan, jika Anda membutuhkan hierarki, juga akan disertakan ke dalam nama class:
.list {
/* Styles */
}
.list__list-item {
/* Styles */
}
Jika Anda memerlukan pengubah, seperti di atas di mana kita ingin melakukan sesuatu yang khusus untuk turunan terakhir, Anda dapat menambahkannya seperti ini:
.list__list-item--last-child {
/* Styles */
}
Jika Anda mencari cara yang baik untuk mengatur CSS Anda, BEM adalah titik awal yang baik, baik dari sudut pandang struktur, dan juga karena penyederhanaan pencarian gaya yang dipromosikan oleh metodologi.
Jika Anda tidak menyukai BEM, ada cara lain untuk mendekati CSS Anda, tetapi pertimbangan performa harus dinilai bersama ergonomi pendekatan.
Referensi
Banner besar dari Unsplash, oleh Markus Spiske.