Mengurangi cakupan dan kompleksitas penghitungan gaya

Jeremy Wagner

Paul Lewis

JavaScript sering kali merupakan pemicu untuk perubahan visual. Terkadang, perubahan tersebut dibuat secara langsung melalui manipulasi gaya, dan terkadang melalui penghitungan yang menghasilkan perubahan visual, seperti menelusuri atau mengurutkan data. JavaScript yang berjalan lama atau jelek waktunya dapat menjadi penyebab umum masalah performa, dan Anda harus berusaha meminimalkan dampaknya sebisa mungkin.

Penghitungan gaya

Mengubah DOM dengan menambahkan dan menghapus elemen, mengubah atribut, class, atau memutar animasi akan menyebabkan browser menghitung ulang gaya elemen dan, dalam banyak kasus, tata letak sebagian atau seluruh halaman. Proses ini disebut penghitungan gaya terkomputasi.

Browser mulai menghitung gaya dengan membuat sekumpulan pemilih yang cocok untuk menentukan class, pemilih pseudo, dan ID mana yang diterapkan pada elemen yang diberikan. Kemudian, sistem akan memproses aturan gaya dari pemilih yang cocok dan mencari tahu gaya akhir yang dimiliki elemen tersebut.

Catatan: Sekitar setengah dari waktu yang digunakan di Blink (mesin rendering yang digunakan di Chromium dan browser turunan) untuk menghitung gaya terkomputasi suatu elemen digunakan untuk mencocokkan pemilih, dan separuh lainnya digunakan untuk membuat representasi gaya terkomputasi dari aturan yang cocok. Rune Lillesveen, Opera/ Invalidasi Gaya di Blink

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. Ini mengukur latensi interaksi dari saat pengguna berinteraksi dengan halaman hingga browser menggambar frame berikutnya yang menampilkan update visual terkait pada antarmuka pengguna.

Komponen penting dari interaksi adalah waktu yang diperlukan untuk menggambar frame berikutnya. Tugas rendering yang dilakukan untuk menampilkan frame berikutnya terdiri dari banyak bagian, termasuk penghitungan gaya halaman yang terjadi tepat sebelum pekerjaan tata letak, penggambaran, dan pengomposisian. Halaman ini berfokus pada biaya penghitungan gaya, tetapi mengurangi bagian mana pun dari fase rendering yang terkait dengan interaksi juga akan mengurangi total latensinya, termasuk untuk penghitungan gaya.

Kurangi kerumitan pemilih

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

.title {
  /* styles */
}

Namun, seiring berjalannya project apa pun, kemungkinan diperlukan CSS yang lebih kompleks, dan Anda mungkin akan memiliki pemilih yang terlihat seperti ini:

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

Untuk menentukan bagaimana gaya ini diterapkan pada halaman, browser harus secara efektif menanyakan "apakah ini elemen dengan class title yang induknya adalah elemen turunan minus-nth-plus-1 dengan class box?" Mencari tahu hal ini dapat memerlukan waktu lama, bergantung pada pemilih yang digunakan serta browser yang bersangkutan. Untuk menyederhanakannya, Anda dapat mengubah pemilih menjadi nama class saja:

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

Nama class pengganti ini mungkin tampak janggal, tetapi nama tersebut membuat tugas browser jauh lebih sederhana. Pada versi sebelumnya, misalnya, agar browser mengetahui sebuah elemen adalah yang terakhir dari jenisnya, browser harus mengetahui segala sesuatu tentang semua elemen lain terlebih dahulu untuk menentukan apakah ada elemen yang muncul setelahnya yang bisa berupa nth-last-child. Hal ini bisa jauh lebih mahal secara komputasi daripada menyesuaikan pemilih ke elemen hanya karena class-nya cocok.

Mengurangi jumlah elemen yang ditata gayanya

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

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

Catatan: Sebelumnya, jika Anda mengubah class pada satu elemen, semua turunannya akan membutuhkan penghitungan ulang gaya terkomputasi. Sekarang, beberapa browser mempertahankan sekumpulan kecil aturan yang unik untuk setiap elemen, yang menyebabkan gaya elemen dihitung ulang jika berubah. Artinya, sebuah elemen mungkin perlu dihitung ulang, bergantung pada lokasinya di hierarki, dan apa yang berubah.

Penghitungan gaya dapat menargetkan beberapa elemen secara langsung, bukan membatalkan validasi seluruh halaman. Pada browser modern, hal ini cenderung tidak menjadi masalah karena browser tidak selalu perlu memeriksa semua elemen yang mungkin terpengaruh oleh perubahan. Di sisi lain, browser lama tidak selalu dioptimalkan untuk tugas tersebut. Jika bisa, Anda harus mengurangi jumlah elemen yang dibatalkan validasinya.

Catatan: Penghitungan gaya di Komponen Web sedikit berbeda, karena gaya tidak melewati batas Shadow DOM secara default, dan dicakupkan ke komponen individual, bukan hierarki secara keseluruhan. Namun, secara keseluruhan, konsep yang sama masih berlaku: pohon yang lebih kecil dengan aturan yang lebih sederhana diproses secara lebih efisien daripada pohon yang lebih besar dengan aturan yang lebih kompleks.

Ukur biaya penghitungan ulang gaya

Salah satu cara untuk mengukur biaya rekalkulasi gaya adalah dengan menggunakan panel performa di Chrome DevTools. Lakukan hal berikut untuk memulai:

1. Buka DevTools.
2. Buka tab Performa.
3. Klik Record.
4. Berinteraksi dengan halaman.

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

Laporan DevTools yang menampilkan penghitungan gaya.

Strip di bagian atas adalah miniatur flame chart yang juga memetakan frame per detik. Semakin dekat aktivitas ke bagian bawah strip, semakin cepat frame di-cat oleh browser. Jika Anda melihat flame chart mendatar di bagian atas dengan batang merah di atasnya, berarti Anda memiliki pekerjaan yang menyebabkan frame yang berjalan lama.

Frame yang berjalan lama di ringkasan aktivitas DevTools.

Frame yang berjalan lama selama interaksi seperti men-scroll layak untuk dilihat lebih dekat. Jika Anda melihat blok ungu besar, perbesar aktivitas dan pilih pekerjaan apa pun yang berlabel Recalculate Style untuk mendapatkan informasi selengkapnya tentang pekerjaan perhitungan ulang gaya yang mungkin mahal.

Penghitungan ulang gaya yang berjalan lama yang memerlukan lebih dari 25&nbspmd di ringkasan DevTools.

Mengklik peristiwa akan menampilkan stack panggilannya. Jika pekerjaan rendering disebabkan oleh interaksi pengguna, proses ini akan memanggil JavaScript yang memicu perubahan gaya. Contoh ini juga menunjukkan jumlah elemen yang terpengaruh oleh perubahan tersebut—hanya lebih dari 900 elemen dalam kasus ini—dan berapa lama waktu yang diperlukan untuk 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) memanfaatkan manfaat performa pencocokan pemilih. BEM merekomendasikan agar semuanya memiliki satu class, dan, jika Anda memerlukan hierarki, hierarki tersebut juga akan disertakan ke dalam nama class:

.list {
  /* Styles */
}

.list__list-item {
  /* Styles */
}

Jika memerlukan pengubah, seperti pada contoh turunan terakhir, Anda dapat menambahkannya seperti ini:

.list__list-item--last-child {
  /* Styles */
}

BEM adalah titik awal yang baik untuk mengatur CSS, baik dari perspektif struktur, maupun karena penyederhanaan pencarian gaya yang dipromosikannya.

Jika Anda tidak menyukai BEM, ada cara lain untuk menggunakan CSS Anda, tetapi Anda harus menilai performa dan ergonominya sebelum memulai.

Referensi

• Pembatalan gaya di Blink
• BEM (Blok, Elemen, Pengubah)

Banner besar dari Unsplash, oleh Markus Spiske.