Cara Menulis CSS yang Lebih Baik dengan Kinerja dalam Pikiran
Dalam posting hari ini kita akan merenungkan pilihan kode yang dapat kita buat di CSS untuk meningkatkan kinerja situs. Tapi, sebelum kita menyelami pilihan-pilihan itu, mari kita lihat sebentar, lebih dekat pada alur kerja rendering halaman web untuk fokus padabidang bermasalah (kinerja-bijaksana) yang dipecahkan melalui CSS.
Inilah alur kasar operasi yang dilakukan oleh browser setelah pembuatan pohon DOM:
- Hitung Ulang Gaya (dan render pembuatan pohon). Browser menghitung gaya yang akan diterapkan pada elemen-elemen di pohon DOM. Pohon render kemudian dibuat saat membuang node (elemen) dari pohon DOM yang tidak akan dirender (elemen dengan
display: tidak ada
) dan mereka yang (elemen semu). - Tata Letak (alias Reflow). Menggunakan gaya yang dihitung dari sebelumnya, browser menghitung posisi dan geometri setiap elemen pada halaman.
- Mengecat ulang. Setelah tata letak dipetakan, piksel ditarik ke layar.
- Lapisan Komposit. Selama pengecatan ulang, lukisan itu dapat dilakukan dalam lapisan yang berbeda secara mandiri; lapisan-lapisan itu akhirnya digabungkan bersama.
Sekarang mari kita lanjutkan ke apa yang dapat kita lakukan dalam tiga tahap pertama operasi untuk menulis kode CSS yang berkinerja lebih baik.
1. Kurangi Perhitungan Gaya
Seperti disebutkan sebelumnya, pada tahap "Gaya Hitung Ulang" browser menghitung gaya yang akan diterapkan pada elemen. Untuk melakukan ini, browser terlebih dahulu menemukan semua penyeleksi dalam CSS yang menunjuk ke simpul elemen yang diberikan di pohon DOM. Kemudian ia melewati semua aturan gaya dalam pemilih tersebut dan memutuskan mana yang akan diterapkan pada elemen tersebut.
Untuk menghindari perhitungan gaya yang mahal, mengurangi pemilih yang kompleks dan sangat bersarang sehingga lebih mudah bagi browser untuk mencari tahu elemen mana yang dirujuk pemilih. Ini mengurangi waktu komputasi.
Cara lain untuk mempekerjakan termasuk mengurangi jumlah aturan gaya (jika memungkinkan), menghapus CSS yang tidak digunakan dan menghindari redundansi & penggantian, sehingga browser tidak harus melalui gaya yang sama berulang kali selama perhitungan gaya.
2. Kurangi Reflows
Perubahan reflow atau Layout pada suatu elemen adalah proses yang sangat "mahal", dan itu bisa menjadi masalah yang lebih besar ketika elemen yang mengalami perubahan tata letak memiliki jumlah anak yang signifikan (karena Reflows mengalir turun hierarki).
Reflow dipicu oleh perubahan tata letak elemen, seperti perubahan pada properti geometrik seperti tinggi atau ukuran font, penambahan atau penghapusan kelas ke elemen, ukuran jendela, diaktifkan : melayang
, Perubahan DOM oleh JavaScript, dll.
Sama seperti dalam perhitungan gaya, untuk mengurangi Reflows, hindari penyeleksi yang kompleks dan pohon DOM yang dalam (sekali lagi, ini untuk mencegah cascading Reflows yang berlebihan).
Jika Anda harus mengubah gaya tata letak komponen di halaman Anda, menargetkan gaya elemen yang paling rendah dalam hierarki elemen bahwa komponen terbuat dari. Ini dimaksudkan agar perubahan tata letak tidak memicu (hampir) Reflows lainnya.
Jika Anda menghidupkan elemen yang mengalami perubahan tata letak, keluarkan dari aliran halaman oleh secara tidak sengaja memposisikannya, karena Reflow pada elemen yang benar-benar diposisikan tidak akan memengaruhi elemen lainnya di halaman.
Untuk meringkas:
- Elemen target yang lebih rendah di pohon DOM saat membuat perubahan tata letak
- Pilih elemen yang benar-benar diposisikan untuk animasi perubahan tata letak
- Hindari menghidupkan properti tata letak bila memungkinkan
3. Kurangi Repaints
Cat ulang mengacu pada gambar piksel pada layar, dan merupakan proses yang mahal seperti Reflow. Repaints dapat dipicu oleh Reflows, scroll halaman, perubahan properti seperti warna, visibilitas dan opacity.
Untuk menghindari repaints yang sering dan besar, gunakan lebih sedikit properti yang menyebabkan pengecatan ulang yang mahal seperti bayangan.
Jika Anda menghidupkan properti dari elemen yang dapat memicu Pengecatan ulang secara langsung atau tidak langsung, itu akan sangat bermanfaat jika elemen itu ada di lapisannya sendiri mencegah proses pengecatannya mempengaruhi sisa halaman dan memicu akselerasi perangkat keras. Dalam akselerasi perangkat keras, GPU akan mengambil tugas melakukan perubahan animasi di lapisan, menghemat kerja ekstra CPU sambil mempercepat proses.
Di beberapa browser, kegelapan
(dengan nilai kurang dari 1
) dan mengubah
(nilai selain tidak ada
) secara otomatis dipromosikan ke lapisan baru, dan akselerasi perangkat keras diterapkan untuk animasi dan transisi. Memilih properti ini untuk animasi dengan demikian bagus.
Untuk dengan paksa mempromosikan elemen ke layer baru dan masuk ke akselerasi perangkat keras untuk animasi, ada dua teknik invovled:
- menambahkan
transform: translate3d (0, 0, 0);
ke elemen, menipu peramban agar memicu akselerasi perangkat keras untuk animasi dan transisi. - Tambahkan
akan berubah
properti ke elemen, yang memberi tahu peramban tentang properti yang kemungkinan akan berubah pada elemen di masa mendatang. Catatan: Sara Soueidan memiliki artikel yang mendalam dan sangat membantu tentang ini di situs Dev.Opera.
Untuk meringkas:
- Hindari gaya mahal yang menyebabkan Repaints
- Mencari promosi layer dan akselerasi perangkat keras untuk animasi dan transisi yang kuat.
Perhatikan
(1) Jadi sampai sekarang, kami belum menyentuh pengurangan ukuran file CSS. Kami telah menyebutkan bahwa pengurangan aturan gaya (dan elemen DOM) membuat peningkatan kinerja yang signifikan karena seberapa banyak browser harus bekerja kurang pada proses menghitung gaya. Sebagai konsekuensi dari pengurangan kode ini, menulis penyeleksi yang lebih baik dan penghapusan CSS yang tidak digunakan, ukuran file akan berkurang secara otomatis.
(2) Juga disarankan untuk tidak membuat terlalu banyak perubahan konsekuensial pada gaya elemen dalam JavaScript. Alih-alih menambahkan kelas ke elemen (menggunakan JavaScript) yang menampung gaya baru untuk melakukan perubahan ini - ini mencegah Reflows yang tidak perlu.
(3) Anda pasti mau hindari Layout Thrashing juga (Reflows sinkron paksa) yang timbul karena mengakses dan memodifikasi properti Layout elemen menggunakan JavaScript. Baca lebih lanjut tentang bagaimana ini membunuh kinerja di sini.