Perintah dan konteks
Sebuah halaman konten memasukkan ratusan kartu ke dalam DOM sekaligus, menyebabkan long task selama tata letak awal dan scrolling. Pewawancara meminta Anda mengevaluasi content-visibility: auto, menjelaskan pekerjaan apa yang dilewati, memperkirakan ukuran di luar layar (off-screen), dan memutuskan kapan paginasi atau virtualisasi tetap diperlukan. Sertakan pengukuran, aksesibilitas, dan kriteria rollback.
Apa yang sedang diuji oleh pewawancara
Mereka ingin melihat apakah Anda memahami hubungan antara alur kerja rendering (rendering pipeline) dan containment CSS, dapat membedakan antara melewati rendering di luar layar dengan mengurangi ukuran DOM, serta dapat menangani perkiraan tinggi, navigasi fokus, dan kompatibilitas. Satu baris CSS atau pengali yang belum diverifikasi tidak membuktikan adanya optimasi.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
- Berapa banyak kartu yang ada, seberapa kompleks masing-masing kartu, dan apa target layar pertama?
- Di mana letak bottleneck-nya: skrip, kalkulasi gaya, tata letak, paint, memori, atau jaringan?
- Apakah tinggi kartu stabil, atau apakah gambar dan font mengubahnya setelah dimuat?
- Apakah halaman bergantung pada fitur pencarian di halaman (find-in-page), fokus keyboard, pembaca layar, atau pencetakan?
- Cakupan dukungan browser dan kriteria penerimaan aksesibilitas apa yang berlaku?
Kerangka jawaban 30 detik
Pertama, saya akan mengonfirmasi long task dan biaya tata letak di panel Performance, kemudian mencoba content-visibility: auto pada kartu-kartu di luar layar yang telah dibagi menjadi beberapa bagian. Ini memungkinkan browser melewati tata letak dan paint untuk subtree yang sementara tidak relevan, sementara konten tetap berada di DOM dan accessibility tree. Size containment dapat membuat konten yang belum dirender berperilaku seperti kotak kosong, jadi saya akan memadukannya dengan contain-intrinsic-size yang terukur dan melacak pergeseran tata letak (layout shift). Jika ukuran DOM atau volume data tetap menjadi bottleneck, saya akan menggunakan paginasi atau virtualisasi.
Pembahasan mendalam langkah demi langkah
Langkah 1: Konfirmasi target optimasi
Catat first paint, latensi interaksi, long task, jumlah tata letak, waktu paint, dan memori. Pertahankan baseline dengan data, perangkat, viewport, dan kondisi cache yang sama agar variasi jaringan tidak disalahartikan sebagai peningkatan dari CSS.
Langkah 2: Bagi konten menjadi unit yang dapat dilewati
Bungkus kartu-kartu berulang dalam section atau article yang stabil sehingga browser dapat mengevaluasi subtree di dekat viewport. Batasan harus sesuai dengan unit konten nyata; hindari menyembunyikan satu kontainer besar yang sering berubah.
Langkah 3: Pahami perilaku auto
content-visibility: auto mengaktifkan containment untuk layout, style, dan paint. Ketika elemen di luar layar tidak relevan bagi pengguna, browser dapat melewati rendering subtree-nya dan melanjutkannya di dekat viewport. Ini bukan display: none: konten tetap berada di DOM dan accessibility tree serta tetap dapat dicari dan difokuskan.
Langkah 4: Berikan placeholder intrinsik yang terukur
Size containment memungkinkan browser menghindari rendering elemen turunan hanya untuk menghitung ukuran luar. Tanpa placeholder, sebuah elemen dapat ditata mendekati tinggi nol dan menyebabkan scrollbar melompat. Gunakan contain-intrinsic-size untuk perkiraan, atau auto agar browser dapat mengingat ukuran yang dirender sebelumnya.
.card-section {
content-visibility: auto;
contain-intrinsic-size: auto 420px;
}Langkah 5: Audit kode yang memaksa rendering
Beberapa pembacaan DOM untuk tata letak atau dimensi memaksa browser memproses subtree yang dilewati. Tinjau pengukuran, tangkapan layar sinkron, animasi, dan widget pihak ketiga. Hindari siklus baca/tulis berulang pada scroll handler; gabungkan pengukuran secara batch atau gunakan observer jika memungkinkan.
Langkah 6: Verifikasi aksesibilitas dan interaksi
Uji navigasi keyboard, find-in-page, pembaca layar, dan lompatan tautan anchor pada konten di luar layar. auto dan hidden memiliki semantik aksesibilitas yang berbeda, jadi jangan mengganti satu dengan yang lain hanya demi performa. Untuk konten yang benar-benar harus disembunyikan, gunakan strategi penyembunyian semantik yang eksplisit dan uji ulang urutan fokus.
Langkah 7: Bandingkan batasan dengan virtualisasi
content-visibility mempertahankan DOM penuh, sehingga cocok untuk halaman di mana ukuran konten sedang tetapi rendering di luar layar membutuhkan biaya komputasi tinggi. Jika jumlah node, listener, atau memori data itu sendiri terlalu besar, gunakan virtualisasi, paginasi, atau pemecahan di sisi server (server-side chunking); pendekatan ini dapat digabungkan berdasarkan wilayah halaman.
Contoh jawaban yang kuat
Saya akan mengonfirmasi bottleneck dalam trace performa, kemudian membagi kartu menjadi beberapa bagian dan menguji content-visibility: auto. Ini melewati tata letak dan paint untuk subtree di luar layar tetapi tidak mengurangi ukuran DOM; contain-intrinsic-size mencegah kartu yang belum dirender terlihat seperti kotak dengan tinggi nol. Saya akan mengaudit pembacaan tata letak, menguji perilaku keyboard, find-in-page, dan pembaca layar, serta membandingkan first paint, latensi interaksi, layout shift, dan memori. Jika ukuran DOM masih menjadi biaya utama, saya akan beralih ke paginasi atau virtualisasi.
Kesalahan umum
Kesalahan: memperlakukan auto sebagai daftar virtual
auto terutama melewati pekerjaan rendering di luar layar sementara node tetap ada. Ini tidak secara otomatis menghilangkan biaya listener, memori data, atau DOM yang terlalu besar.
Kesalahan: mengabaikan estimasi ukuran intrinsik
Size containment dapat menata kotak luar menggunakan placeholder. Nilai yang terlalu kecil mengubah scrollbar dan posisi scroll, jadi perkirakan dari distribusi kartu yang sebenarnya dan kalibrasi ulang.
Kesalahan: hanya mengukur first paint
Konten masih harus dirender saat memasuki viewport. Ukur latensi interaksi scroll, long task, layout shift, memori, dan aksesibilitas selain pemuatan awal.
Kesalahan: mencampuradukkan hidden dan auto
hidden melewati konten dan memengaruhi find-in-page, fokus, serta seleksi; auto menjaga konten di luar layar tetap tersedia untuk fitur-fitur user agent. Pilih berdasarkan kontrak semantik dan interaksi.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan: Apakah ini mengurangi permintaan jaringan?
Tidak. Properti ini memengaruhi rendering dan containment; data dan sumber daya mungkin sudah diunduh. Gunakan paginasi, pemuatan lambat (lazy loading), atau pemecahan sisi server untuk mengurangi biaya jaringan dan memori.
Pertanyaan lanjutan: Mengapa halaman melompat saat scrolling?
Elemen tersebut ditata menggunakan placeholder di bawah size containment, kemudian tingginya berubah setelah dirender. Perbaiki estimasinya, gunakan contain-intrinsic-size: auto, dan verifikasi dengan metrik layout-shift.
Pertanyaan lanjutan: Apakah konten masih ada di accessibility tree?
Dengan auto, konten di luar layar tetap berada di DOM dan accessibility tree serta umumnya dapat dicari dan difokuskan; hidden berbeda. Uji ulang dengan browser dan teknologi asistif target.
Pertanyaan lanjutan: Kapan Anda harus menghindarinya?
Hindari mengandalkannya jika tinggi elemen tidak dapat diprediksi dan estimasi merusak scrolling, komponen sering memaksa tata letak, atau ukuran DOM sudah menjadi bottleneck. Gunakan virtualisasi, paginasi, atau pemuatan bertahap (chunked loading) sebagai gantinya.
Pertanyaan lanjutan: Bagaimana Anda membuktikan tidak ada regresi?
Jalankan pengujian sebelum dan sesudah pada perangkat dan data tetap, catat first paint, latensi interaksi p95, long task, layout shift, frame rate scrolling, memori, dan hasil aksesibilitas, lalu pantau metrik persentil pada trafik nyata.