Core/Dash ディメンション: Redirect Count

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

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

RTT 100msの接続では、1回のリダイレクトがTTFBに100msを追加します。200msのモバイル接続では、これが倍になります。モバイルで2回のリダイレクト：ブラウザがページの最初の1バイトを受信する前に400msの純粋な待ち時間が発生します。このレイテンシーは最終URLを直接テストするラボテストでは見えませんが、リンク、ブックマーク、検索結果をたどる実際のユーザーは、毎回の訪問でこれを負担します。

値の意味

リダイレクト0回

目標の状態です。ブラウザが最初のリクエストで最終URLにアクセスしました。すべての内部ナビゲーションでこの値になるべきです。自サイトのリンク、サイトマップ、canonicalタグが正しければ、内部トラフィックは0のままです。

リダイレクト1回

外部トラフィックでよく見られます：HTTPからHTTPSへのアップグレード、wwwの正規化、またはマーケティングキャンペーンURL。制御できない外部リンクからのアクセスでは許容範囲です。自サイトの内部リンクでは許容できません。CoreDashが内部ナビゲーションで1回のリダイレクトを示している場合、リンクが古いまたは一貫性のないURLを指しています。

リダイレクト2回以上

リダイレクトチェーンです。短縮URLがトラッキングドメインにリダイレクトし、そこからHTTPエンドポイントにリダイレクトし、さらにHTTPSにリダイレクトします。3ホップ、3ラウンドトリップ。URLでグループ化して、どのエントリーポイントがこれらのチェーンを作成しているかを特定し、中間ステップを排除します。

リダイレクトの発生源

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

デバッグワークフロー

1. redir ≥ 1でフィルタリング： 総トラフィックのうち、少なくとも1回のリダイレクトが発生しているパーセンテージを確認します。15%以上であれば調査する価値があります。
2. URLでグループ化： 最も問題のあるランディングページを見つけます。マーケティングページやスラッグが変更された古いブログ投稿が多くを占める傾向があります。
3. 内部と外部を分離： navigation originでフィルタリングします。同一オリジンのトラフィックにリダイレクトがある場合、自サイトのリンクが間違っています。クロスオリジンのリダイレクトは修正が難しいですが、緊急性は低いです。
4. リダイレクトではなく、ソースを修正： リダイレクト自体を最適化（サーバーレスポンスの高速化）するのではなく、原因となったリンクを更新して排除してください。

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

• すべての内部ナビゲーションでリダイレクト0回。 ソースリンクを制御できる場合、自サイトからのリダイレクトは許容できません。
• URL移行のたびに監査を実施。 スラッグを変更したりページを移動したりする場合、コードベースとCMSで古いパスを検索してください。リダイレクトは外部リンクのためのセーフティネットであり、自サイトの参照を更新する代替手段ではありません。
• モバイルではリダイレクト1回あたり150msを見込む。 TTFBの目標が800msで、ユーザーが2回のリダイレクトに遭遇する場合、サーバーが何かを行う前にすでに300msを消費しています。

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