ブラウザの「再計算」という重い十字架を背負うな：`contain`プロパティによるレンダリング最適化の極意
やあ。今日もフロントエンドの泥沼で奮闘しているか？
大規模なSPAを開発していて、「特定のコンポーネントを更新しただけなのに、なぜかページ全体のレンダリングがガクつく」という現象に頭を抱えた経験はないだろうか。ブラウザのレンダリングエンジンは、君たちが書いたコードが少し変わるたびに、せっせとツリーを駆け下り、計算し直す。この「親切すぎるお節介」こそが、パフォーマンスを殺す最大の要因だ。
今日は、そんなブラウザの「律儀すぎる再計算」を物理的に遮断する魔法の杖、`contain`プロパティについて話そうと思う。
—
ブラウザが裏側でやっている「地獄の再計算」
ブラウザはHTMLをパースしてDOMツリーを作り、CSSOMと合体させてレンダリングツリーを構築する。ここまではいい。問題は、DOMの一部が書き換わったその瞬間だ。
ブラウザは原則として、「DOMのどこか一部分が変化すれば、それがページ全体のレイアウトに影響を及ぼすかもしれない」という前提で動いている。だから、たった一つのボタンのサイズが変わっただけで、ページの最下部にあるフッターまで再計算の波及範囲に含まれてしまう。これが「レイアウト・スラッシング」を誘発し、FPSをドブに捨てる原因だ。
ここで登場するのが `contain` だ。これを要素に指定することで、「この要素の中身は、外の世界とは独立しているよ。だから、中身が変わっても外側には一切影響しないよ」という契約をブラウザと結ぶことができる。
`contain` の4つの値を使いこなせ
`contain` プロパティにはいくつかの値があるが、現場で意識すべきは主にこの4つだ。
- `size`: 要素のサイズが子要素に依存しないことをブラウザに伝える。つまり、中身が増えても要素の幅や高さが変わらないと明言する。
- `layout`: 要素内でのレイアウト変更が、外部の要素に影響を与えないことを保証する。これによって、ブラウザは「この要素の外側にある要素の再計算はスキップしていいんだな」と判断できる。
- `paint`: 要素内の描画が、要素の外側にはみ出さないことを保証する。はみ出す可能性があるなら、ブラウザは余計な描画領域を計算しなくて済む。
- `content`: `size` 以外の `layout`, `paint` を含めた便利セット。迷ったらまずはこれだ。
実践：チャットUIで威力を発揮する `contain`
例えば、チャットルームのような「メッセージが次々と追加される」UIを想像してほしい。メッセージリスト全体に `contain: layout` を適用すれば、新しいメッセージが追加されたとき、ブラウザは「この中の再配置だけで完結するから、ヘッダーやサイドバーの再計算は不要だな」と判断してくれる。
/ チャットのリストエリアに適用する最適化 /
.chat-message-list {
/
contain: content を指定することで、
レイアウトと描画のスコープをこの要素内に閉じ込める。
結果として、リスト内の更新による「ページ全体のリフロー」を防止できる。
/
contain: content;
/
注意：contain は強力な境界を作るため、
中身がはみ出すような絶対配置やoverflowの制御には気を配る必要がある。
これは「責任ある設計」の代償だ。
/
overflow-y: auto;
height: 500px;
}
現場で使う際の「禁忌」と注意点
`contain` は魔法だが、万能薬ではない。以下のポイントだけは必ず覚えておいてくれ。
1. `size` の罠: `contain: size` を指定すると、中身が空っぽの要素は「高さ0」として扱われる。明示的に高さを指定しないと、中身が消えたように見えるバグを誘発する。
2. 絶対配置の断絶: `contain` を指定した要素を包含ブロック（Containing Block）として扱うことになるため、要素の外部に `position: absolute` で配置していた要素が、意図せずその中に閉じ込められて表示が崩れることがある。
3. 過剰な最適化: 全ての要素に `contain` を入れるのは逆効果だ。ブラウザの柔軟なレイアウト機能を制限することになる。あくまで「頻繁に更新される独立性の高いコンポーネント」に絞って使うのが、シニアの流儀だ。
最後に：ブラウザと対話する感覚を持て
フロントエンドの最適化とは、単にコードを短くすることじゃない。ブラウザという「巨大なエンジン」の機嫌を損ねないように、データの流れや描画の範囲を設計してやることなんだ。
`contain` を使いこなせば、君はブラウザのレンダリングパイプラインをコントロールできるようになる。それは、ただツールを使っているだけのエンジニアから、ブラウザの仕組みを理解したアーキテクトへの一歩目だ。
次回のコードレビューで、もしパフォーマンスに悩んでいる後輩がいたら、「ここ、`contain` でスコープを切ってみたら？」と優しくアドバイスしてやってくれ。その一言が、君のチームのプロダクトを劇的に軽くするはずだ。
それじゃあ、また現場で会おう。健闘を祈る。
コメント