こんにちは。君もそろそろ、複雑なSPA（シングルページアプリケーション）のパフォーマンスチューニングで泥を被る時期だな。

「ユーザーがボタンを連打したときに画面がカクつく」「無限スクロールのリストの末尾にアイテムを追加した途端にメインスレッドが死ぬ」。こうした地獄のような現象に直面したとき、君はDOMをただ闇雲に `requestAnimationFrame` で包んだり、`debounce` を仕掛けたりしてごまかしていないか？

今日は、そんなフロントエンドのパフォーマンス最適化のネクストステージとして、ブラウザのレンダリングパイプラインの裏側でうごめく「ディスプレイロッキング（Display Locking）」の概念について話をしよう。

これは、モダンブラウザが隠し持っている極めて強力な最適化の切り札だ。これを理解しているかいないかで、重厚長大なWebアプリケーションのUXは天と地ほどの差がつく。さあ、深掘りしていこうか。

—

1. ディスプレイロッキングとは何か？（ブラウザの裏側の世界）

まず、ブラウザが画面を一枚の絵として描き出すまでの基本的なフローを思い出してほしい。
HTMLがパースされてDOMツリーができ、CSSが当たってCSSOMが構築され、両者が合体してレンダーツリー（Layout Tree / Box Tree）が作られる。そして、それぞれの要素の位置や大きさを計算する「レイアウト（リフロー）」、実際にピクセルを塗りつぶす「ペイント」、そしてそれらを合成する「コンポジット」へと進む。

ここで問題になるのが、「画面の隅っこにある、ユーザーから全く見えていない巨大なDOMサブツリー」の存在だ。

例えば、何千行もある折りたたみ式のデータグリッドや、タブ切り替えの裏に隠された膨大なフォーム群を想像してほしい。ユーザーがそれらを見えていない（あるいは触っていない）にもかかわらず、親要素でちょっとしたスタイル変更やクラスの付替が起きると、ブラウザは親切心からその「見えていないサブツリー」のレイアウトやスタイル再計算を律儀に実行してしまう。

……アホらしいと思わないか？ ユーザーの目に触れていない、あるいはインタラクションが起きていない領域の計算コストを払わされるなんて、メインスレッドの無駄遣いだ。

そこで登場するのがディスプレイロッキング（Display Locking）という概念だ。
これは、「特定のDOMサブツリーに対するレンダリング作業（スタイル計算、レイアウト、ペイントなど）を、開発者の明示的な指示によって一時的にブロック（凍結）し、ブラウザの無駄な計算コストを徹底的に削ぎ落とす」ためのブラウザ内部のアーキテクチャ、およびそれを制御するためのAPI群を指す。

ブラウザのC++レベルのレンダリングエンジン（BlinkやWebKitなど）において、ロックされたサブツリーは一時的にレンダリングパイプラインから切り離される。つまり、その内部で何が起ころうとも、ブラウザはスタイルやレイアウトの再計算を「サボる」ことができるのだ。

—

2. 実務でどう使うのか？ `content-visibility` との密接な関係

仕様としてのディスプレイロッキングは、かつてはより低水準なAPIとして提案されていたが、現在ではCSSのプロパティである `content-visibility`、そしてそれに付随する `contain-intrinsic-size` を通じて、我々フロントエンドエンジニアの手に直接委ねられている。

特に `content-visibility: auto;` は、ブラウザに「この要素がビューポートに入るまでは、勝手にディスプレイロッキングを適用してレンダリングをサボってくれ」と指示する魔法の杖だ。

しかし、単なるスクاطト最適化（遅延ロード的なアプローチ）にとどまらず、「今まさに動的につまりまくっている重いDOMツリーの描画を、コードから意図的にコントロールしたい」というシチュエーションには、もう少し踏み込んだ理解が必要になる。

百聞は一見に如かず。現場で即座に使える、ディスプレイロッキングの概念を応用した実践的なコンポーネントのサンプルコードを見てみよう。

—

3. 実践コード：重いサブツリーを制御する仮想コンポーネント

以下のコードは、大量のDOMノードを含むアコーディオン（または折りたたみパネル）を実装する際に、開閉状態に応じてディスプレイロッキング（`content-visibility`）を動的に切り替え、不要なレイアウト計算を完全にシャットアウトする実用的なパターンだ。

---

4. シニアとして後輩に伝えたい「実務の罠とベストプラクティス」

このディスプレイロッキングや `content-visibility` を実務のコードベースに導入する際、君たちが絶対にハマる「落とし穴」がいくつかある。シニアの経験則として、これだけは覚えておいてほしい。

1. `contain-intrinsic-size` をサボるな
`content-visibility: auto;` を指定すると、ブラウザはその要素のサイズを初期状態で「0×0」とみなしてレイアウトを構築しようとする。その結果、ユーザーがスクロールした瞬間にコンテンツが表示されてページ全体がガタガタと大きく揺れる「レイアウトシフト（CLS）」の地獄が起きる。
必ず `contain-intrinsic-size` で大体の高さを見積もって指定するか、`auto` キーワード（例: `contain-intrinsic-size: auto 500px;`）を組み合わせて、ブラウザの自動サイズ測定に優しくヒントを与えてやることだ。

2. フォーカス管理とアクセシビリティの罠
ディスプレイロックされたサブツリーの内部にある要素は、事実上の「非表示」に近い状態（厳密にはフォーカス可能だが、ユーザーから見えない、あるいは検索に引っかからないなど）になる。
キーボードナビゲーション（Tabキーでの移動）やページ内検索（Ctrl+F）がロック中の要素に対して予期せぬ挙動を起こすことがあるため、タブの切り替えやアコーディオンの展開時には、適切なタイミングでDOMのフォーカスをコントロールする泥臭いJavaScriptのケアが必要になる。

3. 「とりあえず全部に付ける」の厳禁
「パフォーマンスが上がるらしいから、すべてのコンポーネントに `content-visibility: auto` を貼ろうぜ！」というジュニアによくいる暴走は絶対に止めろ。
ブラウザがロック状態を管理するためのオーバヘッド（メンテナンストラック）もゼロではない。画面のファーストビュー（Initial Viewport）に確実に入るメインビジュアルや、常に高頻度で再描画が必要な小さなコンポーネントにこれを貼ると、かえってパフォーマンスが劣化することもある。
「画面の初期表示に入らない重いサブツリー」「ユーザーがアクションするまで隠れている重いパーツ」にピンポイントで適用するのがプロの仕事だ。

---

Webブラウザという巨大で気まぐれなエンジンを手懐けるには、その内部でレイアウトやペイントがどういう順序でサボられているか（あるいはサボらせているか）を想像する力が必要不可欠だ。

ディスプレイロッキングの概念をモノにした君なら、もう大量のDOMを前に冷や汗をかくことはないはずだ。次のパフォーマンス改善のチケットが来たら、真っ先にこのアプローチを思い出してくれ。健闘を祈る！