「なんとなく」で終わらせない。`rel=”preconnect”` で実現する、泥臭いロード時間の削り方
フロントエンドのパフォーマンスチューニングにおいて、画像圧縮やJSのバンドルサイズ削減は「基本のキ」ですよね。しかし、現場のシニアとして多くのプロジェクトをレビューしていて感じるのは、「ネットワークのレイテンシ」に対する無頓着さです。
特に、Google FontsやサードパーティのAPI、あるいはCDN上の静的ファイル。これらを読み込む際、ブラウザが裏でどんな苦労をしているか、想像したことはありますか？
今回は、ただのおまじないで終わらせない、`rel=”preconnect”` を使った「コネクションの先読み」について、現場のリアルな知見を交えて解説します。
—
ブラウザの裏側で起きている「地味で長い」待ち時間
ブラウザが `https://api.example.com/data` にリクエストを送る際、実はこれだけの工程が裏で行われています。
1. DNSルックアップ: `api.example.com` のIPアドレスを問い合わせる。
2. TCPハンドシェイク: サーバーとの間で「接続していい？」「いいよ」という往復通信を行う。
3. TLSネゴシエーション: HTTPS通信のための暗号化鍵のやり取りをする。
これらが終わって初めて、実際のデータ転送（HTTPリクエスト）が始まります。この「準備運動」だけで、回線状況によっては数百ミリ秒かかることも珍しくありません。特にモバイル回線であれば、この時間は致命的です。
`rel=”preconnect”` は、ブラウザに対して「後でこのドメインにアクセスするから、今のうちにDNS・TCP・TLSまで済ませて待機しておいてくれ」と指示を出すための強力なヒントです。
—
実践：コピペで使えるベストプラクティス
実装は非常にシンプルです。HTMLの `
` 内、できるだけ早い位置（CSSの読み込みよりも前が望ましい）に記述します。
現場で気をつけるべき「2つの罠」
ここからが、教科書には載っていない「現場の泥臭い知見」です。
1. `crossorigin` 属性を忘れないこと
Google Fontsのように、フォントファイルを読み込むドメイン（`fonts.gstatic.com`）に対しては、必ず `crossorigin` 属性が必要です。これがないと、ブラウザは「CORS（Cross-Origin Resource Sharing）」の要件を満たさないと判断し、事前接続の効果が消えたり、最悪の場合は二重接続が発生してリソースの無駄になります。
2. 「とりあえず全部」は絶対にNG
「効きそうだから」と全ての外部ドメインを `preconnect` すると、ブラウザの貴重なソケットリソースを浪費します。接続を確立するということは、CPUとメモリを消費する行為です。
- 優先すべきは「レンダリングをブロックするリソース」（フォント、メインのJSバンドルなど）。
- 逆に、遅延読み込み（Lazy Loading）するようなリソースには不要です。
—
導入後のチェック方法：Chrome DevToolsの「ネットワーク」
実装したら、必ず検証しましょう。Chrome DevToolsの「Network」タブを開き、各リクエストの「Timing」を確認してください。
`preconnect` が正しく効いていれば、「Initial connection」や「SSL」の待ち時間が劇的に短縮されているはずです。逆に、`preconnect` しているのにこれらの時間が長い場合、ドメインの指定ミスや、`crossorigin` の欠落を疑ってください。
—
まとめ：パフォーマンスは「積み重ね」の芸術
`rel=”preconnect”` は魔法の杖ではありません。劇的にサイトが速くなるわけではなく、「0.1秒、0.2秒を削るための地道な一手」です。
しかし、こうした細かな最適化を積み重ねる姿勢こそが、ユーザーに「このサイト、なんかサクサク動くな」という心地よい体験を提供します。
次にあなたがパフォーマンス改善に取り組む際は、まずは `Lighthouse` の指摘項目を眺めるだけでなく、ネットワークの「準備運動」の時間を削ることから始めてみてください。あなたの書いたコードが、より多くのユーザーにストレスなく届くことを願っています。
それでは、また現場でお会いしましょう。
コメント