DNSルックアップの「待ち時間」を削り取れ：`dns-prefetch` を使いこなす現場の知恵
フロントエンドのパフォーマンスチューニングにおいて、私たちはつい「JSのバンドルサイズ」や「画像フォーマット」といった目に見える改善に注力しがちです。しかし、ブラウザがサーバーと握手を交わす前の、「あのドメインってどこにあるんだっけ？」というDNS解決の数ミリ秒を軽視していませんか？
今回は、モダンブラウザの隠れた働き者である `dns-prefetch` について、現場のリアルな視点から深掘りしていきます。
—
なぜ、DNS解決がボトルネックになるのか
ユーザーが `https://api.example.com` にリクエストを送る際、ブラウザはまずDNSサーバーに問い合わせてIPアドレスを取得しなければなりません。この「名前解決」には、環境やネットワーク状況によって数msから、遅い時には100ms以上かかることもあります。
もちろん、一度解決したアドレスはキャッシュされますが、「初めて訪れるドメイン」に対しては必ずこのオーバーヘッドが発生します。
ここで登場するのが `dns-prefetch` です。これは「このドメインは後で使うから、今のうちに裏で名前解決だけ済ませておいてくれ」とブラウザに指示するヒント（Resource Hints）です。
`preconnect` との違いを理解する
似たような機能に `preconnect` がありますが、両者には明確な温度差があります。
- `preconnect`: DNS解決だけでなく、TCPハンドシェイク、TLSネゴシエーションまで済ませる。リソース消費は大きいが、即座に通信が必要な場合に最強。
- `dns-prefetch`: DNS解決のみを先行する。軽量で低コスト。これから通信する可能性が高いドメインに対して、リスクを抑えて打てる「保険」のような存在です。
すべてのドメインに `preconnect` を貼ると、ブラウザのリソースを無駄に食いつぶし、逆にメインスレッドのパフォーマンスを落としかねません。「重要度は高いが、今すぐ通信するとは限らないドメイン」には `dns-prefetch` を選ぶ。 これが中級者以上の賢い使い分けです。
—
実践：現場で使うべきコードパターン
`dns-prefetch` は `head` タグ内に記述するのが鉄則です。サードパーティのスクリプト（Google Fonts、解析ツール、広告など）を読み込む前に、先行してDNS解決を叩き込んでおきましょう。
【Tips】プロのこだわり：`preconnect` との併用
もし「確実にすぐに読み込む」ことが分かっているなら、以下のように重ねて書くのが現場のベストプラクティスです。古いブラウザは `preconnect` を無視して `dns-prefetch` だけを拾い、最新ブラウザは賢く `preconnect` を優先します。
—
現場でありがちな落とし穴と注意点
「じゃあ、全部のドメインに貼れば最強じゃないか？」と思ったあなた、それは罠です。
1. 過剰なDNSプリフェッチは逆効果:
DNSキャッシュは有限です。無駄に多くのドメインを指定すると、ブラウザのDNSキャッシュテーブルを圧迫し、本当に必要な名前解決を追い出してしまう可能性があります。「確実に使うことが分かっているサードパーティ」に絞るのが大人の判断です。
2. `https` の場合もスキームは省略可:
仕様上、`//domain.com` のようにプロトコル相対で記述するのが一般的です。ブラウザが現在のページと同じスキームを自動的に適用してくれます。
3. 検証は必ず `Network` パネルで:
Chrome DevToolsの「Network」タブで、実際にDNS解決の時間が短縮されているかを確認してください。`Waterfalls`（瀑布図）を眺めれば、リクエスト開始直後の「DNS Lookup」の時間が劇的に減っているはずです。
—
まとめ：微細な最適化が積み重なって「速さ」になる
`dns-prefetch` は、それ単体で劇的な速度改善をもたらす魔法ではありません。しかし、こうした地味な最適化を積み重ねることで、Webサイトの「読み込みの滑らかさ」は確実に向上します。
特に、低速なモバイル回線を利用しているユーザーにとって、この数ミリ秒の短縮は「サイトが重い」と感じさせるか否かの境界線になり得ます。
「ブラウザにどう動いてほしいか」を先回りして教える。
その視点こそが、フロントエンドエンジニアとしての腕の見せ所です。ぜひ今日のプロダクトの `head` を見直して、適切なドメインにこのヒントを仕込んでみてください。
コメント