ブラウザレンダリングを徹底解剖【Download編】

動画クリエーター兼コーダーの川島です。

この記事では、以前執筆したブラウザレンダリングの処理フローにおけるDonwload処理の詳細を知ることができます。

ブラウザレンダリングの概要については過去記事の『ブラウザレンダリングの仕組みを理解し、Webサイトのパフォーマンス向上を目指す』を参照ください。

Loadingフェイズで行われていること

上図のように、Loadingフェイズではふたつの処理が行われています。

それは、「Download」処理と「Parse」処理です。

Downloadフェイズとは、サーバーからデータをダウンロードしてくるフェイズ、

Parseフェイズとは、Downlodフェイズの次に訪れるフェイズで、コードを解析し、DOMツリーと　CSSOMツリーへ変換するフェイズです。

今回は、ブラウザレンダリングにとって1/8フェイズにあたるDownloadフェイズについて詳しく見ていきます。

Downloadの処理フロー

先述したように、このフェイズはサーバーからデータをダウンロードしてくるフェイズです。

具体的にはどのような処理フローを経てデータをダウンロードしてきているのでしょうか。下図は、その処理フローを示したものです。

1. リクエストの生成

ユーザーエージェント（通常はウェブブラウザ）がユーザーのアクション（URL入力、リンククリック、フォーム送信等）に基づいてHTTPリクエストを生成します。このリクエストには、リクエストメソッド（GET、POSTなど）、ヘッダー（追加の情報を含む）、場合によってはボディ（データを含むPOSTリクエストなど）が含まれます。

ブラウザは入力されたURIを解析して、プロトコル（例：http、https）、ホスト名（ドメイン名）、パス、クエリパラメータなどのコンポーネントを特定します。URIとは、URLを含んだ、リソースがどこに存在するかを示す文字列です。

2. DNS（Domain Name System）ルックアップ

URIの解析が完了すると、次にブラウザは、OSへIPアドレスの要求を行います。

そして、OSは指定されたドメイン名をIPアドレスに変換するため、DNSサーバーへ問い合わせを行います。このプロセスをDNSルックアップと呼びます。

まずDNSキャッシュがチェックされます。キャッシュが存在しない場合、DNSサーバーへと問い合わせが行われ、ドメインはIPアドレスへと変換されます。

3. ウェブサーバーとの接続を確立（TCP接続）

DNSルックアップが完了すると、ブラウザは得られたIPアドレスに基づいてウェブサーバーに接続を試みます。HTTPSを使用している場合、この段階でTLS※1ハンドシェイクも行われ、セキュアな接続が確立されます。

これをTCP（Transmission Control Protocol）接続※2と呼びます。

※1：TLS（Transport Layer Security）とは、インターネット上でデータを安全に送受信するためのプロトコルであり、暗号化ハンドシェイクとは、クライアント（例えばウェブブラウザ）とサーバー間でセキュアな通信チャネルを確立するプロセスです。このハンドシェイクは、通信を開始する前に行われます。

※2：TCP接続とは、ユーザーがブラウザを通じてウェブサイトにアクセスしようとすると、まずブラウザはウェブサーバーとの間でTCPコネクションを確立します。このステップは、データの送受信を行うための安定した通信チャネルを確立するために必要です。TCP（Transmission Control Protocol）は、インターネット上でデータを信頼性高く、順序正しく送受信するための基礎的なプロトコルです。

4. リソースのダウンロード

接続が確立されると、サーバーはブラウザのHTTPリクエストに応じて、HTMLレスポンスを送信（ダウンロード）します。ブラウザは受信したレスポンスを解析し始め、HTML内で参照されている外部リソース（CSS、JavaScript、画像ファイルなど）があれば、それらも順にダウンロードします。

上記のように、Downloadフェイズの工程は、主にリクエストとダウンロードから成り立っています。

リクエスト・ダウンロード処理工程でボトルネックとなり得る要素とその改善策を見ていきましょう。

リクエスト処理が重くなる原因と改善策

リクエスト処理が行われる最中、通信速度を低減させる要因として、どんなことが挙げられるでしょうか。また、それらの改善策はどのような方法が挙げられるでしょうか。

1. リクエストサイズが大きい

Cookieや長い認証トークンなど、HTTPリクエストヘッダー※が大きすぎると、リクエストの送信に余分な時間がかかります。

※HTTPリクエストヘッダーとは、クライアント（通常はウェブブラウザ）がサーバーに送るHTTPリクエストの一部で、例えばドメイン名やCookieなど、リクエストに関する追加情報を含んでいます。これらのヘッダーは、リクエストの性質を定義し、サーバーに対してクライアントの設定やリクエストされているリソースに関する特定の条件を伝えるために使用されます。

解決策

• ヘッダー情報の最適化：不必要なCookieの削減、認証トークンのサイズ最適化などにより、ヘッダーのサイズを減らします。
• リクエストの分割：必要に応じて、リクエストを複数に分割（例えば、データの遅延読み込み、非同期処理など）して送信することで、個々のリクエストサイズを小さく保ちます。

2. リクエストの複雑性

複雑なクエリパラメータ: GETリクエストのURLに多数のクエリパラメータが含まれている場合、URIの解析に余分な時間がかかることがあります。

解決策

• クエリパラメータの最適化: URLのクエリパラメータを簡潔に保ち、不必要なパラメータを削除します（URLを短縮する）。
• 効率的なAPI設計: APIのエンドポイント設計を見直し、データ取得に必要なパラメータのみを使用するようにします。

3. サーバー処理時間

サーバーサイドの処理: リクエストに対するサーバーサイドでの複雑な処理やデータベースのクエリが多いと、応答までの時間が長くなります。

解決策

• サーバーサイドの最適化: データベースクエリの最適化、キャッシュ導入、コードの効率化により、サーバー処理を高速化します。
• 非同期処理の活用: 可能な限り非同期処理を使用し、ブロッキングを避けることで応答性を向上させます。

4. サーバーとの通信方式

• HTTP/1.1の制限: HTTP/1.1では一度に1つのリクエストしか処理できないため、多数のリソースをリクエストすると、それぞれが順番に処理され、全体のレスポンスタイムが遅くなる可能性があります。
• HTTPSのオーバーヘッド: セキュアな通信を確立するためのTLSハンドシェイクには時間がかかります。これは、特に新しいTCP接続が必要な場合に顕著です。

解決策

• HTTP/2の採用: HTTP/2を利用することで、同時に複数のリクエストを処理できるようになり、ヘッダー圧縮によってオーバーヘッドを減らすことができます。
• TLSハンドシェイクの最適化: TLS 1.3の採用、セッション再利用などにより、セキュアな接続の確立時間を短縮します。

5. ネットワークの遅延

ラウンドトリップタイム（RTT）: リクエストがユーザーからサーバーへ送信され、応答がユーザーに戻ってくるまでの時間です。地理的な距離やネットワークの混雑状況によって、RTTが長くなることがあります。

解決策

• CDN（Content Delivery Network）の利用: ユーザーに近い地理的な場所からコンテンツを提供することで、通信距離を短縮し、RTTを減らします。
• 接続の最適化: ユーザーの接続速度に応じてコンテンツを動的に調整する、適応型ビットレートストリーミングなどの技術を活用します。

ダウンロード処理が重くなる原因と改善策

では、ダウンロード処理が行われる最中では、通信速度を低減させる要因として、どんなことが挙げられるでしょうか。また、それらの改善策はどのような方法が挙げられるでしょうか。

1. 大きなファイルサイズ

• 高解像度画像やビデオ: 高解像度の画像や長時間のビデオファイルはファイルサイズが大きく、ダウンロードに時間がかかります。
• 未圧縮のリソース: 圧縮されていないCSS、JavaScriptファイルや、最適化されていない画像ファイルは、ダウンロード時間を長くします。

解決策

• 画像やビデオの最適化: 高解像度の画像やビデオをウェブ用に最適化します。例えば、画像の解像度を下げる、適切なフォーマット（JPEG、WebPなど）を選択し、圧縮を行います。
• リソースの圧縮: CSSやJavaScriptファイルは、ミニファイ（不要な空白やコメントを削除）や圧縮ツールを使用してファイルサイズを減らします。

2. 多数のリクエスト

• 外部リソースへのリクエスト: 多くの小さなファイルを個別にリクエストすると、それぞれのHTTPリクエストに関連するオーバーヘッドが積み重なります。
• 第三者コンテンツ: 広告、トラッキングスクリプト、ソーシャルメディアの組み込みなど、第三者による多くの外部リクエストがページのロードを遅くします。

解決策

• リソースの結合: 複数のCSSやJavaScriptファイルを一つに結合して、リクエスト数を減らします。
• 外部リソースの使用を最小限に: 必要な外部リソースだけを使用し、不要なサードパーティコンテンツは削除または遅延読み込みにします。
• HTTP/2の利用: サーバーとクライアントがHTTP/2をサポートしている場合、マルチプレクシング機能により複数のリクエストを同時に送信できるため、ページの読み込みを高速化できます。

3. ネットワークの遅延

• 帯域幅の制限: ユーザーのインターネット接続速度が遅い場合、または高トラフィックによるネットワークの混雑が原因で、ダウンロード速度が低下します。
• 地理的距離: ユーザーとサーバー間の物理的な距離が遠いと、データの転送に時間がかかります。

解決策

• CDN（Content Delivery Network）の利用: コンテンツを地理的に分散したサーバーにキャッシュし、ユーザーに最も近いサーバーからコンテンツを提供することで、データ転送時間を短縮します。
• 適切なキャッシングポリシーの設定: CSS、JavaScript、画像ファイルなどの静的リソースに対して、ブラウザキャッシュを活用するように設定します。

4. サーバーの性能

サーバーの応答時間: サーバーの処理能力が不十分であったり、リソースが過負荷になっている場合、リクエストへの応答に遅れが生じます。

解決策

• サーバーのリソース強化: サーバーのCPUやメモリなどのリソースを増強し、処理能力を高めます。
• 負荷分散: ロードバランサー（複数のサーバーにわたってリクエストを分散させるデバイス/ソフトウェア）を使用して、リクエストを複数のサーバーに分散させ、単一のサーバーへの負荷を軽減します。
• キャッシュの活用: サーバー側で動的コンテンツのキャッシュを行い、同じリクエストに対してはキャッシュから迅速にレスポンスを返すようにします。
• 非同期処理の活用: データベースアクセスや外部API呼び出しなど、処理に時間がかかるタスクを非同期で行うことで、リクエストの処理速度を向上させます。

ダウンロードフェイズの高速化を目指すには

このように、適切な改善を行うことで、ウェブページやアプリケーションのダウンロード速度向上に貢献できます。

現在行われているリクエスト処理とダウンロード処理について、どこがボトルネックとなっているかの検証を行うことが重要です。