はじめに

ブラウザは、ウェブページを表示するためのアプリケーションで、以下のような主要な仕組みで動作しています。

URL入力とDNS解決

ユーザーがアドレスバーにURL（例: https://example.com）を入力します。
ブラウザは、このURLのドメイン名（例: example.com）をIPアドレスに変換するため、DNS（Domain Name System）を使用します。
これにより、サーバーの位置が特定されます。

HTTP/HTTPSリクエストの送信

ブラウザは、指定されたサーバーに対してリクエストを送信します。
このリクエストは、HTTPまたはHTTPSプロトコルを使用して行われ、ウェブページやリソース（画像、CSS、JavaScriptなど）を要求します。

サーバーからのレスポンスの受信

サーバーは、HTMLやその他のリソースをレスポンスとして返します。
HTTPSの場合、データは暗号化されており、ブラウザはSSL/TLSでデータを復号化します。

HTMLの解析とレンダリング

ブラウザの「レンダリングエンジン」（例: ChromeのBlink、FirefoxのGecko）がHTMLを解析
DOM（Document Object Model）ツリーを作成
CSSを解析してスタイルルールを適用し、CSSOM（CSS Object Model）ツリーを作成
JavaScriptエンジン（例: ChromeのV8）がスクリプトを実行し、動的なコンテンツを生成

レンダリングと画面表示

DOMツリーとCSSOMツリーを統合してレンダーツリーを作成
レンダーツリーを基に、ピクセル単位でウェブページを描画

※描画とは
レイアウト（配置）: 各要素の位置やサイズを計算。
ペイント: 背景、文字、画像を描画。
コンポジティング: レイヤーを合成して最終的な表示を生成。

インタラクションの処理

ユーザーがクリック、スクロール、入力などの操作を行うと、ブラウザがイベントをキャプチャして処理します。
必要に応じて、DOMやスタイルを再計算し、再描画（Repaint）や再レイアウト（Reflow）が行われます。

キャッシュとリソースの最適化

一度取得したリソースをキャッシュに保存し、次回以降の読み込みを高速化します。
また、圧縮やデータの優先読み込みなどを行い、パフォーマンスを向上させます。

今回の内容

これらがブラウザの基本的な仕組みです。内部ではさらに複雑な処理が行われていますが、この流れを理解すると、ウェブページがどのように動作しているかの全体像を掴めます。

今回は一歩踏み込んでchromeを例にしてDevtoolに表示される用語などを説明していこうと思います。

なぜ書こうと思ったのか

開発環境は常に改善が行われAIを使った補助がある時代です。今若手と呼ばれる人々は自分を超えてより高いレベルのエンジニアになるだろうというのは疑う余地がありません。
ですが根本的な知識というのは様々なツールのおかげで触れる機会が減りつつあるのではないかと思いました。

ブラウザとはなんぞや

という内容を若手向けにつらつら書こうと思ったわけですが、
世の中には優秀な先人がいるもので探せば詳細に説明がなされています。
ですので一歩踏み込んでchromeを例にしてDevtoolに表示される用語、機能などを説明していこうと思います。
デバッグや、ブラウザのバグに直面したときの理解につながれば幸いです。

chromeでは「その他のツール」> 「デベロッパーツール」から開きます

ちなみに公式でもユースケースが書かれているので見ておくと役に立つかもしれません。

Network

ネットワークアクティビティの検査できます。
かなり多機能なのであまり触っていないとどこから手を付けるのか見た目では分かりづらいかもしれません。

まずここで表示されている列項目が違うかもしれません。

列名を右クリックすると表示項目を選択できます

各項目の説明は公式概要を見ると良さそうです

あるある事例

ページで機能していなさそう

よくあります。その場合Networkを表示、ページをリロードしてみます。
その後Filterがあるので名称やドメインで検索します。(xxx.js、example.com、xxx/apiなど)
存在すればひとまず画面には読み込まれていそうです。
その際Statusを確認し正常に読み込まれているか確認します。

謎のjsが読み込まれている

出どころを知りたいことがあります。

Nameを選択すると詳細が表示されます。
Initiatorではrequestに至るまでのchainがあるので確認してみるとどこからか呼ばれています。

「Elements」パネル
Networkからurlを選択「Response」
Name右クリック > 「Open in Source panel」
などから実際にcodeから実装箇所を確認します。

読み込みが妙に遅い

簡単に確認するには「LightHouse」「Performance」などから見ると遅い(重い)リソースが存在しているかもしれません。

ここでいう遅い(重い)とは、を知るためにNetworkパネルを利用します。
Timingタブを見ます

requestタイミングが視覚的にわかります。
もしとても長いrequestがあればmouseoverもしくはrequestの選択で詳細を見ます。

用語は公式でも説明されていますが簡単にまとめると

名称	説明
Queueing	接続開始前にリクエストをキューに追加します。リクエスト上限を超えて処理が追いつかないと長くなります。
Stalled	読み込み優先度、cacheなどによって一時停止しています。
DNS Lookup	ブラウザがリクエストの IP アドレスを解決しています。(そのままの意味ですね)
Initial connection	接続を確立するためTCP handshake、再試行、SSL のネゴシエーションなどを行います(ここではSSLが別で表示されています)
Request sent	送信！
Waiting	最初のバイトまでの時間です。ここが遅いときサーバーレスポンスが遅いかもしれません。
Content Download	実際のダウンロードです。ここが遅いときNetworkやPCが別タスクで負荷が高い状態かもしれません。

表示項目が少ない場合Size、Headerなどからcacheされていないか確認します

serviceWorkerについてはrespondWithで詳細を見ることができます

Performance

ウェブサイトのパフォーマンスを分析できます。
Networkと比較すると用語が多いので
ブラウザの仕組みをイメージしながら触ると理解しやすいかと思います。

開くとまずリアルタイムに情報が更新されます。
Interaction(ユーザーの操作)やLayout shifts(レイアウトの変更)がどんどん追加されます。

Largest Contentful Paint (LCP)

LCP は、ビューポート内に表示される最大の画像、テキストブロック、または動画のレンダリング時間を、ユーザーが最初にページに移動したタイミングと比較する形で確認できます。

大きなペイントが発生している場合に数字が大きくなります。
最適化できる余地がありそうです。

Cumulative Layout Shift (CLS)

CLS は、ページのライフスパン全体で発生した予期しないレイアウトシフトのレイアウト移動スコアの最大バーストを測定します。

画面上でガタガタしているような状態をスコアにしています。
usabilityを改善できそうですね。

Interaction to Next Paint (INP)

INP は、ユーザーによるページアクセスの全期間中に発生するすべてのクリック、タップ、キーボード操作のレイテンシをモニタリングすることで、ユーザーインタラクションに対するページの全体的な応答性を評価するための指標です。

入力遅延の指標で実際にはイベントの重複やタイマー処理を最適化できそうです。

Recordしてみる

全体を通して妙に処理が重い、表示が遅いというときに一覧したい際利用します。

情報量が多いので整理していきます。

Network

Networkパネルでも同様ですがここでも見ることができます。

選択すると下部のSummaryで表示されます。(範囲選択もできます)
またCall treeを表示することができ、詳細にどの部分で時間がかかっているかを一覧できます。

処理を追う際Sourcesでデバッグしていくほうがわかりやすいですが詳細に処理の内容を知りたい場合役に立つことがあります。

serviceWorkerについてはrespondWithで詳細を見ることができます

トラック

様々な情報がありますがMainトラックに注目します。

処理のスタックと長さがわかります。選択すると下部でEventLogを見られます。
単純にJSを読み込むと言っても順を追った処理が行われていることがわかります。

さいごに

触ってみると意外と簡単ですし問題解決のヒントになることはとても多いです。
ブラウザの仕組みを知っているとより理解しやすい部分もあり
学習が必要ですがそれぞれ資料を貼っているので追えるはず。
もっと気になったらブラウザを作ってみるのも理解につながると思います。

アドベントカレンダーも残ることあと1日、マイボス登場です。