Mengurangi cakupan dan kompleksitas penghitungan gaya

Jeremy Wagner

JavaScript sering kali memicu perubahan visual. Terkadang hal itu membuat mereka perubahan langsung melalui manipulasi gaya, dan terkadang melalui penghitungan yang menghasilkan perubahan visual, seperti penelusuran atau pengurutan data. Kurang tepat waktu atau JavaScript yang berjalan lama dapat menjadi penyebab umum masalah kinerja, dan Anda harus berusaha meminimalkan dampaknya sebisa mungkin.

Penghitungan gaya

Mengubah DOM dengan menambah dan menghapus elemen, mengubah atribut, kelas, atau memutar animasi menyebabkan {i>browser<i} menghitung ulang gaya elemen dan, dalam banyak kasus, tata letak sebagian atau seluruh laman. Proses ini disebut penghitungan gaya.

{i>Browser<i} mulai menghitung gaya dengan membuat satu set pemilih yang cocok untuk menentukan class, pemilih semu, dan ID yang berlaku untuk elemen tertentu. Kemudian, ia memproses aturan gaya dari pemilih yang cocok dan mencari tahu gaya akhir apa yang dimiliki elemen.

Peran penghitungan ulang gaya dalam latensi interaksi

Interaction to Next Paint (INP) adalah runtime yang berfokus pada pengguna metrik performa yang menilai responsivitas halaman secara keseluruhan terhadap input pengguna. Latensi interaksi mengukur latensi interaksi dari saat pengguna berinteraksi dengan halaman hingga browser melukiskan {i>frame<i} berikutnya yang menunjukkan pembaruan visual yang sesuai untuk antarmuka pengguna.

Komponen penting dari suatu interaksi adalah waktu yang dibutuhkan untuk {i>frame<i}. Pekerjaan rendering yang dilakukan untuk menyajikan {i>frame<i} berikutnya terdiri dari banyak bagian, termasuk penghitungan gaya laman yang terjadi tepat sebelum tata letak, penggambaran, dan pekerjaan komposisi. Panduan ini berfokus pada biaya penghitungan gaya, tetapi mengurangi bagian mana pun dari total durasi rendering interaksi juga mengurangi total latensi yang rendah.

Mengurangi kompleksitas pemilih

Menyederhanakan pemilih CSS dapat membantu mempercepat penghitungan gaya halaman Anda. Pemilih paling sederhana mereferensikan elemen dalam CSS hanya dengan nama class:

.title {
  /* styles */
}

Namun, seiring perkembangan proyek, kemungkinan besar diperlukan CSS yang lebih kompleks, dan Anda mungkin mengakhiri dengan pemilih yang terlihat seperti ini:

.box:nth-last-child(-n+1) .title {
  /* styles */
}

Untuk menentukan bagaimana gaya ini diterapkan pada laman, browser harus secara efektif tanyakan "apakah ini elemen dengan class title dengan induk dari class box, yang merupakan turunan minus-n-plus-1 dari elemen induknya? Mencari tahu browser membutuhkan beberapa waktu. Untuk menyederhanakannya, Anda dapat mengubah pemilih menjadi nama class yang lebih spesifik:

.final-box-title {
  /* styles */
}

Nama kelas pengganti ini mungkin tampak canggung, tetapi mereka membuat pekerjaan menjadi jauh lebih sederhana. Dalam versi sebelumnya, misalnya, agar browser mengetahui sebuah elemen adalah yang terakhir dari jenisnya, ia harus terlebih dahulu mengetahui segala sesuatu tentang elemen lain untuk menentukan apakah ada elemen berikutnya yang dapat menjadi nth-last-child. Biaya komputasi ini bisa jauh lebih mahal dibandingkan mencocokkan pemilih dengan elemen berdasarkan nama class-nya.

Mengurangi jumlah elemen yang sedang ditata gayanya

Pertimbangan performa lainnya—dan sering kali lebih penting daripada pemilih kompleksitas — adalah jumlah pekerjaan yang perlu terjadi ketika elemen berubah.

Secara umum, kasus terburuk dari penghitungan gaya elemen komputasi adalah jumlah elemen dikalikan dengan jumlah pemilih, karena browser perlu memeriksa setiap elemen setidaknya sekali terhadap setiap gaya untuk melihat apakah yang cocok.

Penghitungan gaya dapat menargetkan beberapa elemen secara langsung, bukan membuat validasi seluruh halaman. Di {i>browser<i} modern, hal ini cenderung tidak terlalu bermasalah karena {i>browser<i} tidak selalu perlu memeriksa semua elemen yang mungkin dipengaruhi oleh perubahan. Di sisi lain, browser lama tidak selalu dioptimalkan untuk tugas semacam itu. Lokasi sebaiknya kurangi jumlah elemen yang tidak valid.

Mengukur biaya penghitungan ulang gaya

Ada beberapa cara untuk mengukur biaya penghitungan ulang gaya dalam browser. Masing-masing bergantung pada apakah ingin mengukurnya di browser atau tidak di lingkungan pengembangan Anda, atau jika Anda ingin mengukur berapa lama proses ini bagi pengguna aktual di {i>website<i} Anda.

Mengukur biaya penghitungan ulang gaya di Chrome DevTools

Salah satu cara untuk mengukur biaya penghitungan ulang gaya adalah dengan menggunakan di Chrome DevTools. Lakukan hal berikut untuk memulai:

  1. Buka DevTools.
  2. Buka tab Performa.
  3. Centang kotak Statistik pemilih (opsional).
  4. Klik Record.
  5. Berinteraksilah dengan halaman.

Saat berhenti merekam, Anda akan melihat sesuatu seperti gambar berikut:

DevTools menampilkan penghitungan gaya.
Laporan DevTools yang menampilkan penghitungan gaya.

Strip di bagian atas adalah flame chart miniatur yang juga memetakan frame per kedua. Semakin dekat aktivitas ke bagian bawah strip, semakin cepat {i>frame<i} sedang digambar oleh browser. Jika Anda melihat flame chart menipis di bagian atas dengan bilah merah di atasnya, maka Anda memiliki pekerjaan yang menyebabkan {i>frame<i} yang berjalan lama.

Memperbesar area masalah di Chrome DevTools dalam ringkasan aktivitas dari kolom yang di Chrome DevTools.
Frame yang berjalan lama di aktivitas DevTools ringkasan.

Frame yang berjalan lama selama interaksi seperti scroll lebih bernilai lihat. Jika Anda melihat blok ungu besar, perbesar aktivitas, lalu pilih berlabel ReCalculate Style untuk mendapatkan informasi lebih lanjut tentang perhitungan ulang gaya yang mahal.

Mendapatkan detail penghitungan gaya yang berjalan lama, termasuk informasi yang penting seperti sebagai jumlah elemen yang dipengaruhi oleh pekerjaan penghitungan ulang gaya.
Perhitungan ulang gaya yang berlangsung lama hanya dengan lebih dari 25&nbspmd dalam ringkasan DevTools.

Mengklik peristiwa akan menampilkan stack panggilannya. Jika pekerjaan rendering disebabkan oleh interaksi pengguna, fungsi ini memanggil JavaScript yang memicu perubahan gaya. Laporan ini juga menunjukkan jumlah elemen yang dipengaruhi oleh perubahan—lebih dari 900 dalam hal ini—dan berapa lama waktu yang dibutuhkan dalam penghitungan gaya. Anda dapat menggunakan informasi untuk mencoba menemukan perbaikan di kode Anda.

Jika Anda mencentang kotak Statistik pemilih di setelan Panel Performa sebelum melakukan pelacakan, lalu di bagian bawah panel di trace akan memiliki tab tambahan dengan nama yang sama.

Tabel statistik pemilih CSS seperti yang muncul di panel performa Chrome DevTools. Tabel ini berisi {i>header<i} dan data yang sesuai untuk hal-hal seperti waktu berlalu, percobaan, jumlah kecocokan, persentase node yang tidak cocok, pemilih, {i>style sheet<i} tempat mereka dapat ditemukan.
Tabel statistik pemilih seperti yang ditampilkan di panel performa Chrome DevTools.

Panel ini menyediakan data yang berguna mengenai biaya relatif setiap pemilih, yang memungkinkan mengidentifikasi pemilih CSS yang mahal.

Untuk informasi selengkapnya, lihat dokumentasi Statistik Pemilih CSS.

Mengukur biaya penghitungan ulang gaya untuk pengguna nyata

Jika Anda ingin tahu berapa lama waktu yang dibutuhkan untuk perhitungan ulang gaya untuk pengguna sebenarnya situs Anda, Long Animation Frames API memberi Anda alat yang diperlukan untuk melakukannya. Data dari API ini telah ditambahkan ke web-vitals library JavaScript, termasuk waktu penghitungan ulang gaya.

Jika Anda mencurigai bahwa penundaan presentasi dalam sebuah interaksi adalah sebagai kontributor INP halaman, sebaiknya Anda mencari tahu berapa banyak menghabiskan kalkulasi ulang gaya pada halaman. Untuk informasi selengkapnya, baca tentang cara mengukur waktu penghitungan ulang gaya di lapangan.

Resource

Banner besar dari Unsplash, oleh Markus Spiske.