ウェブブラウザがページを取得して表示するまでの流れ

1. はじめに
2. Chrome デベロッパーツールの [Network]パネル
3. リソース毎の処理の流れ
4. その後の流れ
5. DOMContentLoaded と load イベント
6. グラフサンプルとその説明
7. 参考
- (資料) 電子情報学特論：Chromiumのアーキテクチャを解き明かす – Google スライド

1. はじめに

このページでは、Chrome ブラウザのデベロッパーツールを使って、ウェブブラウザがウェブページを取得して表示するまでの流れについてまとめます。

ウェブブラウザが特定のウェブページ（リソース）を取得して表示する過程には、多くの処理が含まれますが、これをざっと理解するためには、ウェブブラウザのデベロッパーツールが役に立ちます。

2. Chrome デベロッパーツールの [Network]パネル

Chrome デベロッパーツールは、[設定]アイコン – [その他のツール] – [デベロッパーツール]から開くことができます。

この中にある [Network] パネルでは、ウェブブラウザがウェブサーバーにリクエストした各リソース毎に「どの処理に」「どのくらい時間が掛かったか」がグラフで表示されます（他のメジャーなウェブブラウザでも同じようなツールがついています）。

※ グラフが表示されない場合は、画面をリロードしてください。

Chrome デベロッパーツールの [Netrowk] タブ — Chrome デベロッパーツールの [Netrowk] パネル

HTMLファイルを選択して、[Timing]タブを表示したところ — HTMLファイルを選択して、[Timing] パネルを表示したところ

このグラフについての説明は、Network Analysis Reference | Tools for Web Developers | Google Developers（日本語訳）に記述されているのですが、見辛いのでここでもまとめておきます。

3. リソース毎の処理の流れ

１つのリソースに対する処理の流れを、以下の表にまとめました。

一番左にある[No.]列の背景色は、[Network] パネル内のグラフの色と対応させています。

No.	フェーズ	説明
Resource Scheduling
1	Queueing	キューに入れられている時間 ※ この時間が発生する要因より優先度の高いリクエストが他にあった場合既に6つのTCPコネクションが、同じオリジンに対して開いていた場合（HTTP/1.0 と HTTP/1.1 のみでの動作） etc.
Connection Start
2	Stalled	リクエストを送信できるようになるまでの待機時間 ※ この時間が発生する要因プロキシネゴシエーション Queueing のところに書いた要因の場合もある
3	DNS Lookup	DNS により、ホスト名を名前解決してIPアドレスを取得するのにかかった時間
4	Initial connection	接続の確立にかかった時間 TCP のハンドシェイク / 再試行 SSL のネゴシエーション etc. ※ HTTP/2 だと、1度のページ取得あたり 1回で済む ※ SSL ネゴシエーションの部分は、独立した項目として表示される。紫色で表示される → Initial connection とグラフ位置は重なる。
Request/Response
5	Request sent	ネットワークリクエストの発行にかかった時間（通常は、1000 分の 1 秒以下）
5a	ServiceWorker Preparation	ブラウザが service worker を起動した時間
5b	Request to ServiceWorker	リクエストが service worker に送信されている時間
6	Waiting (TTFB)	リクエスト送信後、レスポンスとして最初のバイトを受け取るまでの時間（TTFB: Time To First Byte） ※ 主に以下の2つの時間の合計です。サーバーがレスポンスを用意する時間返信の通信データがネットワークを通じてクライアントまで届くのに掛かった時間
7	Content Download	レスポンスデータの受信にかかった時間

4. その後の流れ

最初のHTMLファイルをダウンロードするあたりからの処理の流れ
（CSS, JavaScript, 画像ファイルなど。並列に行われる）
※ あくまで私の理解している内容です。細かく見ると正確でない部分もあると思います。

No.	説明
1	readyState が loading になる。 HTMLファイルのダウンロード HTMLを上からパースする（DOMツリーを構築する）外部CSSファイルのタグが見付かればダウンロードする → CSS のパース（= CSSOM の構築）（終わるまでJavaScriptの実行を遅らせる） ※ インラインCSSはそのままパースされる。 ※ CSS の各工程は、JavaScriptの実行をブロックする。 ※ CSS の各工程は、レンダリングツリーの構築もブロックする。外部JavaScriptファイルのタグが見付かればダウンロードする `async`属性を持った JavaScript ファイルのダウンロードは、HTMLのパース処理と平行して行われる（つまり非同期。優先度は低くなる。）。ダウンロード完了後、即座に実行される（実行は同期、つまりDOMツリー構築をブロックする）。HTMLパースが最後まで処理される前に、このJavaScriptが実行されると、その分 DOMContentLoaded の発生タイミングが遅くなる。 `defer`属性を持った JavaScript ファイルのダウンロードは、HTMLのパース処理と平行して行われる（つまり非同期。優先度は低くなる。）。どちらの属性も持たない JavaScript ファイルはダウンロード後、実行される。 ※ インライン JavaScript はそのまま実行される。画像リンクが見付かればダウンロードする（優先度は低い） readyState が interactive になる。 `defer`属性を持つ JavaScript ファイルの実行
2	No.1 の処理の途中、その時点での DOM ツリーと CSSOM ツリーを元に以下の処理も始まる DOM ツリーと CSSOM ツリーをマージして、レンダリングツリーを形成レイアウト処理（各オブジェクトの正確な位置とサイズを計算）レンダリング開始（ペイント処理） ※「すべてのリソースが処理されてから、この工程が1回だけ行われる」だと、ブラウザのウィンドウに何も表示されない状態が長く続いてしまうため、DOMパーシングの段階に応じて、この工程が複数回実行される。大きなページであればこの回数は多くなる。
3	完全なDOMツリーが完成したら（= HTMLを最後までパースし、見付かった JavaScript（async は除く）をすべて実行したら。見付かったCSSは最後まで処理できてなくてよい。）、DOMContentLoaded イベント発生これ以降、DOMの各要素に対して JavaScript で処理が実行できる。 ※ jQuery の `ready()` はこのイベントのタイミングで実行される。
4	すべてのファイル（画像も含む）をダウンロードしたら、Load イベント発生その直前に、readyState が complete になる。

<script> タグの async 属性と defer 属性

async 属性もしくは defer 属性がセットされた <script> タグでは、HTMLのパース処理をブロックせずに JavaScriptファイルがダウンロードされます。違いは以下です。

async 属性

JavaScriptファイルがダウンロードされたら即座に実行します。なのですが、非同期での実行であるため、パース処理の続きはすぐに再開されるでしょう。
ライブラリを読み込むのに適しています（DOMツリー構築前にライブラリがロードできるため）。
ライブラリであれば「実行」されるタイミングで行われるのは、コードがロードされるくらいなので、HTMLのパース処理をブロックする時間は短くて済みます。

defer 属性

HTMLのパースが終わってから実行されます。
そのため「実行時」に、DOMに対する処理を行う JavaScriptファイルを読み込むのに適しています。

詳細は、4.12.1 The script element | HTML Standard を参照してください。

引用元：4.12.1 The script element | HTML Standard

デモページを用意しました。

デモページ

? JavaScript ファイルの読み込みと実行のタイミングを調べる(async, defer)

5. DOMContentLoaded と load イベント

DOMContentLoaded と load イベントは、[Network] パネル内にも表示されます。

また、ウェブページを閉じる際には、beforeunload イベント → unload イベントがトリガーされます。

参考

Events – HTML Standard

6. グラフサンプルとその説明

HTMLファイル、CSSファイル、JavaScriptファイル、画像ファイルを使ったウェブページを読み込んだ場合の、[Network] パネルを一つ紹介します。
（クリティカルレンダリングパスのパフォーマンスを分析する | Web | Google Developers で紹介されている例です）

HTML ファイルをリクエストして、ダウンロードまで行います。
HTMLをパースします。
CSSファイルが参照されていたのでダウンロードを開始します。
画像ファイルが参照されていたのでダウンロードを開始します。
JavaScriptファイルも参照されていましたが、すぐにダウンロードは行わず、CSSOM が構築できるまでキューに入れて待ちます。
ダウンロードが終わったCSSをパースして CSSOM の構築を行ったら、JavaScriptファイルのダウンロードを開始します。
ダウンロードが終わったら、JavaScript のパース・実行を行います。
DOMContentLoaded イベントが発生します。
レンダリング（画面の表示）が開始されます。
画像ファイルはサイズが大きいため、やっとダウンロードが完了しました。
load イベントが発生します。

※ 一番下のファイル (inject.js)は無視して下さい。

7. 参考

(資料) 電子情報学特論：Chromiumのアーキテクチャを解き明かす – Google スライド

電子情報学特論：Chromiumのアーキテクチャを解き明かす – Google スライドというスライドがとても勉強になります。

その中から、2つスライドを載せておきます。

「Chromiumのアーキテクチャを解き明かす」の中の「全体像を振りかえる」というスライド — 64ページ

スポンサードリンク

No.	説明
1	readyState が loading になる。 HTMLファイルのダウンロード HTMLを上からパースする（DOMツリーを構築する）外部CSSファイルのタグが見付かればダウンロードする → CSS のパース（= CSSOM の構築）（終わるまでJavaScriptの実行を遅らせる） ※ インラインCSSはそのままパースされる。 ※ CSS の各工程は、JavaScriptの実行をブロックする。 ※ CSS の各工程は、レンダリングツリーの構築もブロックする。外部JavaScriptファイルのタグが見付かればダウンロードする `async`属性を持った JavaScript ファイルのダウンロードは、HTMLのパース処理と平行して行われる（つまり非同期。優先度は低くなる。）。ダウンロード完了後、即座に実行される（実行は同期、つまりDOMツリー構築をブロックする）。HTMLパースが最後まで処理される前に、このJavaScriptが実行されると、その分 DOMContentLoaded の発生タイミングが遅くなる。 `defer`属性を持った JavaScript ファイルのダウンロードは、HTMLのパース処理と平行して行われる（つまり非同期。優先度は低くなる。）。どちらの属性も持たない JavaScript ファイルはダウンロード後、実行される。 ※ インライン JavaScript はそのまま実行される。画像リンクが見付かればダウンロードする（優先度は低い） readyState が interactive になる。 `defer`属性を持つ JavaScript ファイルの実行
2	No.1 の処理の途中、その時点での DOM ツリーと CSSOM ツリーを元に以下の処理も始まる DOM ツリーと CSSOM ツリーをマージして、レンダリングツリーを形成レイアウト処理（各オブジェクトの正確な位置とサイズを計算）レンダリング開始（ペイント処理） ※「すべてのリソースが処理されてから、この工程が1回だけ行われる」だと、ブラウザのウィンドウに何も表示されない状態が長く続いてしまうため、DOMパーシングの段階に応じて、この工程が複数回実行される。大きなページであればこの回数は多くなる。
3	完全なDOMツリーが完成したら（= HTMLを最後までパースし、見付かった JavaScript（async は除く）をすべて実行したら。見付かったCSSは最後まで処理できてなくてよい。）、DOMContentLoaded イベント発生これ以降、DOMの各要素に対して JavaScript で処理が実行できる。 ※ jQuery の `ready()` はこのイベントのタイミングで実行される。
4	すべてのファイル（画像も含む）をダウンロードしたら、Load イベント発生その直前に、readyState が complete になる。