Animasi yang tersendat jarang berarti perlu dirombak total — sering kali cukup satu properti yang ditukar, satu elemen yang diberi tanda akan dianimasikan, atau satu bagian halaman yang diisolasi. Teori memilih properti murah (transform dan opacity) versus properti mahal (geometri) telah kita bahas pada Chapter Animation Performance di Section transisi; Chapter ini melanjutkan dari titik itu ke sisi operasionalnya: bagaimana menemukan animasi yang bermasalah lewat pengukuran, lalu mengekang pekerjaan layout dan paint dengan contain, content-visibility, dan will-change.

Mengukur Sebelum Mengubah #

Perbaikan tanpa pengukuran adalah tebakan. DevTools menyediakan dua alat cepat sebelum kita membuka panel Performance penuh:

  1. Buka tab Rendering (menu More tools), lalu aktifkan Paint flashing: area yang digambar ulang berkelip hijau. Animasi yang sehat menandai elemennya sendiri; bila hampir seluruh halaman berkelip, animasi tersebut menarik terlalu banyak area.
  2. Aktifkan Frame Rendering Stats untuk melihat FPS berjalan di sudut layar. Angka yang turun jauh di bawah 60 pada animasi tertentu menandai frame yang kehilangan tenggat.
  3. Bila masalah perlu dianalisis lebih dalam, rekam beberapa detik di panel Performance dan baca baris Frames: bar yang pendek dan kuning adalah frame yang melewati tenggat 16,7 ms.

Setelah terukur, arahkan perbaikan ke penyebabnya — dan di sinilah tiga properti berikut berperan.

contain dan content-visibility: Mengekang Pekerjaan Browser #

Properti contain memberi jaminan bahwa efek sebuah elemen terbatas di dalam batasnya. Nilai contain: layout paint menyatakan dua hal: perubahan di dalam elemen tidak mengubah layout di luarnya, dan lukisan tidak keluar dari batasnya. Browser memakai jaminan itu untuk mempersempit cakupan perhitungan ulang — panel yang diisolasi seperti ini adalah kandidat kuat untuk kartu, widget, dan daftar berulang.

Untuk daftar panjang, content-visibility : auto melangkah lebih jauh: bagian yang berada di luar viewport dilewati dari pekerjaan layout, paint, dan pencarian gaya sepenuhnya. Fitur ini merupakan Baseline sejak 2024 dan dapat dipakai di seluruh browser utama. Karena elemen yang dilewati ukurannya nol, pasangkan dengan contain-intrinsic-size agar bilah gulir tetap stabil:

css
.panel {
  contain: layout paint;
}
.daftar-item {
  content-visibility: auto;
  contain-intrinsic-size: 96px;
}
  1. contain: layout paint pada .panel: perubahan di dalam panel — animasi, pembaruan teks — tidak memicu layout ulang pada elemen di luarnya.
  2. content-visibility: auto pada .daftar-item: browser merender item hanya ketika item mendekati viewport.
  3. contain-intrinsic-size: 96px: ukuran cadangan saat item dilewati, sehingga tinggi halaman tidak melompat-lompat saat digulir.

Hasil di Browser:

text
Panel terisolasi membawa computed contain: layout paint dengan padding
16px. Keempat baris membawa computed content-visibility: auto dengan
ukuran cadangan 96px per baris. Kotak animasi membawa computed
will-change: transform dan transform statis matrix(1, 0, 0, 1, 0, 0)
pada lebar 220px.

will-change: Hemat dan Berbatas #

will-change memberi tahu browser properti apa yang akan berubah pada elemen tersebut, sehingga browser dapat menyiapkan lapisan tersendiri lebih awal. Deklarasi will-change: transform pada elemen yang memang beranimasi menghilangkan jeda di frame pertama; di sisi lain, setiap lapisan memakai memori, sehingga memberikannya ke ratusan elemen justru memperlambat halaman. Properti ini juga membentuk stacking context baru — efek samping yang patut diingat saat mengandalkan urutan tumpukan.

Aturan hematnya: pasang will-change hanya pada elemen yang sedang beranimasi, hapus ketika animasinya berhenti, dan jangan pernah menumpuknya sebagai “jimat keberuntungan” pada semua elemen. Bila animasi berulang terus-menerus, penulisan statis di CSS cukup; untuk animasi yang menyala sesekali, tambahkan class melalui JavaScript tepat sebelum animasi dan lepas setelahnya.

Setelah animasi terekang — properti murah, elemen terisolasi, lapisan terkendali — pekerjaan layout yang tersisa biasanya berasal dari pola JavaScript yang membaca dan menulis bergantian. Pola itu, beserta cara memperbaikinya, menjadi topik Chapter berikutnya.