ナビの動作
これは、Chrome の内部の仕組みを紹介する 4 部構成のブログシリーズのパート 2 です。 前回の投稿では、生成 AI と プロセスとスレッドがブラウザのさまざまな部分を処理します。今回の投稿では ウェブサイトを表示するために、各プロセスとスレッドが通信します。
ウェブ ブラウジングの簡単なユースケースを見てみましょう。ブラウザには URL を入力し、 インターネットからデータを取得してページを表示します。この記事では、 ユーザーがサイトをリクエストすると、ブラウザはページのレンダリング(ナビゲーション)の準備をします。
ブラウザプロセスから始まります
<ph type="x-smartling-placeholder">![ブラウザ プロセス](https://developer.chrome.com/static/blog/inside-browser-part2/image/browser-processes-1abcf214c73ef.png?authuser=9&hl=ja)
前のモジュールで説明したように パート 1: CPU、GPU、メモリ、マルチプロセス アーキテクチャ タブ以外の要素はすべてブラウザ プロセスによって処理されます。 ブラウザ プロセスには、アプリのボタンや入力フィールドを描画する UI スレッドなど、 ブラウザ、インターネットからデータを受信するネットワーク スタックを扱うネットワーク スレッド、 ストレージスレッドのスレッドダンプが ありますアドレスに URL を入力すると、 入力はブラウザ プロセスの UI スレッドによって処理されます。
シンプルなナビゲーション
ステップ 1: 入力を処理する
ユーザーがアドレスバーへの入力を開始すると、UI スレッドが最初に「これは (検索語句または URL)を見つけますChrome のアドレスバーは検索入力フィールドでもあるため、UI スレッドは で解析を行い、検索エンジンとリクエストしたサイトのどちらへ送るかを判断する必要があります。
<ph type="x-smartling-placeholder">![ユーザー入力の処理](https://developer.chrome.com/static/blog/inside-browser-part2/image/handling-user-input-24fea2c817a6a.png?authuser=9&hl=ja)
ステップ 2: ナビを開始する
ユーザーが Enter キーを押すと、UI スレッドがネットワーク呼び出しを開始してサイト コンテンツを取得します。読み込み中アイコン 表示され、ネットワークスレッドは DNS ルックアップとリクエストの TLS 接続の確立。
<ph type="x-smartling-placeholder">![ナビ開始](https://developer.chrome.com/static/blog/inside-browser-part2/image/navigation-start-4aeb163d61a8c.png?authuser=9&hl=ja)
この時点で、ネットワーク スレッドは HTTP 301 などのサーバー リダイレクト ヘッダーを受信することがあります。その場合は ネットワーク スレッドが、サーバーがリダイレクトを要求している UI スレッドと通信する。次に、 別の URL リクエストが開始されます。
ステップ 3: レスポンスを読み取る
<ph type="x-smartling-placeholder">![HTTP レスポンス](https://developer.chrome.com/static/blog/inside-browser-part2/image/http-response-0ae2751b24973.png?authuser=9&hl=ja)
レスポンスの本文(ペイロード)の受信が開始されると、ネットワーク スレッドが最初の数バイトを調べます。 ストリームのコンテキストを追加します。レスポンスの Content-Type ヘッダーで、データの種類、 欠落または誤りの可能性があるため MIME タイプ スニッフィング ここで行います。これは「厄介なビジネス」ソースコードのコメントのとおりです。 このコメントを読むと、さまざまなブラウザでコンテンツ タイプとペイロードのペアがどのように扱われるかがわかります。
レスポンスが HTML ファイルの場合は、次のステップとしてデータをレンダラに渡します。 ZIP ファイルなどのファイルの場合はダウンロード リクエストなので、 ダウンロード マネージャーにデータを渡す必要があります。
<ph type="x-smartling-placeholder">![MIME タイプ スニッフィング](https://developer.chrome.com/static/blog/inside-browser-part2/image/mime-type-sniffing-444e1a2f5b037.png?authuser=9&hl=ja)
ここでもSafeBrowsing チェックが行われます。 ドメインと応答データが既知の悪意のあるサイトと一致しているように見える場合、ネットワークスレッドは 警告ページが表示されます。また Cross Origin Read Blocking(CORB) 機密性の高いクロスサイト セキュリティが データはレンダラプロセスに送られません
ステップ 4: レンダラのプロセスを探す
すべてのチェックが完了し、ネットワーク スレッドでブラウザが ネットワーク スレッドは UI スレッドに、データの準備ができたことを通知します。その後、UI スレッドが 処理してウェブページのレンダリングを続行します。
<ph type="x-smartling-placeholder">![レンダラのプロセスを検索](https://developer.chrome.com/static/blog/inside-browser-part2/image/find-renderer-process-4d4055665d4a7.png?authuser=9&hl=ja)
ネットワーク リクエストからレスポンスが返されるまでに数百ミリ秒かかる場合があるため、 最適化が適用されますUI スレッドが URL リクエストを どのサイトに移動するのかを すでに認識していますUI スレッド は、ネットワーク リクエストと並行してレンダラ プロセスをプロアクティブに検出または開始しようとします。このように すべてが想定どおりに進むと、ネットワーク スレッドが待機状態になったときに、レンダラ プロセスはすでにスタンバイ状態になっています。 受信します。このスタンバイ プロセスは、ナビゲーションがクロスサイト リダイレクトを行う場合、 その場合は別のプロセスが必要になることがあります
ステップ 5: ナビゲーションを commit する
データとレンダラ プロセスの準備が整ったので、ブラウザ プロセスから ナビゲーションを commit します。また、データ ストリームを渡すため、レンダラは HTML データを受信し続けることができます。ブラウザ プロセスが、commit が レンダリングプロセスが完了し、ナビゲーションが完了し、ドキュメントの読み込みフェーズが完了します。 開始されます。
この時点でアドレスバーが更新され、セキュリティ インジケーターとサイト設定の UI に 新しいページのサイト情報を指定します。タブのセッション履歴が更新され、バックフォワード 先ほど開いたサイト内を移動します。タブ/セッションの復元を容易にするため タブやウィンドウを閉じると、セッション履歴がディスクに保存されます。
<ph type="x-smartling-placeholder">![ナビゲーションを commit する](https://developer.chrome.com/static/blog/inside-browser-part2/image/commit-navigation-bc2943921c6f6.png?authuser=9&hl=ja)
追加のステップ: 初期読み込みの完了
ナビゲーションが commit されると、レンダラ プロセスはリソースの読み込みを続けて、
できます。この段階で行われる内容については、次の投稿で詳しく説明します。レンダラが
プロセスを「完了」するブラウザ プロセスに IPC を返送します(つまり、
onload
イベントがページ内のすべてのフレームで発生し、実行を終了したことを示します)。この時点で
UI スレッドがタブの読み込みスピナーを停止します。
私は「完了」と言います。クライアントサイドの JavaScript は依然として 追加のリソースが作成され、この時点以降に新しいビューがレンダリングされます。
<ph type="x-smartling-placeholder">![ページの読み込み完了](https://developer.chrome.com/static/blog/inside-browser-part2/image/page-finish-loading-1bee6888e9e56.png?authuser=9&hl=ja)
別のサイトに移動する
これで簡単なナビゲーションが完了しました。ユーザーがアドレスバーに別の URL を入力した場合はどうなるか
また?ブラウザ プロセスは同じステップを踏んで別のサイトに移動します。
ただし、その前に、現在レンダリングされているサイトで、
beforeunload
イベント。
beforeunload
さんは「このサイトから移動しますか?」というメッセージを作成できます。タブを閉じようとしたときにアラートが表示されます。
JavaScript コードを含め、タブ内の要素はすべてレンダラ プロセスによって処理されるため、
新しいナビゲーション リクエストが届いたときに、ブラウザ プロセスは現在のレンダラ プロセスをチェックする必要があります。
![beforeunload イベント ハンドラ](https://developer.chrome.com/static/blog/inside-browser-part2/image/beforeunload-event-handle-53b6fa7dd9be3.png?authuser=9&hl=ja)
レンダラ プロセスからナビゲーションが開始された場合(例: ユーザーがリンクをクリックした、
クライアントサイドの JavaScript が window.location = "https://newsite.com"
を実行した)
最初に beforeunload
ハンドラを確認します。その後、ブラウザ プロセスと同じプロセスを経て
開始されたナビゲーション唯一の違いは、ナビゲーション リクエストは
ブラウザ プロセスに渡します。
新しいナビゲーションが現在レンダリングされているサイトとは異なるサイトに行われた場合、
新しいナビゲーションを処理するために、現在のレンダリング プロセスを維持したまま、
unload
などのイベントを処理する。詳しくは、ページのライフサイクルの状態の概要をご覧ください。
イベントにフックする方法を
Page Lifecycle API
![新しいナビゲーションとアンロード](https://developer.chrome.com/static/blog/inside-browser-part2/image/new-navigation-unload-29ee714c3fcf4.png?authuser=9&hl=ja)
Service Worker の場合
このナビゲーションプロセスに加えられた最近の変更は Service WorkerService Worker は、 アプリケーション コード内のネットワーク プロキシ。ウェブ デベロッパーは、ウェブ デベロッパーが ネットワークから新しいデータを取得するタイミングを決定できます。ページを読み込むように Service Worker が設定されている場合 データをキャッシュから保存する場合は、ネットワークにデータをリクエストする必要はありません。
覚えておくべき重要な点は、Service Worker はレンダラで実行される JavaScript コードであるということです。 プロセスですしかし、ナビゲーション リクエストが届いたとき、ブラウザ プロセスはサイトに どうすればよいでしょうか。
<ph type="x-smartling-placeholder">![Service Worker のスコープの検索](https://developer.chrome.com/static/blog/inside-browser-part2/image/service-worker-scope-look-f48a8d509535a.png?authuser=9&hl=ja)
Service Worker が登録されると、Service Worker のスコープが参照として保持 (スコープについて詳しくは、 Service Worker のライフサイクルをご覧ください)。 ナビゲーションが発生すると、ネットワーク スレッドがドメインを登録済みの Service Worker と照合する その URL に Service Worker が登録されていれば、UI スレッドは 呼び出す必要がありますService Worker がキャッシュからデータを読み込むことで、 ネットワークにデータをリクエストする必要があるか、ネットワークに新しいリソースをリクエストする可能性があります。
<ph type="x-smartling-placeholder">![ServiceWorker のナビゲーション](https://developer.chrome.com/static/blog/inside-browser-part2/image/serviceworker-navigation-8576df1bffcf9.png?authuser=9&hl=ja)
ナビゲーションのプリロード
ブラウザ プロセスとレンダラ プロセスの間のこのラウンドトリップにより、遅延が発生する可能性があります。 Service Worker が最終的にネットワークからデータをリクエストした場合。 ナビゲーションプリロードは、これを高速化するメカニズムです。 Service Worker の起動と並行してリソースを読み込み、 これらのリクエストにヘッダーのマークを付け、サーバーはそれに基づいてさまざまなコンテンツを送信するかどうかを決定し、 これらのリクエストドキュメント全体ではなくデータを更新した場合などです
<ph type="x-smartling-placeholder">![ナビゲーションのプリロード](https://developer.chrome.com/static/blog/inside-browser-part2/image/navigation-preload-a859b1ad065e3.png?authuser=9&hl=ja)
まとめ
今回の投稿では、ナビゲーション中に行われる処理と、そのようなウェブ アプリケーションのコードがどのように動作するかを見てきました。 レスポンス ヘッダーとクライアントサイドの JavaScript がブラウザとやり取りするためです。歩数のブラウザについて をネットワークからデータを取得すると、なぜ Navigation のような API が プリロードが開発されました次回の投稿では、ブラウザが Google のサーバーをどのように評価し、 ページをレンダリングする HTML/CSS/JavaScript。
投稿はいかがでしたか?今後の投稿についてご不明な点やご意見がございましたら、 ご意見は、以下のコメント欄または Twitter の @kosamari からお寄せください。
<ph type="x-smartling-placeholder"></ph> 次へ: レンダラ プロセスの内部の仕組み