リダイレクトの速度: リダイレクトが遅い理由とその解決方法

リダイレクトはウェブサイトを遅くしますか？#

少しは、毎回遅くなります。ブラウザが実際のページの読み込みを始める前に、古いURLへリクエストを送信し、リダイレクト応答を待ってから、新しいアドレスで再び開始しなければなりません。その時間はページ読み込みの一部です。Google のTime to First Byte 指標では、リダイレクト時間が最初のフェーズとしてカウントされ、0.8秒以下を良好な TTFB とみなします^[1]。リダイレクトにかかるミリ秒は、その分だけ他の処理に使える時間が減ります。

速いリダイレクトが1回ある程度なら、問題になることはほとんどありません。問題なのは、何回も続く場合です。Lighthouse は2回以上のリダイレクトがあるページに警告を出します。余分な往復が増えるたびに、読み込みが数百ミリ秒遅れる可能性があるためです^[2]。特にモバイル回線では顕著です。

検索エンジンもリダイレクトに従います。Google はGooglebot は一般的に10回のリダイレクトホップまで追従する^[3]と述べているため、短いチェーンであればクロールされますが、各ホップはクローラーにとって追加のリクエストであり、チェーンのどこかが壊れる余地も増えます。

リダイレクトが遅くなる原因#

リダイレクト応答自体は小さいため、その時間のほとんどは待ち時間です。つまり、ドメインの参照、接続の確立、HTTPS ハンドシェイク、そしてサーバーが訪問者をどこへ送るかを決めるまでの時間です。通常、次のような理由で遅くなります。

リダイレクトチェーン: 最も一般的な原因#

リダイレクトチェーンとは、遷移先の URL でもう一度リダイレクトされるリダイレクトのことです。ほとんどは意図せず起こります。たとえば、誰かが https://mybrand.com へのリダイレクトを設定したものの、サイト本体は https://www.mybrand.com/en/ にあるため、訪問者は何も表示される前にさらに 2 回跳ね返されます。

これは、人々が想像するよりもはるかに頻繁に起こります。私たちが自社プラットフォーム上のアクティブなドメインリダイレクトのサンプルを確認したところ、約 3 件に 1 件は、訪問者をさらに別のリダイレクト先へ送っていました。余分な段階は、おおむね均等に、www の追加または削除、同じサイト内でのパス変更（末尾のスラッシュ、言語フォルダ、ログインページ）、そして別ドメインへの移行に分かれていました（RedirHub プラットフォームデータ、2026 年 10 月）。それらの段階はどれも必要ありませんでした。最終 URL をそのままリダイレクトにコピーすれば解消できます。

リダイレクトチェーンの見つけ方と修正方法#

1. 古いURLを当社のリダイレクト速度テストに入力してください。各ホップのステータスコードとホップ数が表示されます。
2. ホップが1回以上ある場合は、「到達先」に表示されている最終URLをコピーしてください。
3. リダイレクトの送信先をその正確なURLに変更します。https、同じホスト名（wwwあり／なしのどちらでも可）、そして同じ末尾スラッシュにしてください。
4. 内部リンク、canonicalタグ、サイトマップも更新し、リダイレクトを経由せずに最終URLを使用するようにしてください。
5. もう一度テストします。結果はホップが1回で、最後が200であるはずです。

サイト移転のたびにチェーンは増えていきます。新しいリダイレクトが古いものの上に追加されるからです。Webサイト移行を計画するときは、古いリダイレクトをチェーンにせず、新しい最終URLへ向け直してください。リダイレクトがまったく機能しない場合は、301リダイレクトが機能しない理由を確認してください。

リダイレクトを速くする方法#

• 1回のホップだけにする。 これが最も大きな改善で、コストはかかりません。
• アプリケーションより前でリダイレクトする。 Nginx、Apache、CDN、またはリダイレクトサービスのルールは、アプリのコードが実行される前に応答します。CMS全体を先に読み込む必要があるリダイレクトプラグインは、最も遅い方法です。
• 訪問者の近くで応答する。 1つのリージョンにある単一サーバーからのリダイレクトは、近くでは速く、地球の反対側では遅くなります。エッジネットワークは最寄りの場所から応答します。
• meta refresh や JavaScript ではなく、HTTPリダイレクトを使う。 301 または 302 は短い1回の応答で済みますが、自分でリダイレクトするページは先に読み込まなければなりません。
• http のホップを省く。 リンクは https のURLにし、サイトで HSTS を有効にして、戻ってきたブラウザーが最初にネットワークへ問い合わせることなく直接 https に進めるようにします。
• 移動が恒久的なら 301 を選ぶ。 どちらも応答速度は同じですが、ブラウザーは 301 をキャッシュできるため、再訪問者はリクエスト自体を省略できる場合があります。

リダイレクトはどのくらい速ければよいですか？#

私たちのリダイレクト速度テストは、ワシントンD.C.、フランクフルト、東京から、リダイレクト応答だけ（新しい接続での最初のバイトまでの時間）を計測し、過去7日間にテストされたすべてのリダイレクトと比較して順位付けします。2026年10月24日時点で、7日間平均は157 msでした。提供元別では、中央値は最大級のCDNで約10 msから、最も遅い短縮URLサービスでは500 ms超まで幅があり、RedirHub自身のリダイレクトは17 msで応答しました。提供元によってはテストされたURLが1つか2つしかない場合もあるため、提供元一覧はランキングではなく目安としてご覧ください。

目安として、100 ms未満のリダイレクトは気づかれません。数百ミリ秒かかるなら、広告、メールキャンペーン、モバイルトラフィックなど速度が重要なページでは改善する価値があります。そしてチェーンがあると、各ホップのコストがそのまま積み重なります。

RedirHub: サーバーを稼働させずに高速リダイレクト#

リダイレクトするドメインがどこにもホストされていない場合（旧ブランド、キャンペーンドメイン、 টাইपोドメインなど）、RedirHub が 130 のグローバルエッジロケーションから、訪問者に最も近い場所で、設定した転送先へ単一ホップでリダイレクトを応答します。変更するのはルートと www のレコードだけなので、DNS とメールはそのまま維持され、どちらも 自動 HTTPS が発行・更新されます。

それが最も役立つのは、多くのドメインを管理しているときです。転送済みドメインのポートフォリオや、一括CSVインポートで読み込んだ何千もの古いURLです。サイトがすでにリダイレクトルール付きのCDNの背後にある場合も、それらは同じくらい高速で、そのサイトのリダイレクトに別のサービスは必要ありません。

リダイレクト速度チェックリスト#

• すべてのリダイレクトは、1回のホップで最終ページに到達します。
• 遷移先は、https、正しいホスト名、正しい末尾のスラッシュを含む、完全に最終URLを使用します。
• リダイレクトはページコードではなく、ウェブサーバー、CDN、またはリダイレクトサービスで実行されます。
• 内部リンク、canonical、サイトマップは最終URLを指しています。
• 重要なリダイレクトは、サイトの変更や移行のたびに再テストされます。