ブラウザの「無駄な重労働」を止める：Display Locking API という最強の武器
現場で「なぜかUIがカクつく」「レンダリングが一瞬止まる」という壁にぶつかったことはないだろうか？
フロントエンドエンジニアが避けて通れないのが、ブラウザのレンダリングパイプラインだ。DOMをちょこっといじっただけで、ブラウザは「DOMツリー構築→スタイル計算→レイアウト（リフロー）→ペイント→コンポジット」という重いタスクを、心優しくも律儀に画面全体に対してやり直してくれる。
だが、考えてもみてほしい。画面の端にある小さなサイドバーの数値を1つ変えただけで、ページ全体を再計算させる必要があるだろうか？ ブラウザは「君が何をしたか」を完全には理解していない。だから、念のために「全部やる」という安全策を取る。これがパフォーマンスのボトルネックの正体だ。
そこで登場するのが、Display Locking API（現在は `content-visibility` CSSプロパティとして実装されているものが主流だ）だ。今日は、この「ブラウザの労働を制限する」という、極めて賢い技術について深掘りしよう。
—
ブラウザの裏側で起きていること：なぜ「全部」やるのか
ブラウザのレンダリングエンジンは、基本的に「怠惰」であると同時に「過保護」だ。
DOMツリーの一部が変更されると、ブラウザは「影響範囲がどこまで及ぶか」を推測する。しかし、CSSの複雑な継承やレイアウトの依存関係がある以上、多くの場合「広範囲な再計算」というコストを支払うことになる。
特に、SPAで巨大なコンポーネントを出し入れする際、ブラウザは表示されていない（あるいは画面外の）要素のスタイル計算まで一生懸命行っている。これがメインスレッドを占有し、ユーザーのスクロールやクリックを阻害する。
Display Locking（content-visibility）は、この過保護な動作を物理的に遮断するゲートキーパーだ。
「ここから先は、私が言うまでレンダリングするな」とブラウザに命令することで、本来なら発生するはずだったスタイル計算やレイアウト処理をスキップさせる。これがどれほど強力か、想像できるだろうか？
—
実践：`content-visibility` でレンダリングを「封印」する
最も現場で使いやすく、即効性があるのが `content-visibility: auto` だ。これを使うと、ブラウザは「その要素が画面内にあるか」を判定し、画面外にあればレンダリング処理をバッサリとカットしてくれる。
/ 現場で使える実践的な設定 /
.heavy-component {
/
- auto: 画面外ならレンダリングをサボる（スタイル計算とレイアウトをスキップ）
- contain-intrinsic-size: 要素の「仮の高さ」を定義。
これがないと、レンダリング時に高さが0になり、スクロールバーがガタつく。
/
content-visibility: auto;
contain-intrinsic-size: 0 500px; / 概算のサイズを教えるのがコツ /
}
なぜ `contain-intrinsic-size` が重要なのか？
ここが初心者がハマるポイントだ。ブラウザにレンダリングをサボらせると、その要素は「中身がない状態」として認識される。するとページ全体の高さがガクンと縮み、スクロールバーが激しく暴れる現象（レイアウトシフト）が起きる。
だからこそ、「だいたいこれくらいのサイズになる」という予測値を渡しておくのが、プロとしての責任ある実装だ。
—
さらに一歩先へ：`contain-intrinsic-size` の動的制御
もし、レンダリングされるまで正確な高さがわからない場合は、JavaScriptで少しだけ補佐してやる必要がある。
// 動的に高さを計算して最適化する例
const element = document.querySelector(‘.heavy-component’);
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
// 画面内に入ったら、実際の高さに合わせて調整するなどの処理をここで挟める
console.log(‘レンダリング対象になりました’);
}
});
});
observer.observe(element);
—
現場のエンジニアへ：明日からの心得
Display Locking API を使いこなすことは、「ブラウザをコントロール下に置く」ということだ。
1. 闇雲に使わない: ページの全ての要素に適用する必要はない。リストの項目や、画面外に隠れている重いセクションに絞ること。
2. 計測を忘れるな: Chrome DevTools の「Rendering」タブを開き、「Frame Rendering Stats」を見てほしい。適用前と後で、メインスレッドの負荷がどう変わったか。数字で語れない最適化はただの自己満足だ。
3. 互換性を確認: 現在、主要ブラウザは概ねサポートしているが、古いブラウザを切り捨てる判断が必要な場合もある。`@supports` を使った条件分岐を忘れないように。
@supports (content-visibility: auto) {
.heavy-component {
content-visibility: auto;
contain-intrinsic-size: 1000px;
}
}
Webブラウザは魔法の箱ではない。論理的な挙動の積み重ねで動くマシンだ。その仕組みを理解し、ブラウザの「無駄な努力」を止めてあげることこそが、最高のエクスペリエンスを生む近道だと僕は信じている。
まずは、今抱えているプロジェクトの「特に重いリスト」に `content-visibility: auto` を一行、書き加えてみてほしい。世界が変わるはずだ。
コメント