サーバーの応答が遅い理由
TTFBはほぼ完全にバックエンドとネットワークの問題であり、フロントエンドの問題ではありません。よくある原因は次のとおりです。
- コールドスタート。 しばらくリクエストがなかったあと、最初のリクエストを処理する前に実行環境を立ち上げる必要があるサーバーレス関数です。
- キャッシュされていない動的レンダリング。 本来キャッシュしたり一度だけ計算しておけたりするはずのデータベースクエリやサーバーサイドレンダリングが、リクエストのたびに再実行されているケースです。
- 遅いデータベースクエリ。 インデックスの設定されていない単一のクエリやN+1パターンが、サーバーがレスポンスの書き込みを開始する前に数百ミリ秒を追加してしまうことがあります。
- オリジンまでの物理的な距離が長い。 シンガポールの訪問者がバージニア州のサーバーにアクセスする場合、サーバー自体の応答がどれだけ速くても、そのラウンドトリップのコストはリクエストのたびに発生します。
- リダイレクトチェーン。 http→https→www→最終URLといった各ホップは、本来のレスポンスが始まる前に発生する完全な往復通信です。
実際に何が遅いのかを特定する方法
Scanverraのパフォーマンスチェックは、稼働中のURLに対してLCPやCLSと同じLighthouse実行の一部としてTTFBを取得します。そのため、代理指標ではなく実際のサーバー応答時間そのものが得られます。これが重要なのは、TTFBが速いのにLCPが遅い場合は画像や描画まわりの修正に目を向けるべきだと分かり、TTFBもLCPも遅い場合はまずサーバーの修正を優先すべきだと分かるからです。
実際に時間がどこで消費されているのかを絞り込むには、外部から推測するのではなく、ホスティングやAPMプロバイダーが提供するサーバーサイドのタイミング内訳(多くのプラットフォームは関数の初期化、データベース呼び出し、レスポンスのシリアライズにかかった時間をそれぞれ個別に報告します)を確認してください。
修正方法
1. リクエストごとに再生成する必要のないものをキャッシュする
すべての訪問者(あるいは特定セグメントのすべての訪問者)にとって同じ内容になるものは、キャッシュの候補です。すべてのリクエストがオリジンに到達してしまうのではなく、CDNのエッジで明示的なキャッシュ期間を設定してください。
1Cache-Control: public, max-age=60, stale-while-revalidate=3002. オリジン(少なくともキャッシュ層)をユーザーの近くに配置する
実際のトラフィックに近いリージョンにデプロイするか、遠く離れたオリジンの前にエッジキャッシュ/CDNを配置して、ほとんどのリクエストが長い往復通信をまったく経由しなくて済むようにしてください。
3. 症状ではなく、遅いクエリそのものを修正する
APMでデータベースの処理時間がTTFBの大半を占めていることが分かった場合、それは通常インデックスの欠落、N+1クエリパターン、あるいはページが実際に必要とする以上の処理を行っているクエリが原因です。回避策としてキャッシュに頼る前に、まず該当クエリをプロファイリングしてください。
4. サーバーレス関数のコールドスタート頻度を減らす
レイテンシに敏感なルートについては関数をウォームに保ち、ハンドラーが実行される前に初期化しなければならないコードや依存関係を最小限に抑え、コールドスタートが常時発生するようなトラフィックパターンには永続的なサーバーの採用を検討してください。
5. リダイレクトチェーンを解消する
ユーザーがリクエストするURLと実際にコンテンツを配信するURLの間にあるホップはすべて、描画が始まる前にTTFBへ加算される完全な往復通信です。リンクとcanonical URLは最終的な行き先を直接指すようにしてください。
ScanverraがTTFBの問題をどう検出するか
TTFBは、Scanverraがすべてのパフォーマンスチェックで実行する同じ実際のLighthouseパス——デスクトッププロファイルと375pxのモバイルビューポートの両方——から直接取得されます。そのため、シミュレーションではなく、実際に稼働しているサーバーの応答に対して計測されます。