このページは Cloud Translation API によって翻訳されました。

最新のウェブブラウザの詳細（パート 2）

Mariko Kosaka

ナビの動作

これは、Chrome の内部の仕組みを紹介する 4 部構成のブログシリーズのパート 2 です。前回の投稿では、生成 AI とプロセスとスレッドがブラウザのさまざまな部分を処理します。今回の投稿ではウェブサイトを表示するために、各プロセスとスレッドが通信します。

ウェブブラウジングの簡単なユースケースを見てみましょう。ブラウザには URL を入力し、インターネットからデータを取得してページを表示します。この記事では、ユーザーがサイトをリクエストすると、ブラウザはページのレンダリング（ナビゲーション）の準備をします。

ブラウザプロセスから始まります

前のモジュールで説明したようにパート 1: CPU、GPU、メモリ、マルチプロセスアーキテクチャタブ以外の要素はすべてブラウザプロセスによって処理されます。ブラウザプロセスには、アプリのボタンや入力フィールドを描画する UI スレッドなど、ブラウザ、インターネットからデータを受信するネットワークスタックを扱うネットワークスレッド、ストレージスレッドのスレッドダンプがありますアドレスに URL を入力すると、入力はブラウザプロセスの UI スレッドによって処理されます。

シンプルなナビゲーション

ステップ 1: 入力を処理する

ユーザーがアドレスバーへの入力を開始すると、UI スレッドが最初に「これは（検索語句または URL）を見つけますChrome のアドレスバーは検索入力フィールドでもあるため、UI スレッドはで解析を行い、検索エンジンとリクエストしたサイトのどちらへ送るかを判断する必要があります。

ユーザー入力の処理 — </ph> 図 1: 入力が検索クエリと URL のどちらであるかを尋ねる UI スレッド

ステップ 2: ナビを開始する

ユーザーが Enter キーを押すと、UI スレッドがネットワーク呼び出しを開始してサイトコンテンツを取得します。読み込み中アイコン表示され、ネットワークスレッドは DNS ルックアップとリクエストの TLS 接続の確立。

ナビ開始 — </ph> 図 2: UI スレッドがネットワークスレッドと通信して families.com に移動している

この時点で、ネットワークスレッドは HTTP 301 などのサーバーリダイレクトヘッダーを受信することがあります。その場合はネットワークスレッドが、サーバーがリダイレクトを要求している UI スレッドと通信する。次に、別の URL リクエストが開始されます。

ステップ 3: レスポンスを読み取る

HTTP レスポンス — </ph> 図 3: Content-Type と実際のデータであるペイロードを含むレスポンスヘッダー

レスポンスの本文（ペイロード）の受信が開始されると、ネットワークスレッドが最初の数バイトを調べます。ストリームのコンテキストを追加します。レスポンスの Content-Type ヘッダーで、データの種類、欠落または誤りの可能性があるため MIME タイプスニッフィングここで行います。これは「厄介なビジネス」ソースコードのコメントのとおりです。このコメントを読むと、さまざまなブラウザでコンテンツタイプとペイロードのペアがどのように扱われるかがわかります。

レスポンスが HTML ファイルの場合は、次のステップとしてデータをレンダラに渡します。 ZIP ファイルなどのファイルの場合はダウンロードリクエストなので、ダウンロードマネージャーにデータを渡す必要があります。

MIME タイプスニッフィング — </ph> 図 4：応答データが安全なサイトからの HTML かどうかを尋ねるネットワークスレッド

ここでもSafeBrowsing チェックが行われます。ドメインと応答データが既知の悪意のあるサイトと一致しているように見える場合、ネットワークスレッドは警告ページが表示されます。また Cross Origin Read Blocking（CORB）機密性の高いクロスサイトセキュリティがデータはレンダラプロセスに送られません

ステップ 4: レンダラのプロセスを探す

すべてのチェックが完了し、ネットワークスレッドでブラウザがネットワークスレッドは UI スレッドに、データの準備ができたことを通知します。その後、UI スレッドが処理してウェブページのレンダリングを続行します。

レンダラのプロセスを検索 — </ph> 図 5: UI スレッドにレンダラプロセスを見つけるよう指示するネットワークスレッド

ネットワークリクエストからレスポンスが返されるまでに数百ミリ秒かかる場合があるため、最適化が適用されますUI スレッドが URL リクエストをどのサイトに移動するのかをすでに認識していますUI スレッドは、ネットワークリクエストと並行してレンダラプロセスをプロアクティブに検出または開始しようとします。このようにすべてが想定どおりに進むと、ネットワークスレッドが待機状態になったときに、レンダラプロセスはすでにスタンバイ状態になっています。受信します。このスタンバイプロセスは、ナビゲーションがクロスサイトリダイレクトを行う場合、その場合は別のプロセスが必要になることがあります

ステップ 5: ナビゲーションを commit する

データとレンダラプロセスの準備が整ったので、ブラウザプロセスからナビゲーションを commit します。また、データストリームを渡すため、レンダラは HTML データを受信し続けることができます。ブラウザプロセスが、commit がレンダリングプロセスが完了し、ナビゲーションが完了し、ドキュメントの読み込みフェーズが完了します。開始されます。

この時点でアドレスバーが更新され、セキュリティインジケーターとサイト設定の UI に新しいページのサイト情報を指定します。タブのセッション履歴が更新され、バックフォワード先ほど開いたサイト内を移動します。タブ/セッションの復元を容易にするためタブやウィンドウを閉じると、セッション履歴がディスクに保存されます。

ナビゲーションを commit する — </ph> 図 6: ページのレンダリングをリクエストするブラウザとレンダラプロセス間の IPC

追加のステップ: 初期読み込みの完了

ナビゲーションが commit されると、レンダラプロセスはリソースの読み込みを続けて、できます。この段階で行われる内容については、次の投稿で詳しく説明します。レンダラがプロセスを「完了」するブラウザプロセスに IPC を返送します（つまり、 onload イベントがページ内のすべてのフレームで発生し、実行を終了したことを示します）。この時点で UI スレッドがタブの読み込みスピナーを停止します。

私は「完了」と言います。クライアントサイドの JavaScript は依然として追加のリソースが作成され、この時点以降に新しいビューがレンダリングされます。

ページの読み込み完了 — </ph> 図 7: ページが「読み込まれた」ことを通知するために行われる、レンダラからブラウザプロセスへの IPC

別のサイトに移動する

これで簡単なナビゲーションが完了しました。ユーザーがアドレスバーに別の URL を入力した場合はどうなるかまた？ブラウザプロセスは同じステップを踏んで別のサイトに移動します。ただし、その前に、現在レンダリングされているサイトで、 beforeunload イベント。

beforeunload さんは「このサイトから移動しますか？」というメッセージを作成できます。タブを閉じようとしたときにアラートが表示されます。 JavaScript コードを含め、タブ内の要素はすべてレンダラプロセスによって処理されるため、新しいナビゲーションリクエストが届いたときに、ブラウザプロセスは現在のレンダラプロセスをチェックする必要があります。

注意: 無条件の beforeunload ハンドラを追加しないでください。レイテンシが増加します。これは、開始する前にハンドラを実行する必要があります。このイベントハンドラは、必要な場合にのみ追加する。たとえば、ユーザーが過去にさかのぼって使用したデータが失われる可能性があることを警告する必要がある場合表示されます。

beforeunload イベントハンドラ — </ph> 図 8: ブラウザプロセスからレンダラプロセスに送られてくる IPC 別のサイトに移動する

レンダラプロセスからナビゲーションが開始された場合（例: ユーザーがリンクをクリックした、クライアントサイドの JavaScript が window.location = "https://newsite.com" を実行した）最初に beforeunload ハンドラを確認します。その後、ブラウザプロセスと同じプロセスを経て開始されたナビゲーション唯一の違いは、ナビゲーションリクエストはブラウザプロセスに渡します。

新しいナビゲーションが現在レンダリングされているサイトとは異なるサイトに行われた場合、新しいナビゲーションを処理するために、現在のレンダリングプロセスを維持したまま、 unload などのイベントを処理する。詳しくは、ページのライフサイクルの状態の概要をご覧ください。イベントにフックする方法を Page Lifecycle API

新しいナビゲーションとアンロード — </ph> 図 9: ブラウザプロセスから新しいレンダラプロセスへの、ページのレンダリングを指示する 2 つの IPC 古いレンダラプロセスに対して

Service Worker の場合

このナビゲーションプロセスに加えられた最近の変更は Service WorkerService Worker は、アプリケーションコード内のネットワークプロキシ。ウェブデベロッパーは、ウェブデベロッパーがネットワークから新しいデータを取得するタイミングを決定できます。ページを読み込むように Service Worker が設定されている場合データをキャッシュから保存する場合は、ネットワークにデータをリクエストする必要はありません。

覚えておくべき重要な点は、Service Worker はレンダラで実行される JavaScript コードであるということです。プロセスですしかし、ナビゲーションリクエストが届いたとき、ブラウザプロセスはサイトにどうすればよいでしょうか。

Service Worker のスコープの検索 — </ph> 図 10: Service Worker のスコープを検索するブラウザプロセスのネットワークスレッド

Service Worker が登録されると、Service Worker のスコープが参照として保持（スコープについて詳しくは、 Service Worker のライフサイクルをご覧ください）。ナビゲーションが発生すると、ネットワークスレッドがドメインを登録済みの Service Worker と照合するその URL に Service Worker が登録されていれば、UI スレッドは呼び出す必要がありますService Worker がキャッシュからデータを読み込むことで、ネットワークにデータをリクエストする必要があるか、ネットワークに新しいリソースをリクエストする可能性があります。

ServiceWorker のナビゲーション — </ph> 図 11: ブラウザプロセスの UI スレッドがレンダラプロセスを開始してサービスを処理労働者レンダラプロセスのワーカースレッドがネットワークからデータをリクエスト

ナビゲーションのプリロード

ブラウザプロセスとレンダラプロセスの間のこのラウンドトリップにより、遅延が発生する可能性があります。 Service Worker が最終的にネットワークからデータをリクエストした場合。ナビゲーションプリロードは、これを高速化するメカニズムです。 Service Worker の起動と並行してリソースを読み込み、これらのリクエストにヘッダーのマークを付け、サーバーはそれに基づいてさまざまなコンテンツを送信するかどうかを決定し、これらのリクエストドキュメント全体ではなくデータを更新した場合などです

ナビゲーションのプリロード — </ph> 図 12: ブラウザプロセスの UI スレッドがレンダラプロセスを開始してサービスを処理するネットワークリクエストを並行して開始し、

まとめ

今回の投稿では、ナビゲーション中に行われる処理と、そのようなウェブアプリケーションのコードがどのように動作するかを見てきました。レスポンスヘッダーとクライアントサイドの JavaScript がブラウザとやり取りするためです。歩数のブラウザについてをネットワークからデータを取得すると、なぜ Navigation のような API がプリロードが開発されました次回の投稿では、ブラウザが Google のサーバーをどのように評価し、ページをレンダリングする HTML/CSS/JavaScript。

投稿はいかがでしたか？今後の投稿についてご不明な点やご意見がございましたら、ご意見は、以下のコメント欄または Twitter の @kosamari からお寄せください。

<ph type="x-smartling-placeholder"></ph> 次へ: レンダラプロセスの内部の仕組み