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:

  1. Style: browser menghitung gaya akhir (computed style) untuk setiap elemen — pekerjaan cascade yang kita bahas sejak awal Course ini.
  2. Layout: browser menghitung geometri — posisi dan ukuran setiap kotak. Perubahan width, height, margin, atau top memicu tahap ini diulang.
  3. Paint: browser mengisi piksel pada setiap bagian yang berubah — teks, warna, bayangan, dan border digambar ulang.
  4. 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:

PropertiTahap yang diulangContoh pemakaian
transform, opacityComposite sajaGeser, putar, skala, memudar
color, background-color, box-shadowPaint + compositePerubahan warna dan bayangan
width, height, padding, margin, top, leftLayout + paint + compositeUbah ukuran, geser posisi

Demo chapter ini menampilkan dua kartu beranimasi plus satu kotak statis:

css murah-vs-mahal.html (cuplikan)
/* 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:

  1. Baris 3–4 (opacity: 0.9, will-change: transform): kartu setengah tembus pandang dan diberi tanda akan dianimasikan lewat transform — browser menyiapkan lapisan terpisah untuknya sejak awal.
  2. Baris 5–9 (keyframes angkat): perjalanan translateY dari 0 ke -12 piksel. Nilai yang dianimasikan adalah transform, sehingga layout tidak pernah dihitung ulang.
  3. Baris 12–17 (keyframes geser-kiri): perjalanan left dari 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:

text
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.