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

最初のバイトまでの時間指標を最適化する方法を学習します。

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 APIserverTiming プロパティに入力されます。

// 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 では、TCP に存在するヘッドオブライン ブロッキングの問題(HTTP/2 が依存する)が、UDP プロトコルを使用して解決されます。
  • 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 へのリダイレクトです。これを回避する方法としては、Strict-Transport-Security ヘッダー(HSTS)を使用して、オリジンへの初回アクセス時に HTTPS を適用し、次回以降アクセスするときに HTTPS スキームを使用してオリジンに即座にアクセスするようブラウザに指示します。

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

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

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

ブラウザはストリーミング マークアップの処理に優れていますが、そのストリームの流れを維持できるようにできる限りの手段を尽くして、マークアップの最初の部分ができるだけ早く配信されるようにすることが重要です。バックエンドで処理が妨げられている場合は問題です。バックエンド スタックは多数あるため、すべてのスタックと、各スタックで生じる可能性のある問題は説明しません。

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

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

Service Worker を使用する

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

  • アセットに古い再検証戦略を使用する。アセットが 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)