Temu Duga Frontend: Bagaimana Anda Menggunakan content-visibility Tanpa Menyebabkan Layout Shift?

Soalan dan Senario yang Sesuai

Anda mengendalikan senarai yang panjang, suapan artikel atau ruang kerja pentadbir. DOM mengandungi beratus-ratus bahagian kandungan; hanya beberapa kad yang kelihatan pada awalnya, namun pelayar masih melakukan kerja penggayaan (style), susun atur (layout) dan pengecatan (paint) untuk subpokok di luar skrin. Temu duga ini meminta anda mengurangkan kerja rendering pada benang utama (main thread) dengan CSS containment sambil mengekalkan carian dalam halaman (find-in-page), fokus dan akses pembaca skrin.

Andaikan halaman boleh dibahagikan kepada kad atau bahagian bebas, ketinggiannya berbeza-beza tetapi tidak tanpa had, dan pelayar sasaran menyokong content-visibility: auto. Pelayar yang tidak menyokong mesti tetap merender halaman dengan betul.

Perkara yang Dinilai oleh Penemu Duga

Sama ada anda mengasingkan kekangan (bottleneck) rangkaian, skrip dan rendering sebelum melakukan pengoptimuman.
Sama ada anda boleh menerangkan kekangan susun atur, gaya dan cat yang tersirat daripada auto, serta kekangan saiz di luar skrin.
Sama ada anda menjangkakan ralat saiz placeholder yang menghasilkan lompatan bar tatal dan risiko CLS.
Sama ada anda mengesahkan prestasi bersama-sama dengan fokus, carian dalam halaman, tingkah laku pembaca skrin dan bacaan DOM.

Jawapan yang lemah hanya memberikan satu pengisytiharan CSS. Jawapan yang kukuh menyatakan sempadan, strategi penentuan saiz, kos bacaan susun atur paksa dan pelan sandaran (fallback).

Soalan untuk Dijelaskan Sebelum Menjawab

Adakah kelembapan berlaku semasa render pertama, semasa menatal, selepas penapisan, atau selepas klik? Fasa ini menentukan sama ada anda mengukur kerja rendering, skrip atau rangkaian.
Adakah ketinggian kad stabil? Varians yang lebih besar meningkatkan nilai pengukuran sebenar atau contain-intrinsic-size: auto mengingati saiz yang telah dirender.
Adakah kandungan di luar skrin mesti kekal boleh dicari, boleh difokuskan dan didedahkan kepada teknologi bantuan? Jika ya, hidden bukanlah pengganti terus untuk display: none.
Adakah kod membaca offsetHeight atau getBoundingClientRect() semasa setiap tatalan atau kemas kini keadaan? Bacaan sedemikian boleh menarik semula kerja rendering yang dilangkau ke dalam laluan kritikal.

Kerangka Jawapan 30 Saat

"Mula-mula saya akan menggunakan panel Performance untuk mengesahkan bahawa rendering subpokok di luar skrin ialah puncanya. Saya akan membahagikan suapan kepada bahagian-bahagian bebas, menggunakan content-visibility: auto pada bahagian bukan kritikal, dan menyediakan contain-intrinsic-size yang realistik supaya kekangan saiz tidak menjadikannya kelihatan kosong. Kemudian saya akan menguji fokus, carian dalam halaman dan tingkah laku teknologi bantuan, serta mengaudit bacaan DOM yang memaksa susun atur. Akhir sekali, saya akan membandingkan render pertama, penatalan, INP, CLS dan sandaran sifat yang tidak disokong berbanding kawalan."

Jawapan Terperinci Langkah demi Langkah

1. Wujudkan sempadan rendering

Bahagikan halaman panjang kepada bahagian atau kad yang bebas. Perubahan susun atur di dalam satu sempadan tidak sepatutnya menjejaskan kawasan yang tidak berkaitan; jika tidak, containment boleh menyembunyikan kebergantungan sebenar dan menghasilkan susun atur yang salah.

css

.story {
  content-visibility: auto;
  contain-intrinsic-size: auto 720px;
}

Apabila sesuatu bahagian jauh daripada viewport, auto membolehkan pelayar melangkau sebahagian daripada kerja gaya, susun atur dan cat bagi zuriatnya; apabila ia menghampiri viewport, pelayar merendernya atas permintaan. DOM kekal wujud.

2. Sediakan placeholder saiz

Bahagian di luar skrin diberi saiz sementara tanpa memeriksa kandungannya. Tanpa ketinggian eksplisit atau saiz intrinsik, ia boleh kelihatan seperti kotak kosong yang sangat pendek, mengubah panjang bar tatal dan kedudukan tatal pengguna.

contain-intrinsic-size: auto 720px membekalkan anggaran awal. Selepas rendering, pelayar boleh mengingati saiz sebenar. Dapatkan anggaran daripada sampel pengeluaran dan bukannya memilih nombor hiasan. Untuk varians yang besar, kumpulkan jenis kandungan atau sediakan petunjuk saiz bersama data.

3. Bezakan auto, hidden, dan display none

auto: melangkau rendering di luar skrin dan menyambung semula berhampiran viewport; kandungan kekal dalam DOM dan pepohon kebolehcapaian.
hidden: mengekalkan keadaan rendering sambil sentiasa melangkau rendering; ia sesuai untuk paparan tidak aktif, bukan untuk setiap keperluan menyembunyikan kebolehcapaian.
display: none: membuang keadaan susun atur dan rendering, jadi memaparkannya semula memerlukan pembinaan semula keadaan tersebut.

Jika kandungan sepatutnya tidak dapat dilihat oleh teknologi bantuan, gunakan aria-hidden yang betul secara semantik atau buang daripada DOM, dan pastikan fokus tidak boleh memasuki kawasan yang tersembunyi.

4. Audit bacaan yang menggagalkan pengoptimuman

Bacaan susun atur yang kerap pada bahagian content-visibility boleh memaksa pelayar mengira subpokok yang dilangkau lebih awal. Ukur hanya apabila perlu, kumpulkan (batch) bacaan sebelum penulisan, dan elakkan bacaan dan penulisan berselang-seli yang mencetuskan susun atur segerak.

requestAnimationFrame(() => {
  const height = card.getBoundingClientRect().height;
  card.style.setProperty('--measured-height', `${height}px`);
});

Ini menggambarkan pemasaan (timing), bukan formula sejagat. Gunakan rakaman Performance untuk membuktikan bahawa bacaan menghasilkan tugasan yang panjang (long task) sebelum membuangnya.

5. Sahkan dengan metrik yang dihadapi pengguna

Sekurang-kurangnya, uji:

Render pertama dan jumlah masa rendering, untuk membuktikan kerja di luar skrin telah dikurangkan.
INP atau long task semasa klik, untuk melihat sama ada benang utama mendapat ruang lega.
CLS dan kedudukan tatal, untuk mengesan lompatan saiz placeholder.
Tab papan kekunci, carian dalam halaman dan pembaca skrin, untuk mengesahkan tingkah laku kebolehcapaian auto.
Pelayar yang tidak disokong, untuk memastikan tingkah laku lalai visible masih merender semua kandungan.

Contoh web.dev mengurangkan rendering halaman tertentu daripada 232ms kepada 30ms. Anggap itu sebagai hasil eksperimen, bukan jaminan untuk setiap laman web; kesimpulan anda mesti datang daripada ukuran kawalan dan rawatan anda sendiri.

Contoh Jawapan Berkualiti Tinggi

Saya akan mentakrifkan simptom sebagai kerja rendering yang berlebihan untuk kandungan di luar skrin, kemudian mengesahkan dalam panel Performance bahawa gaya, susun atur atau cat mendominasi benang utama. Selepas pengesahan, saya akan membahagikan halaman kepada bahagian bebas, menetapkan content-visibility: auto, dan menganggarkan contain-intrinsic-size daripada kandungan yang mewakili. Pelayar kemudiannya boleh melangkau rendering zuriat di luar skrin sambil mengekalkan DOM dan akses teknologi bantuan.

Saya tidak akan berhenti pada masa render pertama sahaja. Saya akan menyemak pergerakan bar tatal, fokus dan carian dalam halaman, serta mencari bacaan getBoundingClientRect atau offsetHeight yang memaksa susun atur semasa menatal atau semasa kemas kini keadaan. Saya akan membandingkan render pertama, long task penatalan, INP, CLS dan data pengguna sebenar. Jika ketinggian kad sangat berbeza atau sempadan mempunyai kebergantungan susun atur rentas bahagian, saya akan menyemak semula pembahagian dan strategi penentuan saiz. Pelayar yang tidak disokong menerima tingkah laku lalai visible, jadi pengoptimuman kekal sebagai peningkatan progresif (progressive enhancement).

Kesilapan Lazim

Kesilapan → Menambah content-visibility: auto pada keseluruhan halaman → Sebab ia gagal → sempadan yang tidak jelas menyembunyikan kebergantungan susun atur dan menjadikan atribusi mustahil → Pembaikan → bahagikan bahagian bebas dan rekod garis dasar terlebih dahulu.
Kesilapan → Mengabaikan penentuan saiz intrinsik → Sebab ia gagal → kekangan saiz boleh memandang rendah ketinggian bahagian, memburukkan lagi tatalan dan CLS → Pembaikan → anggarkan daripada sampel dan perhatikan kedudukan tatal sebenar.
Kesilapan → Menggunakan hidden sebagai sinonim untuk aria-hidden → Sebab ia gagal → penyembunyian visual dan semantik kebolehcapaian adalah berbeza → Pembaikan → pilih penyingkiran DOM, aria-hidden, atau kandungan yang dikekalkan mengikut semantik produk.
Kesilapan → Memadam setiap bacaan DOM yang berkaitan dengan prestasi → Sebab ia gagal → sesetengah ukuran diperlukan dan pemadaman membuta tuli merosakkan fungsi → Pembaikan → gunakan rakaman untuk mengenal pasti bacaan yang benar-benar memaksa susun atur.

Soalan Susulan dan Maklum Balas

Adakah anda akan menggunakan satu saiz intrinsik apabila ketinggian kad berbeza sebanyak lima kali ganda?

Tidak. Satu anggaran akan menjadikan sesetengah kad terlalu pendek atau terlalu tinggi secara ketara. Saya akan membahagikan jenis kandungan kepada kumpulan (bucket), mengutamakan saiz yang dirender dan diingati, dan jika perlu, mengembalikan petunjuk saiz daripada pelayan. Saya akan menggunakan CLS dan ralat tatal untuk menentukan sama ada kerumitan pengelompokan tambahan itu berbaloi.

Adakah content-visibility mencukupi jika produk memerlukan penyahkodan video di luar skrin dihentikan sepenuhnya?

Tidak. Ia terutamanya mengawal kerja rendering dan tidak menggantikan pengurusan kitaran hayat media. Saya akan menjeda dan menyambung semula video apabila keterlihatan berubah, memastikan logik itu tidak berulang kali membaca susun atur subpokok yang dilangkau, dan mengukur dasar media secara berasingan daripada pengoptimuman CSS.

Bagaimana anda melancarkannya ke pelayar yang tidak menyokong sifat ini?

Saya tidak akan menjadikan fungsi bergantung padanya. Nilai lalai ialah visible, jadi halaman kekal lengkap; peningkatan progresif dan pemantauan keserasian boleh menunjukkan sama ada pelayar lama memerlukan penomboran halaman (pagination) atau senarai maya sebagai ganti.

Bagaimana anda membuktikan perolehan prestasi datang daripada sifat ini dan bukannya DOM yang lebih kecil?

Kekalkan data dan struktur DOM yang sama dan tukar hanya sifat CSS dalam kawalan setempat atau A/B. Rekod masa rendering, long task, INP dan CLS. Jika penomboran halaman, pemuatan malas imej (lazy loading) atau penjadualan skrip turut berubah, hasilnya tidak boleh diatribusikan kepada satu sifat sahaja.