Transisi dan animasi yang dijalankan pada properti yang keliru membuat halaman terasa berat: gerakan tersendat, kursor terasa lemot, dan baterai perangkat cepat terkuras. Penyebabnya bukan durasi yang terlalu panjang, melainkan pekerjaan yang dipaksa browser ulangi pada setiap frame. Dengan memahami alur render dan memilih properti yang murah, mayoritas animasi UI dapat berjalan mulus tanpa JavaScript tambahan. Pada Chapter ini kita menelusuri alur tersebut, membandingkan properti murah dan mahal, lalu membahas will-change beserta batas pemakaiannya.
Alur Render: Style, Layout, Paint, Composite #
Untuk menampilkan satu frame, browser menjalankan empat tahap berurutan:
- Style: browser menghitung gaya akhir (computed style) untuk setiap elemen — pekerjaan cascade yang kita bahas sejak awal Course ini.
- Layout: browser menghitung geometri — posisi dan ukuran setiap kotak. Perubahan
width,height,margin, atautopmemicu tahap ini diulang. - Paint: browser mengisi piksel pada setiap bagian yang berubah — teks, warna, bayangan, dan border digambar ulang.
- Composite: browser menyusun lapisan-lapisan yang sudah digambar menjadi frame akhir di layar.
Semakin awal tahap yang perlu diulang, semakin berat satu frame. Animasi yang mengubah geometri mengulang layout, paint, dan composite pada 60 frame setiap detik; animasi yang hanya menyusun ulang lapisan cukup berhenti di tahap terakhir — dan tahap inilah yang dikerjakan GPU dengan sangat cepat.
Properti Murah dan Properti Mahal #
Dua properti berdiri di kelompok paling murah: transform
menggerakkan, memutar, dan menskalakan elemen yang sudah digambar, sedangkan opacity mengatur tembus pandangnya. Keduanya bekerja pada tahap composite. Sebaliknya, properti geometri memaksa browser menghitung ulang seluruh tata letak di sekitar elemen:
| Properti | Tahap yang diulang | Contoh pemakaian |
|---|---|---|
transform, opacity | Composite saja | Geser, putar, skala, memudar |
color, background-color, box-shadow | Paint + composite | Perubahan warna dan bayangan |
width, height, padding, margin, top, left | Layout + paint + composite | Ubah ukuran, geser posisi |
Demo chapter ini menampilkan dua kartu beranimasi plus satu kotak statis:
/* Murah: composite saja */
.kartu-melayang {
opacity: 0.9;
will-change: transform;
animation: angkat 2s ease-in-out infinite alternate;
}
@keyframes angkat {
from { transform: translateY(0); }
to { transform: translateY(-12px); }
}
/* Mahal: layout diulang setiap frame */
.kartu-langkah {
animation: geser-kiri 2s linear infinite alternate;
}
@keyframes geser-kiri {
from { left: 0; }
to { left: 24px; }
}Mari kita telaah perbedaannya:
- Baris 3–4 (
opacity: 0.9,will-change: transform): kartu setengah tembus pandang dan diberi tanda akan dianimasikan lewattransform— browser menyiapkan lapisan terpisah untuknya sejak awal. - Baris 5–9 (keyframes
angkat): perjalanantranslateYdari 0 ke -12 piksel. Nilai yang dianimasikan adalahtransform, sehingga layout tidak pernah dihitung ulang. - Baris 12–17 (keyframes
geser-kiri): perjalananleftdari 0 ke 24 piksel. Meskipun gerakannya terlihat sama di layar, setiap frame memaksa browser menghitung ulang layout, menggambar ulang, lalu menyusun ulang — tiga kali lipat pekerjaan untuk hasil visual yang identik.
Hasil di Browser:
Dua kartu beranimasi tampil di demo: kartu-melayang bergerak naik-turun
via transform (will-change "transform", opacity statis "0.9"), dan
kartu-langkah bergeser via properti left. Nilai computed yang diperiksa
harness: will-change "transform", opacity "0.9", animation-name
"angkat" dan "geser-kiri" dengan duration "2s", serta transform statis
"matrix(1, 0, 0, 1, 0, 6)" pada kotak pembanding.will-change dan Praktik Hemat #
will-change
memberi tahu browser properti apa yang akan berubah, sehingga browser dapat menyiapkan lapisan dan memori lebih awal. Deklarasi will-change: transform pada elemen yang benar-benar dianimasikan dapat menghilangkan patah-patah di frame pertama. Nilai tambah itu berlaku hanya bila dipakai hemat: memberikannya ke ratusan elemen memboroskan memori dan justru memperlambat halaman.
Sebagai penutup, patut diketahui bahwa CSS cukup untuk mayoritas animasi antarmuka. Untuk ilustrasi kompleks dengan ratusan objek, tim biasanya beralih ke format Lottie (render vektor via canvas) atau Web Animations API; keduanya tetap memakai prinsip yang sama — pertahankan pekerjaan di tahap composite. Aturan paling padat dari chapter ini: animasikan transform dan opacity, sisakan color untuk perubahan warna kecil, dan hindari menganimasikan properti geometri.