Mengurangi cakupan dan kompleksitas penghitungan gaya

JavaScript sering kali memicu perubahan visual. Terkadang, perubahan tersebut dilakukan secara langsung melalui manipulasi gaya, dan terkadang melalui penghitungan yang menghasilkan perubahan visual, seperti menelusuri atau mengurutkan data. JavaScript yang berjalan lama atau yang pengaturan waktunya buruk 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, sebagian besar, tata letak sebagian atau seluruh halaman. Proses ini disebut penghitungan gaya.

Browser mulai menghitung gaya dengan membuat serangkaian pemilih yang cocok untuk menentukan class, pemilih semu, dan ID mana yang diterapkan pada elemen tertentu. Kemudian, aturan gaya diproses dari pemilih yang cocok dan mengetahui gaya akhir mana yang dimiliki elemen.

Peran penghitungan ulang gaya dalam latensi interaksi

Interaction to Next Paint (INP) adalah metrik performa runtime yang berfokus pada pengguna dan menilai responsivitas halaman secara keseluruhan terhadap input pengguna. Metrik ini mengukur latensi interaksi dari saat pengguna berinteraksi dengan halaman hingga browser merender frame berikutnya yang menampilkan update visual yang sesuai ke antarmuka pengguna.

Komponen penting dari interaksi adalah waktu yang diperlukan untuk merender frame berikutnya. Pekerjaan rendering yang dilakukan untuk menampilkan frame berikutnya terdiri dari banyak bagian, termasuk penghitungan gaya halaman yang terjadi tepat sebelum pekerjaan tata letak, gambar, dan komposisi. Panduan ini berfokus pada biaya penghitungan gaya, tetapi mengurangi bagian mana pun dari total durasi rendering interaksi juga akan mengurangi latensi totalnya.

Mengurangi kompleksitas pemilih

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

.title {
  /* styles */
}

Namun, dengan semakin besarnya project, project tersebut mungkin memerlukan CSS yang lebih kompleks, dan Anda mungkin akan mendapatkan pemilih yang terlihat seperti ini:

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

Untuk menentukan cara gaya ini diterapkan ke halaman, browser harus menanyakan secara efektif "apakah ini elemen dengan class title dengan induk class box yang merupakan turunan minus-nth-plus-1 dari elemen induknya? Memahami hal ini dapat memerlukan waktu beberapa saat untuk browser. Untuk menyederhanakannya, Anda dapat mengubah pemilih menjadi nama class yang lebih spesifik:

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

Nama class pengganti ini mungkin tampak canggung, tetapi nama tersebut membuat tugas browser jauh lebih sederhana. Misalnya, dalam versi sebelumnya, agar browser mengetahui elemen yang merupakan elemen terakhir dari jenisnya, browser harus mengetahui semuanya terlebih dahulu tentang semua elemen lain untuk menentukan apakah ada elemen yang datang setelahnya yang dapat menjadi nth-last-child. Secara komputasi, proses ini dapat jauh lebih mahal daripada mencocokkan pemilih dengan elemen berdasarkan satu-satunya nama class-nya.

Mengurangi jumlah elemen yang diberi gaya

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

Dalam artian umum, kasus terburuk untuk biaya penghitungan gaya elemen terkomputasi adalah jumlah elemen dikali jumlah pemilih, karena browser perlu memeriksa setiap elemen setidaknya sekali terhadap setiap gaya untuk mengetahui kecocokannya.

Penghitungan gaya dapat menargetkan beberapa elemen secara langsung, bukan membuat seluruh halaman menjadi tidak valid. Di browser modern, hal ini cenderung tidak terlalu menjadi masalah karena browser tidak selalu perlu memeriksa semua elemen yang mungkin terpengaruh oleh perubahan. Sebaliknya, browser lama tidak selalu dioptimalkan untuk tugas tersebut. Jika memungkinkan, Anda harus mengurangi jumlah elemen yang dibuat tidak valid.

Mengukur biaya penghitungan ulang gaya

Ada beberapa cara untuk mengukur biaya penghitungan ulang gaya di browser. Masing-masing bergantung pada apakah Anda ingin mengukurnya di browser di lingkungan pengembangan, atau apakah Anda ingin mengukur berapa lama proses ini dibutuhkan untuk pengguna sebenarnya di situs Anda.

Mengukur biaya penghitungan ulang gaya di Chrome DevTools

Salah satu cara untuk mengukur biaya penghitungan ulang gaya adalah menggunakan panel performa 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 diagram api miniatur yang juga memetakan frame per detik. Makin dekat aktivitas ke bagian bawah strip, makin cepat frame digambar oleh browser. Jika Anda melihat diagram api yang rata di bagian atas dengan batang merah di atasnya, berarti Anda memiliki tugas yang menyebabkan frame yang berjalan lama.

Memperbesar area masalah di Chrome DevTools dalam ringkasan aktivitas panel performa yang terisi di Chrome DevTools.
Frame yang berjalan lama di ringkasan aktivitas DevTools.

Frame yang berjalan lama selama interaksi seperti scroll perlu dilihat lebih dekat. Jika Anda melihat blok berwarna ungu yang besar, perbesar aktivitas tersebut dan pilih tugas apa pun yang berlabel ReCalculate Style untuk mendapatkan informasi selengkapnya tentang pekerjaan penghitungan ulang gaya yang berpotensi mahal.

Mendapatkan detail penghitungan gaya yang berjalan lama, termasuk informasi yang penting seperti jumlah elemen yang terpengaruh oleh pekerjaan penghitungan ulang gaya.
Penghitungan ulang gaya yang berjalan lama hanya memerlukan waktu lebih dari 25&nbspms dalam ringkasan DevTools.

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

Jika Anda mencentang kotak Statistik pemilih di setelan Panel Performa sebelum melakukan rekaman aktivitas, panel bawah dalam rekaman aktivitas akan memiliki tab tambahan dengan nama yang sama.

Tabel statistik pemilih CSS seperti yang
    muncul di panel performa Chrome DevTools. Tabel ini berisi header dan data yang sesuai untuk hal-hal seperti waktu berlalu, upaya pencocokan, jumlah kecocokan, persentase node yang tidak cocok, pemilih, dan style sheet yang dapat ditemukan.
Tabel statistik pemilih seperti yang ditampilkan di panel performa Chrome DevTools.

Panel ini memberikan data yang berguna tentang biaya relatif setiap pemilih, sehingga Anda dapat mengidentifikasi pemilih CSS yang mahal.

Untuk informasi selengkapnya, lihat dokumentasi Statistik Pemilih CSS.

Mengukur biaya penghitungan ulang gaya untuk pengguna sungguhan

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

Jika Anda mencurigai bahwa penundaan presentasi interaksi adalah kontributor utama ke INP halaman, Anda harus mencari tahu berapa banyak waktu yang dihabiskan untuk menghitung ulang gaya di halaman. Untuk informasi selengkapnya, baca artikel tentang cara mengukur waktu penghitungan ulang gaya di kolom.

Resource