【フロントエンドの処方箋】`contain`プロパティを制する者はブラウザのレンダリングを制す
おい、調子はどうだい？
最近、社内のレビューをしていて「なんかこのコンポーネント、インタラクションのたびにモッサリするな……」という画面によく遭遇するんだよね。原因をプロファイラで追っていくと、だいたい犯人は決まっていて、「たったひとつのDOMの変更が、なぜかドキュメント全体のレイアウト再計算（リフロー）を引き起こしている」という悪夢のような構造だ。
君も経験ないかい？「モーダルを1つ開いただけなのに、なんでヘッダーからフッターまで全コンポーネントがスタイル再計算の巻き添えをくらってるんだよ！」って頭を抱えた夜がさ。
今日はね、その泥沼から君を救い出すための最強の切り札、CSS Containment（containプロパティ）について話をしよう。これを正しく使いこなせるようになると、ブラウザのレンダリングエンジンと「お友達」になれる。実務のパフォーマンスチューニングで一目置かれる存在になること間違いなしだ。さあ、深掘りしていこうか。
—
1. ブラウザの裏側で何が起きているのか？（レイアウト・ペイントの恐怖）
まず、俺たちが普段何気なく書いているCSSが、ブラウザの内部でどう処理されているかを軽くおさらいしておこう。ここを理解していないと、`contain`の本当のヤバさ（凄さ）が伝わらないからね。
ブラウザ（BlinkやWebKitなど）は、HTMLを受け取ってDOMツリーを作り、CSSを解析してCSSOMツリーを構築し、それらを合わせて「レンダーツリー」を作る。ここまでは基本だ。
問題はそのあと、実際に画面にピクセルを描画するプロセスだ。
1. レイアウト（Layout / リフロー）: 各要素が画面上のどこに、どれくらいのサイズで配置されるかを計算する。
2. ペイント（Paint）: 要素の背景、色、ボーダー、シャドウなどのビジュアルを描画する。
3. コンポジット（Composite）: レイヤーを合成して画面に出力する。
ここで最もCPUをぶん回すのが、1の「レイアウト（リフロー）」だ。厄介なことに、標準のWebの仕様では、「DOMツリーのどこか一部が変化すると、ブラウザはそれが他にどんな影響を及ぼすか分からないため、原則としてドキュメントのルート（根元）から全要素のレイアウトを再計算しようとする」性質がある。
考えてもみてくれ。たった一個のサイドバーの開閉アニメーションのために、数千個あるメインコンテンツ側のノードまでレイアウト計算の網にかかる。これが「重さ」の正体だ。
—
2. `contain`プロパティとは何か？（ブラウザへの「隔離命令」）
そこで登場するのが、CSS Containmentモジュールで定義された `contain` プロパティだ。
こいつは一言で言うと、「この要素の中身と外側は完全に独立しているから、お互いに影響し合わないとみなしていいよ」という、ブラウザへの強力な隔離命令（Isolation）なんだ。
ブラウザはこの指示を受け取ると、「お、この要素の中がどれだけ変わろうと、外側のレイアウトには影響しないんだな。じゃあ外側の再計算はサボって（スキップして）、この要素の中だけで計算を完結させよう」と判断する。これが、レンダリングコストを劇的に劇減させるカラクリさ。
`contain`が持つ4つの主要な独立性（キーワード）
`contain`にはいくつか指定できる値があるけれど、まずは基本のキーワードを押さえておこう。
- `layout`: 要素の内部レイアウトが、外部のレイアウトに一切影響を与えない（およびその逆）。
- `paint`: 要素の内部が、その境界の外側にはみ出して描画されない（クリッピングされる）。もし画面外に出たら、ペイント処理自体がスキップされる。
- `size`: 要素のサイズを計算する際、内部の子要素のサイズを考慮する必要がない（あらかじめサイズが確定している場合に効く）。
- `style`: プロパティの影響範囲をその要素内に閉じ込める（カウンタやクエリなど）。
そして、実務で一番よく使う（そして最も効果が高い）のが、これらを組み合わせたショートハンドだ。
- `contain: layout style;`
- `contain: content;` （`size`以外のすべてを内包）
- `contain: strict;` （`size`を含むすべてを内包。サイズが固定のウィジェット等に最強）
—
3. 実務でどう使う？ コピペで試せる実践コード
理屈はこれくらいにして、実際に手を動かしてみよう。
例えば、無限スクロールするチャットログや、大量のカードが並ぶダッシュボードの「1つの独立したカード（ウィジェット）」を想像してほしい。
このカードの中で何が起きようとも、親コンテナや他のカードのレイアウトを絶対に巻き込みたくない。そんなときの鉄板コードがこれだ。
このコードの何がエライのか？
もし `.widget-body` の中に JavaScript で大量の要素を動的に追加・削除したり、スタイルを書き換えたりしたとする。
通常なら、ブラウザはページ全体のレイアウトツリーを再スキャンしようとするけれど、`contain: layout style paint;` が指定されているおかげで、ブラウザは「あ、この `.widget-card` の中だけで完結してるな。じゃあ外のDOMは一切触らんとこ」と判断し、ピンポイントでそのカードの中だけで処理を完結させるんだ。
リストの項目が何千個もあるようなUIや、ダッシュボード、複雑なSPAのモーダルやドロップダウンメニューなどでは、これだけでフレームドロップ（カクつき）を綺麗に消し去ることができる。
—
4. 現場のシニアが教える「ハマりどころ」と注意点
さて、ここまで読んだ熱心な君なら、「じゃあ、画面中のすべての要素に `contain: strict` を貼り付けまくれば最強じゃん！」と思うかもしれない。
……残念、そうは問屋が卸さないのがフロントエンドの奥深いところだ。
強力な薬には必ず副作用がある。Containmentを導入する際に、現場で絶対にハマるポイントをいくつか共有しておこう。
1. `position: absolute` や `fixed` の子孫に注意
`contain: layout` や `contain: paint` を指定した要素は、「Containing Block（包含ブロック）」の基準点になる。つまり、子孫要素に `position: absolute; top: 0;` を持った要素があった場合、画面の端ではなく、この `contain` を指定した親要素を基準にして配置されてしまう。意図しないレイアウト崩れの原因になるので、「絶対配置の基準にしたいのかどうか」を意識して使おう。
2. `overflow: visible` との相性
`contain: paint` は強制的に内部の描画をクリッピング（切り取り）する。そのため、ドロップダウンのメニューやツールチップなど、「親からはみ出して表示させたいUI」の親要素にこれを指定すると、見事にプッツリとメニューが途中で切れる。はみ出しが必要な要素には `contain: paint` は絶対に使わないこと。
3. `contain: size` の厳格さ
サイズを完全に外部から独立させるため、内部の子要素の高さに合わせて親が勝手に伸び縮みしなくなる。コンテンツ量が可変の要素に安易に使うと、中身が潰れて見えなくなったりするので、`contain-intrinsic-size`（プレースホルダーサイズ）とセットで使うか、サイズが完全固定のウィジェットだけに絞るのがプロの作法だ。
—
5. まとめ：ブラウザと「対話」するコーディングへ
CSSの `contain` プロパティは、単なる「便利な便利機能」じゃない。
これは、フロントエンドエンジニアである私たちが、ブラウザのレンダリングエンジンに対して「ここは俺が責任を持って隔離するから、無駄な計算は省いてくれよ」と指示を出すための、高度なコミュニケーションツールなんだ。
仕様の背景を理解し、DOMのツリー構造のどこがボトルネックになっているかをプロファイラで突き止め、適切な粒度で `contain` を仕込む。この一手間ができるかどうかが、動くだけのコードを書くジュニアと、スケーラブルで爆速なWebアプリを設計できるシニアの分かれ道だ。
次の機能開発やリファクタリングのとき、モッサリしがちなリストやウィジェットを見つけたら、ぜひ思い出してこの魔法のプロパティを差し込んでみてほしい。ブラウザが軽やかに、スッと応えてくれるはずさ。
それじゃあ、また次の現場でお会いしよう。ハッピー・コーディング！
コメント