Core/Dash ディメンション: リダイレクト数

ユーザーがページに到達するまでに経由するHTTPリダイレクトの数と、それがTTFBに与える直接的なコストを測定します。

無料トライアル

Trusted by market leaders · Client results

harvardwhowhatwearworkivasnvaleteiaperionvpnnina careadevintanestlekpndpg mediafotocasaebayhappyhorizoncompareerasmusmcmarktplaatsloopearplugsmy work featured on web.devsaturnmonarch

ディメンション: Navigation: Redirect Count (redir)

redir ディメンションは、最終ページに到達する前のHTTPリダイレクトをカウントします。値は 0、1、2、または 3+ です。各リダイレクトは、サーバーがHTMLの生成を開始する前に行われる完全なネットワークの往復です。

RTTが100msの接続では、1回のリダイレクトによりTTFBに100msが追加されます。200msのモバイル接続ではその倍になります。モバイルでの2回のリダイレクトは、ブラウザがページの最初の1バイトを受信するまでに400msの純粋な待機時間を生み出します。この遅延は、最終的なURLを直接叩くラボテストでは目に見えませんが、リンク、ブックマーク、または検索結果をたどる実際のユーザーは、訪問のたびにこの遅延の影響を受けます。

coredash redirect count

各値の意味

リダイレクト0回

目標とする状態です。ブラウザは最初のリクエストで最終的なURLに到達しました。すべての内部ナビゲーションはこの値になるべきです。自身のサイトのリンク、サイトマップ、およびカノニカルタグが正確であれば、内部トラフィックは0のままです。

リダイレクト1回

外部トラフィックで一般的です（HTTPからHTTPSへのアップグレード、wwwの正規化、マーケティングキャンペーンのURLなど）。制御できないインバウンドリンクであれば許容できますが、自身の内部リンクでは許容されません。内部ナビゲーションでCoreDashに1回のリダイレクトが表示される場合、リンクが古い、または一貫性のないURLを指しています。

リダイレクト2回以上

リダイレクトチェーンです。短縮URLがトラッキングドメインにリダイレクトされ、それがHTTPエンドポイントにリダイレクトされ、さらにHTTPSにリダイレクトされます。3回のホップ、3回の往復です。URL でグループ化して、どのエントリポイントがこれらのチェーンを生成しているかを特定し、中継地点を排除してください。

リダイレクトの発生源

  • HTTPからHTTPSへ: 古い内部リンクがまだ http:// を指しています。すべてのリンク、サイトマップ、およびカノニカルタグを更新して、https:// を直接使用するようにしてください。
  • wwwの正規化: wwwありとwwwなしの間に一貫性がありません。DNSレベルでどちらか一方を強制し、すべての参照を更新してください。
  • CMSスラッグの変更: 301により古いパスが新しいパスにリダイレクトされています。外部からのバックリンクとしては問題ありませんが、すべての内部リンクを更新して新しいスラッグを直接指すようにしてください。
  • マーケティング用バニティURL: /spring-sale のようなバニティパスが /products/seasonal にリダイレクトされています。すべての訪問者がクリックするたびに遅延のコストを支払うことになります。
  • メールやソーシャルのURL短縮サービス: リンクがドメインに到達する前に、Bitly、トラッキングピクセル、またはメールサービスプロバイダーを経由します。各サービスは制御できない往復を追加しますが、自身のサイトでのリダイレクトを最小限に抑えることで全体を低く保つことができます。

デバッグのワークフロー

  1. redir \u2265 1 でフィルタリング: 全トラフィックの何パーセントが少なくとも1回のリダイレクトに遭遇しているかを確認します。15%を超える場合は調査する価値があります。
  2. URLでグループ化: どのランディングページが最も問題を引き起こしているかを見つけます。マーケティングページや、スラッグが変更された古いブログ記事が大部分を占める傾向があります。
  3. 内部と外部の分割: navigation origin でフィルタリングします。同一オリジンのトラフィックでリダイレクトが発生している場合、自身のリンクが間違っていることを意味します。クロスオリジンのリダイレクトは修正が難しいですが、緊急性は低いです。
  4. リダイレクトではなくソースを修正する: リダイレクト自体を最適化（サーバー応答の高速化など）しないでください。原因となったリンクを更新することでリダイレクトを完全に排除します。

エンジニアリングの経験則

  • すべての内部ナビゲーションでリダイレクト0回: リンク元を制御できる場合、自身のサイトからのリダイレクトは一切許容されません。
  • URL移行ごとの監査: スラッグを変更したりページを移動したりする場合は、コードベースとCMSで古いパスをgrepしてください。リダイレクトは外部リンクのための安全網であり、自分自身の参照を更新する代わりにはなりません。
  • モバイルでのリダイレクト1回につき150msの予算を見込む: TTFBの目標が800msであり、ユーザーが2回のリダイレクトに遭遇した場合、サーバーが何らかの処理を行う前にすでに300msを消費していることになります。

リダイレクトは、発見と修正が最も簡単なTTFBの改善策です。コードの変更、サーバーのチューニング、アセットの最適化は必要ありません。間違った場所を指しているURLを更新するだけです。