content-visibilityとCSS Containmentのレンダリング省略

封じ込めが解く問題：無効化はなぜ広がるのか

ブラウザのレンダリングはスタイル→レイアウト→ペイント→コンポジットと流れ、上流が変わると下流が連鎖して無効化されます（詳細は レンダリングパイプライン詳説）。問題は、この無効化が部分木の外へ波及することです。ある要素の高さが変わると、その兄弟の位置がずれ、祖先の寸法も変わりうるため、ブラウザは「どこまで再計算が必要か」を保守的に広く見積もります。ページが大きいほど、小さな変更1つの再レイアウトが重くなります。

CSS Containment は、この波及経路を開発者が明示的に遮断する仕組みです。contain を当てた要素は、レンダリングに関して「独立した部分（independent subtree）」だとブラウザに宣言され、内部の変更が外に出ない・外の変更が中に入らないことが保証されます。保証があるからこそ、ブラウザは再計算の範囲をその部分木に安全に閉じ込められます。

layout封じ込め：レイアウトの境界を引く

contain: layout は、要素の内部レイアウトを外部から完全に切り離す契約です。具体的には3つの保証が成り立ちます。第1に、子孫のジオメトリ変化は要素の外のレイアウトに影響しません。第2に、要素自身が新しい**包含ブロック（containing block）**となり、内部の position: absolute/fixed の基準が外へ漏れません。第3に、要素は独立した整形コンテキスト（BFC相当）を確立し、マージンの相殺や浮動の回り込みが境界を越えません（包含ブロックと整形文脈の基礎は CSSレイアウトアルゴリズム）。

この結果、頻繁に更新される領域に contain: layout を当てると、その中で要素を追加・削除・リサイズしても、再レイアウトはその部分木だけで完結します。リスト項目の動的更新やチャットのメッセージ追加のように「独立して変わる領域」が典型的な適用先です。

/* 各カードは独立した範囲。中身が変わっても祖先の再レイアウトを起こさない */
.card { contain: layout; }

paint封じ込めとsize封じ込め

contain: paint は、子孫の描画を要素の境界でクリップする保証です。子が境界からはみ出して描かれないとブラウザが確信できるため、要素が画面外にあるときペイントを丸ごとスキップできます。overflow: hidden と似て見えますが、paint封じ込めはクリップに加えて「この要素が独立した合成・ペイントの単位である」という意味を持ち、スタッキングコンテキストも新規に作ります。

contain: size は最も強く、注意を要します。これは「子孫を一切見ずに自分の寸法を決める」という契約で、内在サイズ（min-content / max-content）の計算で子を参照しなくなります。結果として、明示的な高さを与えなければ要素の内在サイズは0として扱われ、潰れます。size封じ込めは「寸法が中身に依存しない」と保証できる場合にのみ有効で、単独で使うことはまれです。価値が出るのは、後述の content-visibility のように**寸法のプレースホルダ（contain-intrinsic-size）**と組み合わせ、子のレイアウトを省きつつ場所だけ確保するときです。

content-visibility:auto の動作原理

content-visibility: auto は、Containment をビューポートとの位置関係で自動的に切り替えるショートカットです。要素が画面外（と近傍のレンダリング余白の外）にある間、ブラウザはその要素に contain: layout paint style size 相当を適用し、子孫のレイアウト・ペイント・ラスタライズをすべてスキップします。子のスタイル計算やレイアウトツリー構築の大半が遅延されるため、要素数の多いページの初期表示コストが、実際に見える領域の分だけに縮みます。

要素がスクロールでビューポートに近づくと、ブラウザは自動的に封じ込めを解除して通常どおりレンダリングし、離れると再びスキップ状態へ戻します。JSのIntersection Observerで同等の遅延描画を手作りする必要が、CSS1行で消えるわけです。

.section {
  content-visibility: auto;
  /* スキップ中の各セクションの推定寸法（幅 高さ）。スクロールバーの暴れを防ぐ */
  contain-intrinsic-size: auto 600px;
}

ここで content-visibility: auto は size封じ込めを含むため、スキップ中の要素は本来0高さに潰れます。それを防ぐのが contain-intrinsic-size で、レンダリングを省いた要素に与えるプレースホルダ寸法です。auto 600px の auto キーワードは「一度実レンダリングしたら、そのときの実寸を記憶して次回以降のプレースホルダに使う」挙動を意味し、推定値のズレを自己補正します。

落とし穴：アクセシビリティと検索性

content-visibility: auto でスキップ中の子孫は、レイアウトが省かれているだけでDOMには存在し、アクセシビリティツリーにも残ります。スクリーンリーダーやCtrl+Fのページ内検索はスキップ要素の中身にも到達でき、display: none のように完全に消えるわけではありません。これは利点ですが、注意点もあります。スキップ中の要素は寸法が contain-intrinsic-size の推定値なので、ページ内リンク（アンカー）への即時ジャンプやスクロール位置の計算が推定寸法に基づくため、実寸とズレるとジャンプ後に位置補正が走ることがあります。

また、size封じ込めにより画面外要素の正確なレイアウトが存在しないため、getBoundingClientRect() 等で画面外セクションの寸法を読むと、実値ではなく推定寸法ベースの結果になりえます。レイアウトに依存した測定を行うコードとは相性に注意が必要です。

計測と適用判断

封じ込めの効果は「スキップされたレンダリング作業の量」で測ります。長いページで content-visibility: auto を当て、DevTools の Performance パネルで初期ロード時の Layout / Paint / Rendering 時間が減れば成功です。逆に、ほぼ全要素が常に画面内に入る短いページでは、スキップする対象がないため効果は薄く、むしろ封じ込めの管理コストがわずかに乗ります。

まとめ