読み込みが速いウェブサイトを構築する最初のステップは、ページの HTML に対してサーバーからタイムリーなレスポンスを受け取ることです。ブラウザのアドレスバーに URL を入力すると、ブラウザは GET リクエストをサーバーに送信して URL を取得します。ウェブページの最初のリクエストは HTML リソースに対するものであり、HTML が最小限の遅延で迅速に届くようにすることが、パフォーマンスの重要な目標となります。
HTML の最初のリクエストは、いくつかのステップを経て処理されます。各ステップには時間がかかります。各ステップにかかる時間を短縮すると、Time to First Byte（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 レスポンスのキャッシュ保存は困難です。これらのリソースには、それぞれのファイル名に一意のフィンガープリントが含まれている場合があります。このフィンガープリントは、ファイルの内容に基づいて変化します。つまり、キャッシュに保存された HTML ドキュメントには古いサブリソースへの参照が含まれるため、デプロイ後に古いものになる可能性があります。
ただし、キャッシュ保存なしではなく、キャッシュの有効期間を短くすると、リソースを CDN でキャッシュ保存してオリジン サーバーから配信されるリクエスト数を減らしたり、ブラウザでリソースを再ダウンロードするのではなく再検証したりできるなどのメリットがあります。このアプローチは、コンテキストによって変化しない静的コンテンツに最適です。リソースをキャッシュに保存する適切な時間を、適切な分数に設定できます。静的 HTML リソースの場合は 5 分が安全な値であり、定期的な更新が認識されないことを防ぐことができます。
ページの内容が認証済みユーザー向けにパーソナライズされている場合など、さまざまな理由から、コンテンツをキャッシュに保存したくないことがよくあります。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 を使用しますが、ウェブサイトをレガシー ブラウザで多くのユーザーが使用している場合は、gzip がフォールバックとして使用されるようにしてください。圧縮なしよりも圧縮ありの方が優れています。
- ファイルサイズが重要です。非常に小さいリソース（1 KiB 未満）は、圧縮率が低くなるか、まったく圧縮されないことがあります。あらゆる種類のデータ圧縮の有効性は、圧縮アルゴリズムがより圧縮可能なデータのビットを見つけるために使用できる大量のデータがあるかどうかに依存します。ファイルが大きいほど圧縮の効果は高くなりますが、圧縮の効果を高めるためだけに非常に大きなリソースを配信しないでください。大きなリソース（JavaScript や CSS など）は、ブラウザで解凍された後、解析と評価に時間がかかります。また、わずかな変更でも、ファイル ハッシュが異なるため、頻繁に変更される可能性があります。
- 動的圧縮と静的圧縮の違いを理解します。動的圧縮と静的圧縮は、リソースを圧縮するタイミングに対するアプローチが異なります。動的圧縮では、リソースがリクエストされたときに圧縮されます。リクエストされるたびに圧縮されることもあります。一方、静的圧縮では、ファイルを事前に圧縮するため、リクエスト時に圧縮を行う必要はありません。静的圧縮では、圧縮自体に伴うレイテンシが解消されます。動的圧縮の場合、このレイテンシがサーバーのレスポンス時間に加算される可能性があります。JavaScript、CSS、SVG 画像などの静的リソースは静的に圧縮する必要があります。一方、HTML リソースは、特に認証済みユーザー向けに動的に生成される場合は、動的に圧縮する必要があります。
圧縮を適切に行うのは難しいため、次のセクションで説明するコンテンツ配信ネットワーク（CDN）に処理を任せるのが最善の方法です。ただし、これらのコンセプトを理解しておくと、ホスティング プロバイダが圧縮を適切に使用しているかどうかを判断するのに役立ちます。この知識は、圧縮設定を改善してウェブサイトに最大のメリットをもたらす機会を見つけるのに役立ちます。
コンテンツ配信ネットワーク（CDN）
コンテンツ配信ネットワーク（CDN）は、オリジン サーバーからリソースをキャッシュに保存し、ユーザーの近くにあるエッジサーバーからリソースを配信する分散型サーバー ネットワークです。ユーザーとの物理的な距離が短くなることで、ラウンド トリップ時間（RTT）が短縮されます。また、HTTP/2 や HTTP/3、キャッシュ保存、圧縮などの最適化により、CDN は配信元サーバーから取得する場合よりも迅速にコンテンツを配信できます。CDN を利用すると、場合によってはウェブサイトの TTFB を大幅に改善できます。
理解度テスト
完全に制御できるリダイレクトの種類は何ですか？
Server-Timing ヘッダーには複数の指標を含めることができます。
エンドユーザーに物理的に最も近いサーバーは、次のうちどれですか？
次へ: クリティカル パスについて
ウェブサイトの HTML に関連するパフォーマンスの考慮事項について理解できたので、ウェブサイトをできるだけ早く読み込めるようにする準備が整いました。しかし、これはウェブ パフォーマンスの学習の始まりにすぎません。次に、クリティカル レンダリング パスの背後にある理論について説明します。このモジュールでは、レンダリング ブロック リソースや解析ブロック リソースなどの重要なコンセプトと、ブラウザでページの初回レンダリングをできるだけ早く行ううえでそれらが果たす役割について説明します。