Time to First Byteの待機時間部分を短縮してください。

待機時間は、リダイレクトとブラウザのキューイングで構成されます。TTFBを短縮するために、リダイレクトを監査し、HSTSを設定し、リダイレクトチェーンを排除する方法を学びましょう。

Arjen Karel - linkedin

Last update: 2026-03-05

Time to First Byteの待機時間を短縮する

この記事はTime to First Byte (TTFB)ガイドの一部です。待機時間はTTFBの最初の要素であり、主にリダイレクト時間とブラウザのキューイングで構成されます。待機時間が長い場合、ほぼ間違いなく不要なリダイレクトが原因です。サーバーが実際のリクエストを処理し始める前に、ラウンドトリップが追加されるためです。

Time to First Byte (TTFB) は以下の要素に分解できます。

Time to First Byteを最適化したいですか？この記事では、Time to First Byteの待機時間について解説します。Time to First Byteを理解または改善したいが、待機時間の意味がわからない場合は、この記事を読む前にTime to First Byteとは何か、およびTime to First Byteの問題を特定して修正するをお読みください。

Time to First ByteのwaitingDurationは、ブラウザがWebサーバーへの接続を開始する前に他のタスクを実行している時間と、リダイレクト時間で構成されます。RUMデータでwaitingDurationが長い場合、原因はほぼ間違いなくリダイレクト時間です。

リダイレクトはTime to First Byte (TTFB) に大きな影響を与えます。各リダイレクトの処理時間が、ブラウザがサーバーから最初の1バイトのデータを受け取るまでの時間に追加されるためです。リダイレクトがTTFBに与える影響は以下の通りです。

Table of Contents!

Time to First Byteの待機時間を短縮する
リダイレクトはどのようにTime to First Byteを増加させるか
UX（およびSEO）への影響
リダイレクトによるTTFBの問題を測定する方法
サイトのリダイレクトを監査する方法
リダイレクトの影響を最小限に抑える方法
- HTTPからHTTPSへのリダイレクトとHSTS
参考資料：最適化ガイド
TTFBの要素：完全ガイド

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

通常、リダイレクトはTTFBの全体測定値に含まれます（青い枠を参照）。つまり、すべてのリダイレクトにかかる時間がTTFB全体のスコアに加算されるため、想定以上に数値が大きくなる可能性があります。

ページがリダイレクトされる際、通常は以下の手順が発生します。

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

リダイレクトの種類とその影響

すべてのリダイレクトが同じわけではありません。種類を理解することで、どのリダイレクトを優先して排除すべきかがわかります。

リダイレクトの種類	HTTPステータス	用途	TTFBへの影響
恒久的なリダイレクト	301	ページが新しいURLに恒久的に移動した	ブラウザがキャッシュする可能性があり、再訪問時の影響を軽減できる
一時的なリダイレクト	302	ページが一時的に別のURLにある	ブラウザにキャッシュされない。毎回完全なラウンドトリップが発生する
一時的なリダイレクト（明示的）	307	302と同じだがHTTPメソッドを保持する	キャッシュされない。302と同じ影響がある
恒久的なリダイレクト（明示的）	308	301と同じだがHTTPメソッドを保持する	ブラウザがキャッシュする可能性がある。301と同様

ネットワーク状況やサーバーの応答時間にもよりますが、1回のリダイレクトで通常TTFBに50〜300ミリ秒追加されます。2〜3回のリダイレクトがチェーンになると、それらの時間が重なり、TTFBが「良好」とされる800ミリ秒のしきい値を大きく超える可能性があります。

サーバー処理時間の増加

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

リダイレクトチェーン

最終目的地に到達するまでに、複数のリダイレクトが発生する場合があります。これが「リダイレクトチェーン」を生み出し、TTFBを増加させます。チェーン内の各リダイレクトに独自の処理時間が追加され、実際のコンテンツの最初の1バイトを受信するまでの遅延が大きくなります。

リダイレクトチェーンのよくある例：

http://example.com
  -> 301 -> https://example.com
    -> 301 -> https://www.example.com
      -> 301 -> https://www.example.com/en/

この例では、ブラウザがコンテンツを受信する前に3回のリダイレクトが発生しています。最初のリダイレクト（HTTPからHTTPS）はHSTSで排除できます。2番目と3番目のリダイレクトは、内部リンクを更新して最終的なURLを直接指すようにすることで排除できます。

ネットワークの遅延

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

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

Time to First Byteに影響しないため、JavaScriptリダイレクトを選択すべきだと考えるかもしれません。しかし残念ながら、JavaScriptリダイレクトは実際のユーザーにとって非常に遅く、UXの低下を招きます。

UX（およびSEO）への影響

リダイレクトが必要な場合もありますが、TTFBへの影響はさらに広範囲に及びます。

UX：リダイレクトによるTTFBの低下は、ページの初期レンダリングを遅らせ、ユーザーをいらだたせる可能性があります。
SEO：TTFBは直接的なランキング要因ではありませんが、検索エンジンが考慮するCore Web Vitalsの1つであるLargest Contentful Paint (LCP)などの他の指標に影響を与えます。
クロールバジェット：検索エンジンのクローラーはリダイレクトをたどるため、リダイレクトごとにクロールバジェットが追加で消費されます。大規模なWebサイトの場合、これにより新規または更新されたコンテンツの発見が遅れる可能性があります。

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

リダイレクトによって実際のユーザーが受けている影響を調べるには、CoreDashのようなRUMツールを使用する必要があります。RUMを使用すると、Core Web Vitalsを詳細に追跡できます。

CoreDashでは、「redirect count」をクリックするだけで、リダイレクト数ごとにセグメント化されたデータを視覚化できます。その後、例えば「1 redirect」セグメントをクリックして、RUMデータを「1回のリダイレクト」でフィルタリングし、影響を受けるすべてのURLを確認します。

ttfb coredash redirect count 3

サイトのリダイレクトを監査する方法

体系的なリダイレクト監査は、次の3つのステップで行います。

ステップ1：サイトをクロールする

クロールツール（MarketingTracer、Screaming Frog、Sitebulbなど）を使用して、Webサイト全体をクロールします。クローラーは、3xxステータスコードで応答するすべての内部URLを報告します。リストをエクスポートし、各リダイレクト先URLを指す内部リンクの数で並べ替えてください。

ステップ2：リダイレクトチェーンを特定する

クロール結果をフィルタリングし、リダイレクト先のURLがさらにリダイレクトしているものを探します。これらはTTFBのペナルティを倍増させるため、真っ先に修正すべきです。

ステップ3：修正と検証

内部リンクを更新し、最終的なURLを直接指すようにします。リンクの更新後、再度クロールして、内部ナビゲーションからリダイレクトがトリガーされなくなったことを検証してください。ブラウザからのリダイレクトを検出するには、以下のJavaScriptスニペットを使用します。

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  if (nav.redirectCount > 0) {
    console.warn('Redirect detected!', {
      redirectCount: nav.redirectCount,
      redirectTime: nav.redirectEnd - nav.redirectStart,
      finalUrl: nav.name
    });
  }
}).observe({
  type: 'navigation',
  buffered: true
});

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

原則として、リダイレクトの問題を回避するために次の3つの簡単なステップに従ってください。

可能な限りリダイレクトの使用を最小限に抑えます。
リンクを更新して最終目的地となるURLを直接指すようにし、リダイレクトチェーンを回避します。
可能であれば、クライアントサイドのリダイレクトではなく、サーバーサイドのリダイレクトを使用します。一般的にこちらの方が高速です。

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

クロスオリジンのリダイレクト。クロスオリジンのリダイレクトは、他のWebサイト上のリンクから発生します。これらを制御することはほとんどできません。大量のトラフィックを生み出す影響の大きいリンクについては、サイトのWebマスターに連絡してリンク先のURLの更新を依頼することを検討してください。

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

HTTPからHTTPSへのリダイレクトとHSTS

HTTPからHTTPSへのリダイレクトは、最も一般的なリダイレクトの1つです。「https://」なしでドメインを入力したり、古いHTTPリンクをたどったりしたすべての訪問者に、301リダイレクトが発生します。Strict-Transport-Securityヘッダー（HSTS）は、常にHTTPSを使用するようにブラウザに指示することで、再訪問者に対するこのリダイレクトを排除します。

HSTSを有効にするには、サーバーの応答に以下のヘッダーを追加します。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

各ディレクティブの意味は以下の通りです。

max-age=31536000：ブラウザは1年間（31,536,000秒）、このドメインに対してHTTPSを使用することを記憶します。
includeSubDomains：HTTPSの要件をすべてのサブドメインにも適用します。
preload：ドメインをブラウザに組み込まれたHSTSプリロードリストに含めることができます。これにより、最初の訪問時でもリダイレクトなしでHTTPSが使用されます。

ドメインをHSTSプリロードリストに登録するには、hstspreload.orgにアクセスしてください。ドメインがプリロードリストに登録されると、ブラウザはドメインに対するHTTPリクエストを一切行わなくなり、すべての訪問者に対してHTTPからHTTPSへのリダイレクトが完全に排除されます。

Apacheでは、以下のようにHSTSを追加できます。

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginxの場合：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

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

内部リンクを定期的に確認し、更新します。ページの場所を変更した場合は、必ずそのページへの内部リンクを更新し、以前のページの場所への参照が残らないようにします。
サーバーレベルでリダイレクトを処理します。推奨されるリダイレクト方法は301リダイレクトです。301リダイレクトは恒久的なリダイレクトですが、302リダイレクトは一時的なリダイレクトです。一時的なリダイレクトは、例えば検索エンジンで更新されない可能性があります。
相対URLを使用します。自サイトのページにリンクする場合は、絶対URLではなく相対URLを使用してください。これにより、不要なリダイレクトを防ぐことができます。
正規URLを使用します。類似したコンテンツのページが複数ある場合は、正規URLを使用して推奨されるバージョンのページを指定します。これにより、コンテンツの重複と不要なリダイレクトを防ぐことができます。

参考資料：最適化ガイド

TTFBの要素：完全ガイド

待機時間は、TTFBの5つの要素の1つです。全体像を理解するために、他の要素についても確認してください。

TTFBの問題の特定と修正：すべてのTTFB最適化の出発点となる診断です。
キャッシュ時間（Cache Duration）：サービスワーカーのパフォーマンス、ブラウザのキャッシュ検索、bfcacheについて。
DNS時間（DNS Duration）：DNSプロバイダーの選択、TTL設定、dns-prefetchについて。
接続時間（Connection Duration）：TCPハンドシェイク、TLS最適化、HTTP/3、preconnectについて。
リクエスト時間（Request Duration）：サーバーの処理時間、データベースクエリ、バックエンドの最適化について。

Lighthouseのスコアは全体像ではありません。

実ユーザーはAndroid端末で4Gを使っています。その人たちが実際に何を体験しているかを分析します。

フィールドデータを分析

Core Web Vitals Time to First Byteの待機時間部分を短縮してください。