Time to First Byte 指標を最適化する方法について説明します。
公開日: 2023 年 1 月 19 日、最終更新日: 2025 年 11 月 28 日
Time to First Byte（TTFB）は、First Contentful Paint（FCP）や Largest Contentful Paint（LCP）などの他の重要なユーザー エクスペリエンス指標に先立つ、ウェブ パフォーマンスの基本的な指標です。つまり、TTFB の値が高いと、その後の指標に時間が追加されます。
サーバーがナビゲーション リクエストに十分迅速に応答し、ユーザーの 75 パーセンタイルが「良好」のしきい値内で FCP を体験できるようにすることをおすすめします。大まかな目安として、ほとんどのサイトでは TTFB を 0.8 秒以下にすることを目指す必要があります。
TTFB の測定方法
TTFB を最適化する前に、TTFB がウェブサイトのユーザーにどのように影響するかを観察する必要があります。TTFB はリダイレクトの影響を受けるため、TTFB を観察する主なソースとしてフィールド データを使用する必要があります。一方、ラボベースのツールは多くの場合、最終 URL を使用して測定されるため、この追加の遅延は考慮されません。
PageSpeed Insights は、Chrome ユーザー エクスペリエンス レポートで利用可能な公開ウェブサイトのフィールド情報とラボ情報の両方を取得する方法の 1 つです。
実際のユーザーの TTFB は、上部の [実際のユーザーが体験していることを確認する] セクションに表示されます。
ラボデータの場合、TTFB の問題はドキュメント リクエストのレイテンシの分析情報に表示されます。
フィールドとラボの両方で TTFB を測定する方法について詳しくは、TTFB 指標のページをご覧ください。
フィールド TTFB とラボ TTFB の違いを理解する
ラボとフィールドの TTFB はさまざまな理由で異なる場合があります。異なる場合は、ラボデータを効果的に使用してユーザー エクスペリエンスを改善できるように、その理由を理解することが重要です。
ラボの TTFB がフィールドの TTFB よりもはるかに大きい場合、ラボ環境が一般的なユーザー エクスペリエンスよりも制約されていることを示しています。ラボの結果と推奨事項は引き続き有効であるため、これは必ずしも問題ではありませんが、影響と改善が誇張される可能性があります。
フィールド TTFB がラボ TTFB よりもはるかに大きい場合、サーバーサイド キャッシュの使用、リダイレクト、ネットワークの違いなど、ラボの実行では明らかにならない問題があることを示しています。この場合、ラボの結果と推奨事項は、主な問題の 1 つを見逃しているため、あまり役に立たない可能性があります。
サーバーサイド キャッシュがラボの TTFB に影響しているかどうかを確認するには、あまり一般的でないページをテストするか、別の URL パラメータを使用してキャッシュされていないコンテンツを取得し、TTFB がフィールドの TTFB と一致するかどうかを確認します。また、特定の URL パラメータを使用してサーバーサイド キャッシュをバイパスできると便利です。キャッシュに保存されたコンテンツのセクションをご覧ください。
リダイレクトとネットワークの違いについては、トラフィックがサイトにどのようにアクセスしているか、どこからアクセスしているかを分析することで、潜在的な問題かどうかを診断できます。
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 - $dbReadStartTime) / 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] タブの [Timings] パネルに表示されます。
ここでは、Server-Timing を使用して、リソースのリクエストが CDN キャッシュにヒットしたかどうか、リクエストが CDN のエッジサーバーにヒットしてからオリジンにヒットするまでの時間を測定します。
サーバーのタイミングは、Chrome DevTools の [Performance] パネルの [Network] トラックにも表示されます。
![Chrome DevTools の [Performance] パネルの [Network] トラックの [Details] タブに表示される Server-Timing ヘッダー値の可視化。](https://web.developers.google.cn/static/articles/optimize-ttfb/image/performance-panel-network-track-server-timing.png?hl=ja)
利用可能なデータを分析して 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 プロトコルを使用することで、TCP（HTTP/2 が依存するプロトコル）に存在するヘッドオブライン ブロッキングの問題を解決します。
- CDN は最新バージョンの TLS を提供している可能性が高く、TLS ネゴシエーション時間に関連するレイテンシを短縮できます。特に TLS 1.3 は、TLS ネゴシエーションをできるだけ短くするように設計されています。
- 一部の CDN プロバイダは、「エッジワーカー」と呼ばれる機能を提供しています。この機能は、Service Worker API と同様の API を使用してリクエストをインターセプトし、エッジ キャッシュ内のレスポンスをプログラムで管理したり、レスポンスを完全に書き換えたりします。
- CDN プロバイダは、圧縮の最適化に非常に優れています。圧縮を独自に適切に行うのは難しく、動的に生成されたマークアップをその場で圧縮する必要がある場合など、特定のケースではレスポンス時間が遅くなる可能性があります。
- また、CDN プロバイダは静的リソースの圧縮レスポンスを自動的にキャッシュに保存するため、圧縮率とレスポンス時間の最適な組み合わせが実現します。
CDN の導入に必要な労力は、ごくわずかなものから多大なものまでさまざまですが、ウェブサイトでまだ CDN を使用していない場合は、TTFB の最適化を追求するうえで優先度の高い取り組みとなります。
可能な場合はキャッシュに保存されたコンテンツを使用する
CDN を使用すると、コンテンツが適切な Cache-Control HTTP ヘッダーで構成されている場合、訪問者に物理的に近いエッジサーバーにコンテンツをキャッシュできます。これはパーソナライズされたコンテンツには適していませんが、オリジンまで戻る必要があると、CDN の価値の多くが失われる可能性があります。
コンテンツを頻繁に更新するサイトの場合、キャッシュ時間が短くても、アクセス数の多いサイトではパフォーマンスが大幅に向上します。これは、その時間内に最初にアクセスしたユーザーのみが、配信元サーバーへの完全なレイテンシを経験し、他のすべてのユーザーはエッジサーバーからキャッシュされたリソースを再利用できるためです。一部の CDN では、サイトのリリース時にキャッシュを無効化できるため、キャッシュ時間を長くしつつ、必要に応じて即座に更新するという、両方のメリットを享受できます。
キャッシュが正しく構成されている場合でも、分析測定に一意のクエリ文字列パラメータを使用することで、キャッシュを無視できます。これらは、同じコンテンツであっても CDN には異なるコンテンツのように見えるため、キャッシュされたバージョンは使用されません。
古いコンテンツやアクセス数の少ないコンテンツもキャッシュされないことがあり、その結果、一部のページで TTFB 値が他のページよりも高くなることがあります。キャッシュ保存時間を長くすると、この影響を軽減できますが、キャッシュ保存時間を長くすると、古いコンテンツが配信される可能性が高くなります。
キャッシュに保存されたコンテンツの影響は、CDN を使用しているユーザーだけに及ぶわけではありません。キャッシュに保存されたコンテンツを再利用できない場合、サーバー インフラストラクチャは、コストのかかるデータベース ルックアップからコンテンツを生成する必要がある場合があります。アクセス頻度の高いデータやプリキャッシュされたページは、パフォーマンスが向上することがよくあります。
複数のページ リダイレクトを避ける
TTFB が高くなる一般的な原因の一つは、リダイレクトです。リダイレクトは、ドキュメントのナビゲーション リクエストが、リソースが別の場所にあることをブラウザに通知するレスポンスを受け取ったときに発生します。1 回のリダイレクトでもナビゲーション リクエストに不要なレイテンシが追加される可能性がありますが、そのリダイレクトが別のリソースを指し、その結果別のリダイレクトが発生すると、さらに悪化する可能性があります。これは、広告やニュースレターから大量の訪問者を受け取るサイトに特に影響する可能性があります。これらのサイトは、測定目的で分析サービスを介してリダイレクトされることが多いためです。直接管理下にあるリダイレクトを排除することで、良好な TTFB を実現できます。
リダイレクトには次の 2 種類があります。
- 同一オリジンのリダイレクト。リダイレクトが完全にウェブサイト上で行われます。
- クロスオリジン リダイレクト。リダイレクトが最初に別のオリジン（ソーシャル メディアの短縮 URL サービスなど）で発生してから、ウェブサイトに到達します。
同一オリジンのリダイレクトは直接制御できるため、これを排除することに重点を置きます。これには、ウェブサイト上のリンクをチェックして、302 または 301 のレスポンス コードが返されるリンクがないか確認することが含まれます。多くの場合、これは https:// スキームが含まれていない（ブラウザがデフォルトで http:// にリダイレクトする）か、URL の末尾のスラッシュが適切に含まれていないか、除外されていないことが原因です。
クロスオリジンのリダイレクトは、多くの場合、制御できないため、より複雑になります。ただし、可能な限り、複数のリダイレクトを回避するようにしてください。たとえば、リンクを共有するときに複数のリンク短縮ツールを使用するなどです。広告主やニュースレターに提供する URL が正しい最終ページ URL であることを確認し、それらのサービスで使用されるリダイレクトに別のリダイレクトが追加されないようにします。
リダイレクト時間のもう 1 つの重要な原因として、HTTP から HTTPS へのリダイレクトが挙げられます。この問題を回避する方法の一つは、Strict-Transport-Security ヘッダー（HSTS）を使用することです。このヘッダーは、オリジンへの最初のアクセスで HTTPS を強制し、それ以降のアクセスでは HTTPS スキームを介してオリジンにすぐにアクセスするようブラウザに指示します。
適切な HSTS ポリシーを導入したら、サイトを HSTS プリロード リストに追加することで、オリジンへの最初のアクセスを高速化できます。
マークアップをブラウザにストリーミングする
ブラウザは、マークアップがストリーミングされるときに効率的に処理するように最適化されています。つまり、マークアップはサーバーから到着したときにチャンクで処理されます。これは、マークアップのペイロードが大きい場合に重要です。つまり、ブラウザは、解析を開始する前にレスポンス全体が到着するのを待つのではなく、マークアップのチャンクを段階的に解析できます。
ブラウザはストリーミング マークアップの処理に優れていますが、ストリームを維持するためにできる限りのことを行い、最初のマークアップが可能な限り早く送信されるようにすることが重要です。バックエンドが処理を遅らせている場合は、問題があります。バックエンド スタックは多数存在するため、すべてのスタックと、それぞれで発生する可能性のある問題を網羅することは、このガイドの範囲外です。
たとえば、React や、サーバー上でオンデマンドでマークアップをレンダリングできる他のフレームワークでは、サーバーサイド レンダリングに同期アプローチが使用されてきました。ただし、新しいバージョンの React では、レンダリング時にマークアップをストリーミングするためのサーバー メソッドが実装されています。つまり、React サーバー API メソッドがレスポンス全体をレンダリングしてから送信するのを待つ必要がありません。
マークアップをブラウザにすばやくストリーミングするもう一つの方法は、ビルド時に HTML ファイルを生成する静的レンダリングを利用することです。ファイル全体がすぐに利用可能になるため、ウェブサーバーはすぐにファイルの送信を開始でき、HTTP の固有の性質によりマークアップがストリーミングされます。このアプローチは、ユーザー エクスペリエンスの一環として動的なレスポンスが必要なページなど、すべてのウェブサイトのすべてのページに適しているわけではありませんが、特定のユーザーに合わせてマークアップをパーソナライズする必要がないページには有効です。
サービス ワーカーを使用する
Service Worker API は、ドキュメントとドキュメントが読み込むリソースの両方の TTFB に大きな影響を与える可能性があります。これは、Service Worker がブラウザとサーバー間のプロキシとして機能するためです。ただし、ウェブサイトの TTFB に影響があるかどうかは、Service Worker の設定方法と、その設定がアプリケーションの要件に合致しているかどうかによって異なります。
- アセットに stale-while-revalidate 戦略を使用する。アセットが Service Worker キャッシュにある場合、それがドキュメントであっても、ドキュメントに必要なリソースであっても、stale-while-revalidate 戦略は、まずキャッシュからそのリソースを提供し、次にバックグラウンドでそのアセットをダウンロードして、今後のインタラクションのためにキャッシュから提供します。
- あまり変更されないドキュメント リソースがある場合は、stale-while-revalidate 戦略を使用すると、ページの TTFB をほぼ瞬時にできます。ただし、ウェブサイトが動的に生成されたマークアップ（ユーザーが認証されているかどうかに基づいて変化するマークアップなど）を送信する場合、この方法はあまり効果的ではありません。このような場合は、ドキュメントをできるだけ最新の状態に保つために、常に最初にネットワークにアクセスする必要があります。
- ドキュメントが、ある程度の頻度で変更される重要でないリソースを読み込むものの、古いリソースを取得してもユーザー エクスペリエンスに大きな影響を与えない場合（選択した画像やその他の重要でないリソースなど）、stale-while-revalidate 戦略を使用することで、それらのリソースの TTFB を大幅に削減できます。
- クライアント レンダリング アプリケーションにはアプリケーション シェルモデルを使用する。このモデルは、ページの「シェル」を Service Worker キャッシュから即座に配信でき、ページの動的コンテンツがページ ライフサイクルの後半で入力されてレンダリングされる SPA に最適です。
レンダリングに不可欠なリソースには 103 Early Hints を使用する
アプリケーションのバックエンドがどれほど最適化されていても、レスポンスを準備するためにサーバーが行う必要がある作業は依然として大量に存在する可能性があります。これには、ナビゲーション レスポンスの到着を遅らせる、高コストな（しかし必要な）データベース作業も含まれます。この潜在的な影響として、CSS や、場合によってはクライアントでマークアップをレンダリングする JavaScript など、後続のレンダリングに不可欠なリソースが遅延する可能性があります。
103 Early Hints ヘッダーは、バックエンドがマークアップの準備でビジー状態のときに、サーバーがブラウザに送信できる早期レスポンス コードです。このヘッダーを使用すると、マークアップの準備中にページがダウンロードを開始する必要があるレンダリングに不可欠なリソースがあることをブラウザに伝えることができます。対応ブラウザでは、ドキュメントのレンダリング（CSS）が高速化され、ページの読み込みが速くなります。
103 Early Hints のデメリットの 1 つは、キャッシュと同様に、サイトの「実際の」TTFB をマスクできることです。サーバー インフラストラクチャが遅い場合（パワー不足またはコードの最適化が必要なため）、103 Early Hints を使用すると TTFB が速く見えるため、そのことがわかりにくくなる可能性があります。103 Early Hints を使用しているサイトでは、PerformanceNavigationTiming API の Server-Timing または finalResponseHeadersStart を使用して、実際のサーバー時間を測定することを検討してください。
まとめ
バックエンド アプリケーション スタックの組み合わせは非常に多いため、ウェブサイトの TTFB を下げるためにできるすべてを網羅した記事はありません。ただし、サーバー側で処理を少しでも高速化するために、いくつかの方法を試すことができます。
他の指標の最適化と同様に、アプローチはほぼ同じです。フィールドで TTFB を測定し、ラボツールを使用して原因を掘り下げ、可能な場合は最適化を適用します。状況によっては、一部の手法が有効でない場合もありますが、有効な手法もあります。これまでと同様に、フィールド データを注意深く監視し、必要に応じて調整を行って、可能な限り高速なユーザー エクスペリエンスを実現する必要があります。