こんにちは！フロントエンド・アーキテクトの私です。

日々、Webサイトを作ったり、JavaScriptでガリガリとアニメーションを実装したりしていると、「なんだか最近、画面がカクつくぞ…？」という壁にぶつかることってありませんか？ ユーザーのスクロールに合わせて要素をボコボコ追加したり、複雑なリストを再描画させたりしたときに、急に重くなる現象です。

実は、Webブラウザの内部では、私たちが書いたコードの裏で「いかに効率よく画面をピクセル単位で描き直すか」という壮大なドラマが繰り広げられています。

今回は、そのブラウザの裏側の世界をちょっと覗いてみましょう。テーマは「ディスプレイロッキング（Display Locking）」という、少し難しそうだけど、知ると「おぉ、ブラウザって頭いいな！」と感動する仕組みについてです。

専門用語の荒波に溺れないよう、身近な例えを交えながら優しく紐解いていきますので、どうぞリラックスしてコーヒーでも飲みながら読んでいってくださいね。

—

1. そもそもブラウザって、画面をどうやって作っているの？

ディスプレイロッキングのお話をする前に、まずはブラウザが画面を表示するまでの「お仕事の流れ」をざっくりとおさらいしておきましょう。

私たちが書いたHTMLやCSSを、ブラウザは次のような手順で料理します。

1. HTMLを読む（パース）：「ここにタイトルがあって、その下にリストがあって……」と骨組みを作ります（DOMツリー）。
2. CSSを読む（パース）：「タイトルは赤色で、リストの余白はこれくらいね」とデザインを当てはめます（CSSOMツリー）。
3. 合わせる：骨組みとデザインをドッキングさせます（レンダーツリー）。
4. 配置して塗る：「この要素はこの座標に置いて、色を塗って……」と計算し、最終的に画面にピクセルとして描き出します（レイアウト・ペイント・合成）。

ここでポイントなのは、ブラウザは基本的に「Webページ全体、あるいは大きな変更があった部分のすべてを、責任を持って一気に再計算しようとする」という真面目すぎる性格をしている点です。

もし、画面のずーーっと下の方にある、普段ユーザーが見ていない小さなパーツ（DOMのサブツリー）をJavaScriptでちょっと書き換えただけでも、ブラウザは「大変だ！全体に影響があるかもしれないから、まわりのレイアウトも全部計算し直さなきゃ！」と、せっせと汗を流してしまいます。

……これ、ちょっともったいないですよね？ 見えていない場所なのに。

2. 「ディスプレイロッキング」ってなに？ 身近な例えで考えてみよう

ここで登場するのが、今回の主役である「ディスプレイロッキング」です。

難しく考えず、身近な例えでイメージしてみましょう。

あなたは今、ものすごく分厚い「百科事典」の編集長をしています。
ある日、読者から「300ページ目にあるコラムの、ほんの一部の表現を変えてほしい」と連絡が入りました。

普通のやり方だと、編集長であるあなたは「よし、全体とのバランスを見るために、1ページ目から500ページ目までのレイアウトを全部チェックし直すぞ！」と、本全体を最初からめくり直してしまいます。これでは時間がいくらあても足りませんよね。

そこで、こう考えます。
「待てよ、今修正しているコラムのページは、まだ読者には見せていない（あるいは今は関係ない）んだから、その部分だけクリップで留めて、他のページに影響が及ばないように『一時的に鍵（ロック）』をかけておこう。そして、全体のレイアウト計算の対象から外してしまおう！」

この「見えていない部分や、いま関係のないサブツリー（木構造の一部）のレンダリング作業を、一時的に一時停止（ロック）して省エネしちゃおう」というブラウザの最適化の概念、それがディスプレイロッキングです。

ブラウザは賢いので、「あ、このエリアは今画面に入っていないな」「ユーザーに見せる必要がまだないな」と判断すると、その部分のスタイル計算やレイアウトの計算をサボって（遅延させて）くれます。これにより、CPUやメモリの無駄遣いを防ぎ、メインの画面をサクサク動かせるようにしているんです。

—

3. つまずきやすいポイント：見えない場所で起きていること

Web制作を学んでいると、「JavaScriptで要素を作ったのに、なぜかスタイルが当たらない？」「高さを取得しようとしたら `0` になっちゃった！」という不思議な現象に出会うことがあります。

「えっ、コードは間違っていないはずなのに……なんで！？」と、ここでパニックになってしまう初学者の方も多いのですが、大丈夫ですよ、あなたが悪いわけではありません。

ブラウザがパフォーマンスを優先するあまり、「まだ画面に必要ない（あるいはロックされている）から、レイアウトの計算を後回しにしよう」と気を利かせた結果、私たちが欲しい情報（要素の正確なサイズなど）がまだ計算されていない、というケースがあるのです。

ブラウザの「ちょっと待って、今忙しいから後でね！」という裏の事情を知っているだけでも、「あ、今計算がスキップされているんだな」と心に余裕が持てるようになりますよね。

—

4. 実務でどう活きる？ モダンWebの工夫

さて、このディスプレイロッキングの概念をさらに押し進めた、現在進行形のブラウザの標準技術に「Content Visibility (`content-visibility`)」というCSSプロパティがあります。

これを使うと、開発者である私たちがブラウザに対して、「この大きなリストのエリアは、画面に入るまで中身のレイアウト計算をロック（サスペンド）していいよ！」と直接指示を出せるようになります。

言葉だけだとイメージしにくいと思うので、実際にエディタに貼り付けて試せるサンプルコードを見てみましょう。何千件もあるような長いリストを効率よく表示するための、現代のフロントエンドのテクニックです。

サンプルコード：`content-visibility` を使ったパフォーマンス最適化

ディスプレイロッキングの実験場

下のほうにあるアイテムは、スクロールして画面に入るまでブラウザの計算が「ロック」されています。

コードのポイント

• `content-visibility: auto;`: これがまさに、ブラウザに「画面外ならこのサブツリーのレンダリングをロックして！」とお願いする強力なプロパティです。これだけで、初期表示のスピードが劇的に変わることがあります。
• `contain-intrinsic-size`: ロックされている最中に「だいたいこれくらいの大きさのスペースを空けておいてね」とブラウザに伝える設定です。これを指定しないと、スクロールした瞬間にページ全体が「グイッ」と縦に伸び縮みしてしまい、ユーザー体験がガタガタになってしまうのでセットで覚えておきましょう！

—

おわりに

今回は、ブラウザの裏側の知恵である「ディスプレイロッキング」について、少しおしゃべりするように解説してみました。

普段私たちが何気なく書いているHTMLやCSS、そしてJavaScriptですが、その裏ではWebブラウザという優秀な相棒が、「どうやったらユーザーにサクサク快適な画面を届けられるか」を常に考え、こうしたレンダリングの最適化（ロック）をこっそりと頑張ってくれています。

もし今後、「画面が重いな」「ブラウザの動きを最適化したいな」と感じる場面に出会ったら、ぜひ今回の「画面に見えていない部分の計算をどうやって賢くサボらせるか（ロックするか）」という視点を思い出してみてください。

フロントエンドの世界が、これまでよりも少しだけ立体的に、そして面白く見えてくるはずです。

それでは、あなたの開発ライフが快適でハッピーなものになりますように！また次回の記事でお会いしましょう。