RTTとは何か、なぜ重要なのか
往復時間（RTT）は、信号が通信相手まで届き、戻るまでの時間です。応答全体の時間とは異なり、DNS、接続確立、サーバー処理、転送などの時間も加わります。並列リクエストの数だけ RTT が直列に加算されるわけではありません。
RTTはWeb Vitalsにどう影響するか
- LCP： HTML や重要なリソースの遅延で、主要コンテンツの表示が遅れる場合があります。
- INP： 操作から次の描画までを測り、非同期リクエストの完了時間を測るものではありません。検索結果が遅くても INP が良好な場合があるため、両方を測定します。
- TTFB： RTT だけでなく接続確立やサーバー処理も含みます。TTFB 自体は Core Web Vital ではありません。
- CLS： 表示領域を確保していないリソースが遅れて届くと、レイアウトがずれる場合があります。高い RTT だけが原因とは限りません。
RTTが大きくなる主な原因
- オリジンサーバーが遠い、または CDN とバックエンドの間に余分な経路がある
- 依存するリクエストやリダイレクトが連鎖している
- 再利用できる接続を毎回作り直している
- 重要な外部リソースの発見が遅い
- 応答全体の時間だけを見ると、サーバー処理の遅さをネットワークの問題と誤認する
RTTを減らすための対策
- リージョンを比較し、利用者に近い CDN や計算処理を検討します。実際にエッジで返す応答を確認してください。
- 対応する HTTP/2 と HTTP/3 を比較します。物理的な距離はなくならず、HTTP/2 には TCP レベルのブロッキングが残ります。
- バージョン付きの静的リソースをキャッシュします。HTML と API では情報の鮮度と機密性を守ります。
<link rel="preconnect">、dns-prefetch、フォントの preload は、重要だと確認したリソースに限定します。物理的な RTT は短くなりません。- 不要な要求を減らし、重要でない JavaScript を遅らせます。遅延読み込みは画面外の適切な内容に使い、LCP 画像には使わないでください。
- リダイレクトを減らし、接続や TLS セッションを再利用します。0-RTT や証明書の最適化は実際の環境で確認します。
Miltenの結果を使ってRTTを調べる
- ネットワーク診断の RTT、サーバー遅延、オリジン別の転送性能を、測定条件とともに確認します。
- リソースヒントとウォーターフォール、特に LCP/FCP 前の要求を調べます。ヒントがないことは調査候補であり、必ず追加すべきとは限りません。
- サーバー処理と通信の遅延を分けます。
- リリース後に再測定します。地域を比べるときは利用できる設定を確認し、条件をそろえてください。
確認項目のチェックリスト
- 遅いオリジンと重要な要求の連鎖を特定する
- ブラウザー–エッジ間と、必要ならエッジ–オリジン間の実際のプロトコルを調べる
- 有効な接続・先読みヒントだけを追加する
- 正しい最終 URL を維持し、不要なリダイレクトを減らす
- キャッシュや stale-while-revalidate で鮮度と機密性を守る
- 条件をそろえた複数の試行と、実際の訪問データを比較する
まず測定する
milten.io の Speed Scanner でネットワークの指摘を調べ、確認できたボトルネックを一つ選びましょう。初期結果と条件を保存し、変更後に同じ条件で比較してください。
