すばやく読み込まれるウェブサイトを構築するための最初のステップは、ページの HTML に対するレスポンスをサーバーからタイムリーに受け取ることです。ブラウザのアドレスバーに URL を入力すると、ブラウザはサーバーに GET リクエストを送信して URL を取得します。ウェブページの最初のリクエストは、HTML リソースをリクエストします。HTML が遅延を最小限に抑えてすばやく到着できるようにすることは、重要なパフォーマンス目標です。
この HTML の最初のリクエストはいくつかのステップを通り、各ステップに時間がかかります。各ステップに要する時間を短縮すると、最初のバイトまでの時間（TTFB）が短縮されます。ページの読み込み速度に関して重視すべき指標は TTFB だけではありませんが、TTFB が高いと、Largest Contentful Paint（LCP）や First Contentful Paint（FCP）などの指標の「良好」なしきい値に達することが困難になります。
リダイレクトの回数を減らす
リソースがリクエストされると、サーバーは永続的なリダイレクト（301 Moved Permanently レスポンス）または一時的なリダイレクト（302 Found レスポンス）のいずれかでリダイレクトで応答します。
リダイレクトを行うと、ブラウザが新しい場所で追加の HTTP リクエストを行ってリソースを取得する必要があるため、ページの読み込み速度が低下します。リダイレクトには次の 2 種類があります。
- 元のページ全体で発生する同一オリジンのリダイレクト。リダイレクトを管理するロジックはウェブサーバー上に存在するため、このようなリダイレクトはユーザーが完全に制御できます。
- 別のオリジンによって開始されたクロスオリジン リダイレクト。通常、このようなタイプのリダイレクトは制御できません。
クロスオリジン リダイレクトは、広告、URL 短縮サービス、その他のサードパーティ サービスでよく使用されます。クロスオリジン リダイレクトは自分では管理できませんが、複数のリダイレクトを避ける必要はあります。たとえば、リンク先が HTTP ページにリンクしていて HTTPS の同等のページにリダイレクトすることや、クロスオリジン リダイレクトが元のページに到達した後、同じオリジンのリダイレクトをトリガーすることなどです。
HTML レスポンスをキャッシュに保存する
HTML レスポンスのキャッシュは困難です。レスポンスには、他の重要なリソース（CSS、JavaScript、画像、その他のリソースタイプなど）へのリンクが含まれることがあるためです。これらのリソースのファイル名には、ファイルの内容に応じて変化する一意のフィンガープリントが含まれる場合があります。つまり、デプロイ後にキャッシュされた HTML ドキュメントが古くなる可能性があります。古くなったサブリソースへの参照が含まれるためです。
ただし、キャッシュ保存がないよりもキャッシュの有効期間が短いと、CDN でリソースをキャッシュに保存できる、送信元サーバーから提供されるリクエストの数が削減される、ブラウザでリソースを再検証せずに再検証できるなどのメリットがあります。この方法は、コンテキストが変化しない静的コンテンツに最適です。また、リソースをキャッシュに保存する適切な時間を、適切と思われる数分に設定できます。静的 HTML リソースは 5 分間確保しておくのが賢明であり、定期的な更新が気に入らないようにすることができます。
ページの HTML コンテンツがなんらかの方法で（認証されたユーザーのために）パーソナライズされている場合、セキュリティや鮮度などのさまざまな懸念からコンテンツをまったくキャッシュに保存することは望ましくありません。HTML レスポンスがユーザーのブラウザによってキャッシュに保存されると、そのキャッシュを無効にすることはできません。したがって、このような場合、HTML を完全にキャッシュに保存しないことをおすすめします。
HTML をキャッシュに保存する際は、ETag または Last-Modified レスポンス ヘッダーを使用することをおすすめします。ETag（エンティティ タグとも呼ばれます）ヘッダーは、リクエストされたリソースを一意に表す識別子で、多くの場合、リソースのコンテンツのハッシュが使用されます。
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
リソースが変更されるたびに、新しい ETag 値を生成する必要があります。後続のリクエストでは、ブラウザは If-None-Match リクエスト ヘッダーを介して ETag 値を送信します。サーバー上の ETag がブラウザから送信されたものと一致すると、サーバーは 304 Not Modified レスポンスで応答し、ブラウザはキャッシュのリソースを使用します。これによりネットワーク レイテンシが発生しますが、304 Not Modified レスポンスは HTML リソース全体よりもはるかに小さくなります。
ただし、リソースの更新頻度の再検証に伴うネットワーク レイテンシには、やはりデメリットがあります。ウェブ開発における他の多くの側面と同様に、トレードオフや妥協は避けられません。この方法で HTML をキャッシュする作業に見合うだけの価値があるのか、HTML コンテンツをまったくキャッシュせずに安全に保管しておくのが最善なのかは、ご自身の判断で判断できます。
サーバーの応答時間を測定する
レスポンスがキャッシュに保存されていない場合、サーバーのレスポンス時間は、ホスティング プロバイダとバックエンド アプリケーション スタックに大きく依存します。たとえば、データベースからデータを取得するなど、動的に生成されるレスポンスを提供するウェブページは、バックエンドでのコンピューティング時間がそれほど長くなくすぐに配信される静的ウェブページよりも TTFB が高くなる可能性があります。読み込みスピナーを表示し、クライアント サイドですべてのデータを取得すると、より予測しやすいサーバーサイド環境から、予測不可能なクライアント サイド環境に移行できます。通常、クライアントサイドの作業を最小限に抑えることで、ユーザー中心の指標が改善されます。
フィールドでの TTFB が遅い場合は、Server-Timing レスポンス ヘッダーを使用して、サーバーで時間がかかった場所に関する情報を表示できます。
Server-Timing: auth;dur=55.5, db;dur=220
Server-Timing ヘッダーの値には、複数の指標とそれぞれの期間を含めることができます。その後、Navigation Timing API を使用して現場のユーザーからデータを収集し、分析してユーザーに遅延がないかを確認できます。上記のコード スニペットでは、レスポンス ヘッダーに 2 つのタイミングが含まれています。
- ユーザーの認証時間（
auth）。55.5 ミリ秒かかりました。 - データベース アクセス時間（
db）。所要時間は 220 ミリ秒です。
また、ホスティング インフラストラクチャを見直し、ウェブサイトが受信するトラフィックを処理するのに十分なリソースがあることを確認することもおすすめします。共有ホスティング プロバイダは、高い TTFB の影響を受けることが多く、より高速なレスポンス時間を提供する専用ソリューションはコストが高くなる場合があります。
圧縮
HTML、JavaScript、CSS、SVG 画像などのテキストベースのレスポンスは、圧縮してネットワーク経由の転送サイズを小さくし、ダウンロード時間を短縮する必要があります。最も広く使用されている圧縮アルゴリズムは、gzip と Brotli です。Brotli では、gzip よりも約 15 ～ 20% 改善されています。
ほとんどのウェブ ホスティング プロバイダでは、多くの場合、圧縮が自動的に設定されますが、圧縮設定をご自身で構成または調整できる場合は、次の点に注意してください。
- 可能な場合は Brotli を使用する。前述のように、Brotli は gzip よりもかなり改善されており、Brotli はすべての主要なブラウザでサポートされています。可能であれば Brotli を使用します。ただし、多くのユーザーが従来のブラウザでウェブサイトを使用している場合は、代わりに gzip を使用するようにしてください。これは、圧縮しないよりは圧縮した方がよいためです。
- ファイルサイズは重要です。1 KiB 未満の非常に小さいリソースは、圧縮率があまり高くないか、まったく圧縮されないこともあります。どのタイプのデータ圧縮も、圧縮可能なビット量を見つけるために圧縮アルゴリズムが処理できるデータ量が大量に存在するかどうかに左右されます。ファイルが大きければ大きいほど、圧縮率は高くなります。ただし、圧縮効率が上がるという理由だけで、それほど大きなリソースを用意しないでください。JavaScript や CSS などのサイズの大きいリソースの場合、ブラウザによる解凍後の解析と評価に時間がかかります。また、変更によってファイル ハッシュが異なるため、わずかな変更でも頻繁に変更される場合があります。
- 動的圧縮と静的圧縮の違いを理解する動的圧縮と静的圧縮では、リソースを圧縮するタイミングが異なります。動的圧縮では、リソースがリクエストされたとき、場合によってはリクエストがリクエストされるたびに圧縮されます。一方、静的圧縮はファイルを事前に圧縮するため、リクエスト時に圧縮を行う必要はありません。静的圧縮では、圧縮自体によるレイテンシが除去されるため、動的圧縮の場合、サーバーのレスポンス時間が長くなる可能性があります。静的リソース（JavaScript、CSS、SVG 画像など）は静的に圧縮されるべきですが、HTML リソース（特に認証済みユーザー向けに動的に生成されている場合）は動的に圧縮される必要があります。
自分で圧縮を行うのは困難であり、多くの場合、次のセクションで説明するコンテンツ配信ネットワーク（CDN）で処理することをおすすめします。ただし、こうしたコンセプトを知ることで、ホスティング プロバイダが圧縮を適切に使用しているかどうかを見分け、改善の機会を見つけるのに役立ちます。
コンテンツ配信ネットワーク（CDN）
コンテンツ配信ネットワーク（CDN）は、配信元サーバーのリソースをキャッシュに保存し、物理的に近いエッジサーバーからリソースを提供する、サーバーの分散ネットワークです。ユーザーと物理的に距離を置くことでラウンド トリップ時間（RTT）が短縮され、HTTP/2 や HTTP/3、キャッシュ、圧縮などの最適化により、CDN は配信元サーバーから取得する場合よりも迅速にコンテンツを配信できます。CDN を利用すると、場合によってはウェブサイトの TTFB を大幅に改善できます。
知識を試す
完全に管理できるリダイレクトのタイプは何ですか。
Server-Timing ヘッダーには複数の指標を含めることができます。
エンドユーザーに物理的に最も近い可能性があるのは、どのタイプのサーバーか。
次のトピック: クリティカル パスについて
ウェブサイトの HTML のパフォーマンスに関するいくつかの考慮事項についてご理解いただけたところで、できるだけ早く読み込みができることを確認しました。しかし、これはウェブ パフォーマンスの学びの始まりにすぎません。次は、クリティカル レンダリング パスの背後にある理論について説明します。このモジュールでは、レンダリング ブロック リソースと解析ブロック リソースなどの主要なコンセプトと、ブラウザでページの最初のレンダリングを可能な限り迅速に行ううえでそれらが果たす役割について説明します。