最初のバイトまでの時間を最適化する

Time to First Byte 指標を最適化する方法を学習します。

Jeremy Wagner
Barry Pollard

Time to First Byte（TTFB）は、他のあらゆる意味のあるユーザー エクスペリエンス指標（First Contentful Paint（FCP）や Largest Contentful Paint（LCP））に先行する基本的なウェブ パフォーマンス指標です。つまり、TTFB の値が大きくなると、その後の指標に時間が長くなります。

ユーザーの 75 パーセンタイルが「良好」のしきい値内の FCP を体験できるように、サーバーがナビゲーション リクエストに迅速に応答できるようにすることをおすすめします。大まかに言えば、ほとんどのサイトでは TTFB を 0.8 秒以下にするよう努力する必要があります。

良好な TTFB 値は 0.8 秒以下、不良値は 1.8 秒を超え、その間はすべて改善が必要

TTFB の測定方法

TTFB を最適化する前に、それがウェブサイトのユーザーに及ぼす影響をモニタリングする必要があります。TTFB はリダイレクトの影響を受けるため、主なソースとしてフィールド データを利用する必要がありますが、ラボベースのツールは最終ページ URL を使用して測定することが多いため、この余分な遅延を回避できます。

PageSpeed Insights を使用すると、Chrome ユーザー エクスペリエンス レポートに掲載されている一般公開ウェブサイトのフィールドとラボの両方の情報を簡単に取得できます。

実際のユーザーの TTFB は、上部の [実際のユーザー エクスペリエンスを把握する] セクションに表示されます。

PageSpeed Insights の実際のユーザーデータ

TTFB のサブセットは、サーバー応答時間の監査に表示されます。

サーバー応答時間の監査

現場とラボの両方で TTFB を測定するその他の方法については、TTFB 指標のページをご覧ください。

Server-Timing で TTFB が高いことについて

Server-Timing レスポンス ヘッダーをアプリケーション バックエンドで使用すると、高レイテンシの原因となる可能性のある個別のバックエンド プロセスを測定できます。ヘッダー値の構造は柔軟であり、少なくともユーザーが定義したハンドルを受け入れます。オプションの値には、期間の値（dur を使用）と、人が読める形式の説明（desc を使用）が含まれます。

Serving-Timing を使用すると多くのアプリケーション バックエンド プロセスを測定できますが、特に注意すべき点がいくつかあります。

  • データベース クエリ
  • サーバーサイド レンダリング時間（該当する場合）
  • ディスクシーク
  • エッジサーバーのキャッシュのヒット/ミス（CDN を使用している場合）

Server-Timing エントリのすべての部分はコロンで区切られます。複数のエントリはカンマで区切ることができます。

// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

このヘッダーは、アプリケーション バックエンドの任意の言語を使用して設定できます。たとえば PHP では、ヘッダーを次のように設定できます。

<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);

// Perform a database query and get results...
// ...

// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);

// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStarTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

このヘッダーを設定すると、ラボとフィールドの両方で使用できる情報が表示されます。

このフィールドでは、Server-Timing レスポンス ヘッダーが設定されたすべてのページで、Navigation Timing API の serverTiming プロパティに値が入力されます。

// Get the serverTiming entry for the first navigation request:
performance.getEntries("navigation")[0].serverTiming.forEach(entry => {
    // Log the server timing data:
    console.log(entry.name, entry.description, entry.duration);
});

ラボでは、Server-Timing レスポンス ヘッダーのデータが Chrome DevTools の [Network] タブのタイミング パネルに表示されます。

Chrome DevTools の [Network] タブでの Server-Timing ヘッダーの値の可視化。この図の Server-Timing ヘッダーの値は、CDN エッジサーバーでキャッシュ ヒットまたはキャッシュミスが発生したかどうかと、エッジと配信元サーバーからリソースを取得する時間を測定しています。

Chrome DevTools の [Network] タブで可視化された Server-Timing レスポンス ヘッダー。ここでは、Server-Timing を使用して、リソースに対するリクエストが CDN キャッシュにヒットしたかどうかと、リクエストが CDN のエッジサーバーに到達してから送信元に到達するまでにかかる時間を測定しています。

利用可能なデータを分析して、問題のある TTFB があると判断したら、問題の修正に進むことができます。

TTFB の最適化方法

TTFB の最適化で最も困難な点は、ウェブのフロントエンド スタックは常に HTML、CSS、JavaScript である一方、バックエンド スタックは大きく異なるということです。多数のバックエンド スタックやデータベース プロダクトがあり、それぞれが独自の最適化手法を持っています。したがって、このガイドでは、スタック固有のガイダンスのみに焦点を当てるのではなく、ほとんどのアーキテクチャに適用されるものに焦点を当てます。

プラットフォーム固有のガイダンス

ウェブサイトに使用するプラットフォームは、TTFB に大きく影響する可能性があります。たとえば、WordPress のパフォーマンスは、プラグインの数と品質、または使用されているテーマの影響を受けます。プラットフォームをカスタマイズすると、他のプラットフォームも同様に影響を受けます。この記事で紹介するパフォーマンスに関する一般的なアドバイスを補足するには、お使いのプラットフォームのドキュメントでベンダー固有のアドバイスを参照してください。Lighthouse の監査では、サーバーの応答時間を短縮するための監査にも限定的なスタック固有のガイダンスが含まれています。

ホスティング、ホスティング

他の最適化アプローチを検討する前に、まずホスティングについて検討する必要があります。具体的なガイダンスについてはあまり説明できませんが、一般的な経験則として、ウェブサイトのホストが、送信したトラフィックを処理できることを確認する必要があります。

一般に、共有ホスティングは遅くなります。主に静的ファイルを提供する小規模な個人ウェブサイトを運営している場合は、おそらくこれで問題ありません。後述する最適化手法を使用して、TTFB を可能な限り短縮できます。

ただし、パーソナライズ、データベース クエリ、その他のサーバー側の集中的なオペレーションを伴う、多数のユーザーが関与する大規模なアプリケーションを実行している場合は、フィールドの TTFB を小さくするために、ホスティングの選択が重要になります。

ホスティング プロバイダを選ぶ際には、次の点を考慮してください。

  • アプリケーション インスタンスに割り当てられているメモリ量はどれくらいですか。アプリケーションのメモリが不足していると、スラッシングが発生し、ページをできるだけ速く表示することが難しくなります。
  • ホスティング プロバイダはバックエンド スタックを最新の状態に保っていますか？新しいバージョンのアプリケーション バックエンド言語、HTTP 実装、データベース ソフトウェアがリリースされると、それらのソフトウェアのパフォーマンスは徐々に向上していきます。このような重要なメンテナンスを優先するホスティング プロバイダと提携することが重要です。
  • 特定のアプリケーション要件があり、サーバー構成ファイルへの最下位レベルのアクセスが必要な場合は、独自のアプリケーション インスタンスのバックエンドをカスタマイズする意味があるかを尋ねてください。

こうした処理を行うホスティング プロバイダは多数存在しますが、専用のホスティング プロバイダでも長い TTFB 値が見られる場合は、可能な限り最高のユーザー エクスペリエンスを提供できるように、現在のホスティング プロバイダの機能を再評価する必要があるかもしれません。

コンテンツ配信ネットワーク（CDN）を使用する

「CDN の使用状況」というトピックは馴染みのあるものですが、アプリケーション バックエンドを高度に最適化することは可能ですが、配信元サーバーから遠くにいるユーザーの TTFB が大きくなる可能性があります。

CDN は、サーバーの分散ネットワークを使用して、物理的にユーザーに近いサーバーにリソースをキャッシュすることで、送信元サーバーからのユーザー近さの問題を解決します。これらのサーバーはエッジサーバーと呼ばれます。

CDN プロバイダは、エッジサーバー以外にも次のようなメリットをもたらします。

  • CDN プロバイダは通常、DNS の解決時間を大幅に短縮します。
  • CDN は、HTTP/2 や HTTP/3 などの最新のプロトコルを使用して、エッジサーバーからコンテンツを提供する可能性があります。
  • 特に HTTP/3 は、UDP プロトコルを使用することで、HTTP/2 が依存する TCP に内在するヘッドオブライン ブロッキングの問題を解決します。
  • CDN は、TLS の最新バージョンも提供し、TLS ネゴシエーション時間に関連するレイテンシを短縮できる可能性があります。特に、TLS 1.3 は TLS ネゴシエーションをできるだけ短くするように設計されています。
  • 一部の CDN プロバイダは「エッジワーカー」と呼ばれる機能を提供しています。この機能は、Service Worker API に似た API を使用してリクエストをインターセプトし、エッジ キャッシュ内のレスポンスをプログラムで管理し、レスポンス全体を書き換えます。
  • CDN プロバイダは、圧縮の最適化に非常に優れています。圧縮は、そのままではうまくいきません。動的に生成されたマークアップはその場で圧縮する必要があるため、場合によっては応答時間が遅くなる可能性があります。
  • また、CDN プロバイダは静的リソースの圧縮されたレスポンスを自動的にキャッシュに保存するため、圧縮率とレスポンス時間の最適なバランスを実現できます。

CDN の導入には、簡単なものから大規模なものまで、さまざまな労力が伴いますが、ウェブサイトでまだ TTFB を使用していない場合は、TTFB の最適化に取り組むことが最優先となります。

可能な場合はキャッシュに保存されたコンテンツを使用する

CDN を使用すると、コンテンツが適切な Cache-Control HTTP ヘッダーで構成されている場合、物理的に訪問者に近い場所にあるエッジサーバーで、コンテンツをキャッシュに保存できます。これはパーソナライズされたコンテンツには適していませんが、送信元まで戻る必要があると、CDN の価値の多くが否定されてしまう可能性があります。

コンテンツを頻繁に更新するサイトでは、キャッシュ時間が短い場合でも、ビジー状態のサイトのパフォーマンスが顕著に向上する可能性があります。これは、その間の最初の訪問者のみが配信元サーバーへの完全なレイテンシを受け、他のすべての訪問者はエッジサーバーからキャッシュされたリソースを再利用できるためです。一部の CDN では、サイトのリリース時にキャッシュを無効化できるため、キャッシュ時間が長くても、必要に応じて即座に更新できるという、両方の長所を活かすことができます。

キャッシュ保存が正しく設定されていても、分析測定には一意のクエリ文字列パラメータが使用されるため、この動作は無視できます。これらは同じでも CDN では別のコンテンツのように見える場合があるため、キャッシュされたバージョンは使用されません。

古いコンテンツやアクセス頻度の低いコンテンツもキャッシュされないことがあるため、一部のページで他のページよりも TTFB の値が大きくなる可能性があります。キャッシュ時間を増やすと影響を軽減できますが、キャッシュ時間が長くなると古いコンテンツが提供される可能性が高くなるので注意してください。

キャッシュに保存されたコンテンツの影響は、CDN を使用するユーザーだけに影響するものではありません。キャッシュされたコンテンツを再利用できない場合、サーバー インフラストラクチャでは、コストのかかるデータベース ルックアップからコンテンツを生成しなければならない場合があります。アクセス頻度が高いデータや事前キャッシュしたページのほうが、パフォーマンスが向上することがよくあります。

複数のページ リダイレクトを回避する

TTFB が長くなる原因の 1 つに、リダイレクトがあります。リダイレクトは、ドキュメントのナビゲーション リクエストで、リソースが別の場所に存在することをブラウザに知らせるレスポンスを受け取った場合に発生します。あるリダイレクトによって、ナビゲーション リクエストに不要なレイテンシが加わることは確かですが、そのリダイレクトが別のリソースにリダイレクトされ、その結果、さらに別のリダイレクトが発生すると、状況は悪化する可能性があります。これは、広告やニュースレターから大量の訪問者がいるサイトは、分析サービス経由で測定目的でリダイレクトすることが多いため、特に影響を受けます。直接制御下にあるリダイレクトをなくすことで、適切な TTFB を実現できます。

リダイレクトには次の 2 種類があります。

  • 同一オリジン リダイレクト: リダイレクト全体がウェブサイト上で行われます。
  • クロスオリジン リダイレクト: ウェブサイトに到達する前に、最初に別のオリジン（ソーシャル メディアの URL 短縮サービスなど）でリダイレクトが行われます。

同一オリジンのリダイレクトは直接制御できるため、排除に注力する必要があります。これには、ウェブサイト上のリンクをチェックし、302 または 301 のレスポンス コードが返されるかどうかを確認します。多くの場合、https:// スキームが含まれていない（ブラウザはデフォルトで http:// に設定され、その後リダイレクトされる）か、末尾のスラッシュが URL に適切に含まれていないか、除外されていないことが原因である可能性があります。

クロスオリジン リダイレクトは自分で管理できないことが多いため、やや複雑ですが、可能であれば複数のリダイレクトは避けてください。たとえば、リンクを共有するときに複数の短縮リンクを使用するなどです。広告主様やニュースレターに指定する URL が、該当のサービスで使用されている URL への別のリダイレクトを追加しないように、正しい最終ページ URL であることを確認します。

リダイレクト時間のもう 1 つの重要な原因は、HTTP から HTTPS へのリダイレクトです。この問題を回避する 1 つの方法は、Strict-Transport-Security ヘッダー（HSTS）を使用することです。これにより、オリジンへの初回アクセス時に HTTPS が適用され、次回アクセス時には HTTPS スキームを介してオリジンに即座にアクセスするようブラウザに指示します。

適切な HSTS ポリシーを設定すると、サイトを HSTS プリロード リストに追加することで、オリジンへの初回アクセス時の処理をスピードアップできます。

マークアップをブラウザにストリーミングする

ブラウザは、マークアップのストリーミング時に効率的に処理できるように最適化されています。つまり、マークアップがサーバーから到着するとチャンクで処理されます。これは、大規模なマークアップ ペイロードに関係する場合、非常に重要なことです。ブラウザは、レスポンス全体の到着を待たずに解析を開始するのではなく、マークアップのチャンクを段階的に解析できるということです。

ブラウザはストリーミング マークアップを処理するのに優れていますが、そのストリームの流れを維持して、マークアップの最初の部分ができるだけ早く届くようにするためにできることをすべて行うことが重要です。バックエンドで処理が妨げられている場合は、問題となります。バックエンド スタックは数多くあるため、すべてのスタックと、スタックごとに発生する可能性のある問題を取り上げることは、このガイドの範囲外です。

たとえば、React や、サーバー上でオンデマンドでマークアップをレンダリングできる他のフレームワークでは、サーバーサイド レンダリングに同期アプローチを採用してきました。ただし、新しいバージョンの React では、レンダリング時にストリーミング マークアップ用のサーバー メソッドが実装されています。つまり、React サーバーの API メソッドでレスポンス全体がレンダリングされるのを待たずに送信することができます。

マークアップがブラウザにすばやくストリーミングされるようにするもう 1 つの方法は、ビルド時に HTML ファイルを生成する静的レンダリングを利用することです。ファイル全体が即座に利用可能になることで、ウェブサーバーはすぐにファイルの送信を開始できます。また、HTTP の本質的な性質により、ストリーミング マークアップが生成されます。このアプローチは、すべてのウェブサイトのすべてのページ（ユーザー エクスペリエンスの一部として動的なレスポンスを必要とするページなど）に適しているわけではありませんが、マークアップを必要としないページで特定のユーザー向けにパーソナライズすることには有益です。

Service Worker を使用する

Service Worker API は、ドキュメントとそれらによって読み込まれるリソースの両方の TTFB に大きな影響を与える可能性があります。これは、Service Worker がブラウザとサーバー間のプロキシとして機能するためです。ただし、ウェブサイトの TTFB に影響するかどうかは、Service Worker の設定方法と、その設定がアプリケーションの要件に沿っているかどうかによって決まります。

  • アセットに stale-while-revalidate 戦略を使用する。アセットが Service Worker のキャッシュにある場合（ドキュメントに必要なリソースでも、ドキュメントでもリソースでも）、stale-while-revalidate 戦略では、まずキャッシュからそのリソースを処理します。次に、そのアセットをバックグラウンドでダウンロードし、今後の操作のためにキャッシュから配信します。
    • 頻繁に変更されないドキュメント リソースがある場合、古い再検証戦略を使用すると、ページの TTFB がほぼ瞬時に作成されることがあります。ただし、動的に生成されたマークアップ（ユーザーが認証されたかどうかに応じて変化するマークアップなど）をウェブサイトから送信する場合には、これはうまく機能しません。このような場合、ドキュメントができるだけ新しいものになるように、常に最初にネットワークにアクセスする必要があります。
    • 一定の頻度で変更される重要性の低いリソースをドキュメントが読み込み、古いリソースを取得してもユーザー エクスペリエンスに大きく影響しない（一部の画像やその他の重要ではないリソースなど）場合は、古い再検証戦略を使用することで、それらのリソースの TTFB を大幅に削減できます。
  • 可能であれば、ストリーミング Service Worker アーキテクチャを使用します。この Service Worker アーキテクチャでは、ドキュメント リソースの一部が Service Worker のキャッシュに保存され、ナビゲーション リクエスト時にコンテンツの部分と組み合わされるアプローチが使用されます。この Service Worker パターンを使用すると、ナビゲーションが高速になりますが、ネットワークからダウンロードされる HTML ペイロードは小さくなります。この Service Worker パターンはすべてのウェブサイトで利用できるわけではありませんが、ドキュメント リソースの TTFB 時間は、それを使用できるサイトであればほぼ瞬時に実現できます。
  • クライアントがレンダリングするアプリケーションには App Shell モデルを使用します。このモデルは、ページの「シェル」を Service Worker のキャッシュから瞬時に配信でき、ページの動的コンテンツがページのライフサイクルで後から入力、レンダリングされる SPA に最適です。

レンダリングに不可欠なリソースには 103 Early Hints を使用する

アプリケーション バックエンドがどれだけ適切に最適化されていても、レスポンスの準備のためにサーバーで多大な作業が必要になる可能性があります。たとえば、ナビゲーション レスポンスができるだけ早く到着するのを遅らせる高価な（ただし必要である）データベース作業などが挙げられます。これにより、クライアントでマークアップをレンダリングする CSS や、場合によっては JavaScript など、レンダリングに不可欠な後続のリソースが遅延する可能性があります。

103 Early Hints ヘッダーは、バックエンドがマークアップの準備でビジー状態のときにサーバーがブラウザに送信できる早期レスポンス コードです。このヘッダーを使用すると、マークアップの準備中にページからダウンロードを開始する必要がある、レンダリングに不可欠なリソースがあることをブラウザに伝えることができます。ブラウザをサポートすると、ドキュメントのレンダリング（CSS）が高速化され、ページのコア機能（JavaScript）がより早く利用できるようになります。

おわりに

バックエンド アプリケーション スタックには非常に多くの組み合わせがあるため、ウェブサイトの TTFB を短縮するためにできるすべてを 1 つの記事にまとめているわけではありません。ただし、サーバーサイドで処理を少し高速化するために試すことができるオプションもあります。

すべての指標を最適化する場合とほぼ同じです。現場で TTFB を測定し、ラボツールを使用して原因を掘り下げ、可能であれば最適化を適用します。ここで紹介したすべての手法が、実際の状況に有効とは限りません。これまでと同様に、フィールド データを注意深く確認し、必要に応じて調整を行い、可能な限り高速なユーザー エクスペリエンスを実現してください。

ヒーロー画像Taylor Vick（出典: Unsplash）