ブラウザレンダリングを「局所化」せよ：CSS Containmentで実現するパフォーマンスの極致
やあ。現場でCSSを書いていて、「なぜか特定の要素を動かすだけで、ページ全体がガタつく」という経験はないかな？
ブラウザのレンダリングエンジン（BlinkやWebKitなど）は、基本的に「ページ全体がひとつの巨大なキャンバス」だと考えている。DOMの一部が少しでも変化すれば、ブラウザは「影響範囲はどこまでだ？」と必死に計算（Layout/Reflow）を始める。これがパフォーマンスのボトルネックの正体だ。
今日は、そんなブラウザの「過剰な正義感」を制御し、レンダリングの範囲をピンポイントに絞り込むための魔法、『CSS Containment』について話をしよう。
—
なぜブラウザは「余計なこと」をするのか
DOMのどこかで要素が動いたり、スタイルが変わったりすると、ブラウザは再計算（Recalculate Style, Layout, Paint）を走らせる。デフォルトの状態では、ブラウザはその影響範囲を特定するために、DOMツリーの最上部からツリー全体をスキャンしようとするんだ。
もし君が、複雑なダッシュボードの端っこにある小さなウィジェットをアニメーションさせているなら、ブラウザは無駄にページ全体のレイアウトを再検証していることになる。これは非常に非効率だよね。
そこで登場するのが `contain` プロパティだ。こいつを使うと、「このDOMの内部は独立しているから、外側に影響しないし、外側からも影響を受けないよ」とブラウザに明示的な境界線を引くことができる。
—
containプロパティの4つの切り札
`contain` は、具体的にどのフェーズを遮断するかを細かく指定できる。現場でよく使うのは以下の4つだ。
1. `layout`: この要素の内部レイアウトは、外側のレイアウトに一切影響を与えないと宣言する。
2. `paint`: この要素の内容が境界の外にはみ出さないことを保証する。はみ出る場合はクリッピングされる。
3. `size`: この要素のサイズが、その中身のコンテンツに依存しないことをブラウザに教える。
4. `style`: CSSのカウンターやクォートなどが、この要素の外部に漏れないようにする。
一番強力なのは `contain: strict;` だが、これはすべての値を適用するため、要素のサイズをしっかり指定していないとコンテンツが消えてしまうリスクがある。現場では `contain: layout paint;` のように、必要な分だけ組み合わせるのが定石だ。
—
実践：パフォーマンスを劇的に改善する実装例
例えば、「動的にリストが追加されるサイドバー」や「スクロールする複雑なウィジェット」を想定してみよう。これらに適用するだけで、ガタつきを劇的に抑えられるはずだ。
/ ウィジェットのコンテナに適用 /
.widget-container {
/ レイアウト計算をこの要素内で完結させる /
/ Paintの範囲もこの要素内に制限し、はみ出しをカット /
contain: layout paint;
/ 注意: sizeを併用する場合は、必ず明確な幅と高さを指定すること /
/ そうしないと、要素が潰れて中身が見えなくなる /
width: 300px;
height: 400px;
overflow: auto; / コンテナ内でのスクロール /
background: #fff;
border: 1px solid #ccc;
}
/ 内部の動的に変化する要素 /
.dynamic-list-item {
/ ここが変化しても、.widget-containerの外側には影響が及ばない /
padding: 10px;
border-bottom: 1px solid #eee;
}
どう使い分けるか？
- 複雑なコンポーネントのルート: `contain: layout paint;` で十分。ほとんどの再計算コストをカットできる。
- サイズが予測可能なカードデザイン: `contain: strict;` も検討の余地あり。ブラウザは「中身がどうあれこのサイズ」と断定できるため、最も強力に最適化が効く。
- 注意点: `contain: size` を使う際は、CSS側で `width` や `height` を明示しないと、ブラウザは「高さ0」と見なして中身を隠してしまう。これは初心者が必ず一度はハマる罠だ。
—
現場のシニアとしてのアドバイス
「とりあえず何でも `contain` をつければ速くなる」というのは間違いだ。過剰な隔離は、CSSの設計を複雑にするし、意図しないレイアウト崩れを引き起こすこともある。
私が推奨するのは、「明らかに独立して動く部品（ウィジェット、モーダル、ドロップダウンメニュー、複雑なリスト）」に対して、プロファイリングツール（Chrome DevToolsのPerformanceタブ）を見ながらピンポイントで適用することだ。
ブラウザのレンダリングエンジンは優秀だが、人間が「ここは独立している」とヒントを与えてやるだけで、計算コストは劇的に下がる。コードの可読性とパフォーマンスのトレードオフを意識しながら、この武器を使いこなしてほしい。
さあ、次のコミットで、その「重たいUI」をスムーズに動かしてみようじゃないか。何か詰まったらまたいつでも聞きに来てくれ。
コメント