AI時代のウェブパフォーマンスエンジニアリング (Japanese Edition)

第5章 ブラウザ内部 ：ページの読み込みとレンダリングの仕組み

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

これまで本書では、ウェブパフォーマンスがユーザ体験とビジネスの成功に不可欠な理由を学び、Core Web Vitalsなどの主要メトリックについて理解を深めてきた。この章では技術的な基盤に焦点を当てる。 読み込み速度、インタラクティブ性、視覚的安定性を効果的に最適化するには、まずブラウザの動作原理をしっかりと理解する必要がある。この章では、Chromeなどのブラウザがコードやリソースを完全にレンダリングされたインタラクティブなページに変換する過程を掘り下げる。この知識は、以降の章で説明する具体的な最適化戦略の基礎となる。

ブラウザの基本

現代のウェブブラウザは非常に洗練度が高い。HTMLを解析し、スクリプトやスタイル、画像などのリソースを読み込み、JavaScriptを実行し、スタイルとレイアウトを計算し、画面にピクセルを描画する。その全てを、ユーザー入力に応答しつつ、アニメーションを滑らかに保とうとしながら行うのだ。パフォーマンスを最適化するには、ブラウザが経るステップと、それらのステップを高速化またはブロックする方法を理解することが重要だ。 本章では、Chrome（Blinkエンジン）を中心に、ブラウザのレンダリングパイプラインとCPU上でのスケジューリングの仕組みを解説する。Chromeを主軸とするが、基本的な概念は現代のブラウザ全般に適用可能だ（実装の詳細は異なる場合がある）。Chromeは市場シェアで圧倒的優位を保ち、アーキテクチャも詳細に文書化されているため、理想的なケーススタディとなる。Chromeを理解すれば、サポートが必要な全ブラウザのパフォーマンスについて推論する基盤が得られる。

まずページロードのライフサイクルを追う：ナビゲーション開始から、読み込み・解析を経て、レンダリングとやり取りまで。次にChromeのアーキテクチャを覗き見する：メインスレッド、コンポジタースレッド、ネットワークスタック、タスクの優先順位付けといった高度な概念も含む。

マルチプロセスアーキテクチャとメインスレッド

スレッドとは プログラム内の基本実行単位だ。CPUが独立して実行できるシーケンスと考えるといい。単一プロセス内で複数のスレッドが並行して実行可能であり、HTML解析とユーザ入力処理を同時に行うなど、プログラムが複数の作業を同時にこなせるようになる。

Chromeや他の現代的なブラウザは、安定性とセキュリティのためにマルチプロセスアーキテクチャを採用している。これはブラウザが複数の独立したプロセス（メモリ内の隔離されたプログラム）を実行し、それぞれが独自のスレッドを持つことを意味する。 あるプロセスがクラッシュしても（例えば不具合のあるWebサイトが原因で）、ブラウザ全体がダウンすることはない。そのタブだけが機能しなくなる可能性がある。新しいサイトに移動すると、Chromeは通常、そのページを処理するために新しいレンダラープロセス（他のプロセスから隔離されたもの）を起動する。レンダラープロセスは、レンダリングエンジンであるBlinkが動作する場所だ。そこには スレッドが含まれており、具体的には以下のものがある：

• メインスレッドは、JavaScriptとDOM操作の大部分を実行する

• コンポジタースレッド。グラフィックレイヤーの処理やスムーズなスクロールを支援する ...