Time to First Byteの待機時間サブパートを削減する

Time to First Byteの待機時間を削減する

Time to First Byte（TTFB）は以下のサブパートに分解できます：

• 待機 + リダイレクト（待機時間）
  
• Worker + キャッシュ（キャッシュ時間）
• DNS（DNS時間）
• 接続（接続時間）
• リクエスト（リクエスト時間）

Time to First Byteを最適化したいですか？この記事ではTime to First Byteの待機時間パートの詳細な分析を提供しています。Time to First Byteを理解または修正したいが、待機時間の意味がわからない場合は、Time to First ByteとはとTime to First Byteの問題を特定して修正するをこの記事の前にお読みください

リダイレクトはTime to First Byte（TTFB）に大きな影響を与える可能性があります。各リダイレクトがブラウザがサーバーからデータの最初のバイトを受信するまでの時間に加算されるためです。リダイレクトがTTFBに影響を与える仕組みは以下の通りです：

リダイレクトはどのようにTime to First Byteを増加させるのか？

リダイレクトは通常、TTFBの完全な測定に含まれます（青いボックスを参照）。これは、すべてのリダイレクトにかかる時間がTTFBスコア全体に反映され、予想よりも高く見える可能性があることを意味します。

ページがリダイレクトされると、通常以下のステップが発生します：

• ブラウザが元のURLに最初のリクエストを送信します。
  
• サーバーがこのリクエストを処理し、リダイレクトステータスコード（例：301または302）で応答します。
  
• ブラウザがリダイレクト先のURLに新しいリクエストを送信します。サーバーがこの2番目のリクエストを処理し、実際のコンテンツの送信を開始します。

サーバー処理時間の増加

この追加の処理は全体的なTTFBを増加させます。各ステップにはサーバーがリクエストを処理して応答するための時間が必要です。

リダイレクトチェーン

場合によっては、最終目的地に到達する前に複数のリダイレクトが発生することがあります。これにより「リダイレクトチェーン」が作成され、TTFBが増加する可能性があります。チェーン内の各リダイレクトはそれぞれの処理時間を追加し、実際のコンテンツの最初のバイトが受信されるまでの遅延を増加させます。

ネットワークレイテンシー

リダイレクトには、クライアントとサーバー間の追加のネットワークラウンドトリップが伴うことがよくあります。これにより、特にリダイレクトが異なるドメインやサーバーに関与している場合、追加のネットワークレイテンシーが発生します。各リダイレクトにおけるクライアントとサーバー間の物理的な距離は、TTFBにさらに影響を与える可能性があります。

JavaScriptリダイレクトとサーバーサイドリダイレクト：サーバーサイドリダイレクト（30xリダイレクトヘッダーで動作するもの）のみがTime to First Byteに加算されます。JavaScriptリダイレクトはサーバーから完全なレスポンス（200）が送信されるため、Time to First Byteには加算されません。

Time to First Byteに加算されないため、JavaScriptリダイレクトを好むべきだと考えるかもしれません。しかし残念ながら、JavaScriptリダイレクトは実際のユーザーにとってはるかに遅く、User Experienceの低下の原因となります。

User Experience（およびSEO）への影響

リダイレクトは時として必要ですが、TTFBへの影響はより広範な影響を及ぼす可能性があります：

• User Experience：リダイレクトによるTTFBの低下はページの初期レンダリングを遅延させ、ユーザーのフラストレーションを引き起こす可能性があります。
• SEO：TTFBは直接的なランキング要因ではありませんが、Largest Contentful Paint（LCP）などの他の指標に影響を与えます。LCPは検索エンジンが考慮するCore Web Vitalsの一つです。

リダイレクトによるTTFBの問題を測定する方法

リダイレクトが実際のユーザーに与える影響を把握するには、CoreDashのようなRUMツールを使用する必要があります。Real User Monitoringにより、Core Web Vitalsを詳細にトラッキングできます。

CoreDashでは、「リダイレクト回数」をクリックするだけで、リダイレクト回数別にデータを可視化できます。次に、例えば「1リダイレクト」セグメントをクリックして、RUMデータを「1リダイレクト」でフィルタリングし、影響を受けるすべてのURLを表示します。

リダイレクトの影響を最小限に抑える方法

一般的なルールとして、リダイレクトの問題を回避するために以下の3つの簡単なステップに従ってください：

• 可能な限りリダイレクトの使用を最小限に抑えます。
  
• リンクを最終的な宛先URLに直接向けるように更新して、リダイレクトチェーンを回避します。
• 可能な場合は、クライアントサイドリダイレクトの代わりにサーバーサイドリダイレクトを使用してください。一般的にサーバーサイドの方が高速です。

同一オリジンリダイレクト。同一オリジンリダイレクトは、自分のウェブサイト上のリンクから発生します。これらのリンクは完全にコントロールできるため、Time to First Byteの改善に取り組む際にはこれらのリンクの修正を優先すべきです。これらの内部リダイレクトを見つける一般的な方法は、ウェブサイト全体のリダイレクトをチェックできる利用可能な ツール を使用することです。

クロスオリジンリダイレクト。クロスオリジンリダイレクトは、他のウェブサイト上のリンクから発生します。これらに対するコントロールはほとんどありません。大量のトラフィックを生成する影響の大きいリンクについては、サイトのウェブマスターに連絡してリンク先URLの更新を検討してください。

リダイレクトチェーン。 複数のリダイレクトやリダイレクトチェーンは、単一のリダイレクトがリソースの最終的な場所にリダイレクトしない場合に発生します。これらのタイプのリダイレクトはTime to First Byteにより大きな負担をかけるため、絶対に避けるべきです。ここでも、ツールを使用してこれらのタイプのリダイレクトを見つけて修正してください！

HTTPからHTTPSへのリダイレクト。これを回避する方法の1つは、Strict-Transport-Securityヘッダー（HSTS）を使用することです。HSTSはオリジンへの最初のアクセスでHTTPSを強制し、以降のアクセスではブラウザにHTTPSスキームを通じてオリジンに即座にアクセスするよう指示します。

一般的に、以下を推奨します：

1. 内部リンクを定期的にチェックして更新してください！ページの場所を変更するたびに、そのページへの内部リンクを更新して、以前のページの場所への参照が残らないようにしてください。
   
2. リダイレクトはサーバーレベルで処理してください。推奨されるリダイレクト方法は301リダイレクトです。301リダイレクトは恒久的なリダイレクトであり、302リダイレクトは一時的なリダイレクトです。一時的なリダイレクトは、例えば検索エンジンで更新されない可能性があります。
   
3. 相対URLを使用する：自分のウェブサイトのページにリンクする場合は、絶対URLの代わりに相対URLを使用してください。これにより不要なリダイレクトを防ぐことができます。
   
4. 正規URLを使用する：類似のコンテンツを持つ複数のページがある場合は、正規URLを使用してページの優先バージョンを示してください。これにより重複コンテンツや不要なリダイレクトを防ぐことができます。