preconnectとは、外部リソースへの接続を事前に確立し、ページ表示の高速化を図るための仕組みです。

通常はリクエスト発生後にDNS解決やTCP接続、TLSハンドシェイクが行われますが、preconnectを使うことでこれらを先回りして実行できます。

本記事では、preconnectの基本的な仕組みから具体的な設定方法、効果を最大化するための注意点までをわかりやすく解説します。

preconnectとは

preconnectとは、外部ドメインへの通信に必要な接続処理を、リソース取得前に先回りして行うための仕組みです。

通常、ブラウザはDNSルックアップ、TCP接続、TLSハンドシェイクといった段階を経て通信を開始しますが、preconnectを使うことでこれらを事前に完了させ、待ち時間を短縮できます。

特にCDNやWebフォント、外部APIなど別ドメインのリソースを読み込む場合に有効で、初期表示速度やLCPの改善に寄与します。

何を事前接続するのか

preconnectでは、外部ドメインとの通信に必要な3つの処理を事前に接続します。

まず、ドメイン名からIPアドレスを取得する「DNSルックアップ」、次にサーバーと通信路を確立する「TCP接続」、そしてHTTPS通信を安全に行うための「TLSハンドシェイク」です。

通常はリソース要求時にこれらが順番に実行されるため遅延が発生しますが、preconnectを使うことで事前に完了させ、実際のリクエスト時にはすぐにデータ取得を開始できる状態を作れます。

これにより、特に外部リソースの初回読み込み速度が大きく改善されます。

preconnectの仕組み

通常の通信フローとの違い

通常の通信では、ブラウザがHTMLを解析し外部リソースを発見した後に、DNSルックアップ、TCP接続、TLSハンドシェイクといった接続処理を順番に開始します。

そのため、実際のデータ取得までに複数の待ち時間が発生します。

一方preconnectでは、これらの接続処理をリソース要求より前に実行しておくため、必要になったタイミングですぐにデータ通信を開始できます。

つまり「リクエスト後に接続する」通常フローに対し、「事前に接続を済ませておく」点が大きな違いです。

なぜ高速化されるのか

preconnectによって高速化される理由は、通信開始前に発生する遅延を削減できるためです。

特にDNSルックアップやTCP接続、TLSハンドシェイクはそれぞれ往復通信（RTT）を伴うため、ネットワーク距離が長いほど時間がかかります。

preconnectでこれらを事前に完了させておくことで、実際のリクエスト時には即座にデータ転送へ移行でき、初回表示の待ち時間を大幅に短縮できます。

特にCDNや海外サーバーなど、接続コストが高い環境で効果を発揮します。

preconnectのメリット

LCP改善

preconnectは、LCP（Largest Contentful Paint）の改善に大きく貢献します。

LCP要素が外部リソース（画像CDNやWebフォントなど）に依存している場合、接続確立の遅れがそのまま表示遅延につながります。

preconnectを使って事前に接続を完了させておくことで、リソース取得までの待ち時間を削減し、描画開始を早めることが可能です。

特にファーストビューに関わるリソースで効果が高く、Core Web Vitalsのスコア改善にも直結します。

初期表示の高速化

preconnectは、ページの初期表示速度を向上させる有効な手段です。

通常は外部リソースを検知してから接続処理が始まるため、表示までにタイムラグが発生します。

しかしpreconnectを設定しておくことで、ページ読み込みと同時に接続処理を先行させることができ、重要なリソースの取得がスムーズになります。

結果として、テキストや画像の表示が早まり、ユーザーが体感する表示速度の改善につながります。

外部リソース読み込みの最適化

preconnectは、CDNやWebフォント、外部APIなど別ドメインから取得するリソースの読み込みを最適化します。

これらのリソースは接続コストが高く、複数存在するとパフォーマンス低下の原因になります。

preconnectを適切に使うことで、重要な外部ドメインへの接続を優先的に確立でき、リソース取得のボトルネックを解消できます。

結果として、無駄な待機時間を減らし、ページ全体の読み込み効率を高めることが可能になります。

preconnectのデメリット・注意点

無駄な接続による負荷

preconnectは便利な一方で、不要なドメインに対して実行すると無駄な接続が発生し、ブラウザやサーバーに負荷をかけてしまいます。

接続確立にはDNS解決やTCP接続、TLSハンドシェイクといった処理が伴うため、実際に使用しないリソースに対して行うとリソースの浪費になります。

特にモバイル環境では通信コストやバッテリー消費にも影響するため、対象は本当に必要な外部ドメインに限定することが重要です。

多用すると逆効果

preconnectを多用しすぎると、ブラウザの同時接続数の上限に達し、本来優先すべきリソースの読み込みが遅れる可能性があります。

また、不要な接続が増えることでネットワーク帯域を圧迫し、結果として全体のパフォーマンスが低下するケースもあります。

一般的には重要度の高いドメインに絞り、3〜5件程度に抑えるのが推奨されます。

効果を確認しながら最適化することが重要です。

HTTP/2・HTTP/3環境での影響

HTTP/2やHTTP/3では1つの接続で複数のリクエストを効率的に処理できるため、preconnectの効果が限定的になる場合があります。

特に同一ドメイン内のリソースでは既存接続が再利用されるため、追加のpreconnectは不要です。

またHTTP/3では接続確立の高速化自体が進んでいるため、恩恵が小さいケースもあります。

ただし異なるドメイン間の通信では依然として有効なため、環境に応じた適切な判断が求められます。

preconnectを使うべきケースと実装例

Google Fonts利用時

Google Fontsを利用する場合、フォントファイルはfonts.gstatic.comなど別ドメインから配信されるため、初回接続に時間がかかります。

preconnectを設定することで、フォント読み込み前にDNS解決やTLS接続を完了させ、表示遅延を防げます。

特にファーストビューでWebフォントを使用する場合に有効です。

使用例

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap" rel="stylesheet">

CDN利用時

画像やCSS、JavaScriptをCDNから配信している場合もpreconnectは有効です。CDNは別ドメインであることが多く、初回アクセス時に接続確立の遅延が発生します。

preconnectを使うことで事前に接続を完了し、リソース取得を高速化できます。

特にヒーロー画像や重要なCSSをCDN配信している場合に効果が大きいです。

使用例

<link rel="preconnect" href="https://cdn.example.com">
<link rel="stylesheet" href="https://cdn.example.com/styles.css">

外部API利用時

外部APIからデータを取得する場合も、preconnectによって通信開始までの遅延を削減できます。

特に初回リクエスト時は接続確立に時間がかかるため、事前接続しておくことでレスポンス速度が向上します。

ユーザー操作に応じてAPI通信が発生するケースでは、体感速度の改善に直結します。

使用例

<link rel="preconnect" href="https://api.example.com">
<script>
fetch('https://api.example.com/data')
</script>

広告・タグマネージャー

広告配信やタグマネージャーも外部ドメインとの通信が多いため、preconnectの対象になります。

特にGoogleが提供するタグ管理ツールなどは、複数のリクエストを発生させるため、接続遅延が積み重なりやすい領域です。

事前接続によりスクリプトの読み込みをスムーズにし、ページ全体のパフォーマンス低下を防げます。

使用例

<link rel="preconnect" href="https://www.googletagmanager.com">
<script src="https://www.googletagmanager.com/gtm.js"></script>

preconnectが不要なケース

同一ドメイン内

同一ドメイン内のリソースに対しては、preconnectは基本的に不要です。

ブラウザはHTMLの取得時点で既にそのドメインとの接続を確立しており、その後のCSSやJavaScript、画像の読み込みでは同じ接続を再利用します。

そのため、改めてpreconnectを指定しても効果はほとんどありません。

むしろ無駄な記述が増えるだけで、最適化の観点では意味が薄くなります。

対象はあくまで外部ドメインに限定することが重要です。

HTTP/2で既に接続済み

HTTP/2では1つの接続で複数のリクエストを同時に処理できるため、一度接続が確立されるとその後の通信は効率的に行われます。

このため、すでに接続済みのドメインに対してpreconnectを追加しても効果は限定的です。

特に同一ドメインや早い段階で読み込まれる外部リソースについては、ブラウザが自動的に接続を維持・再利用するため、追加の最適化としての優先度は低くなります。

リクエストが少ない場合

外部ドメインへのリクエストが少ない場合も、preconnectの効果は限定的です。

接続確立には一定のコストがかかるため、1回しかアクセスしない、もしくは重要度が低いリソースに対して事前接続を行うと、コストに対して得られる効果が見合わない可能性があります。

特に遅延の影響が小さい軽量リソースでは、preconnectを使わずに通常の読み込みでも十分なパフォーマンスが得られるケースが多いです。

preload・preconnect・prefetchとの違い

preloadの特徴と違い

preloadは、表示に必要なリソースを優先的にダウンロードするための仕組みで、preconnectとは役割が大きく異なります。

preconnectが「接続を先に確立する」のに対し、preloadは「ファイルそのものを先に取得する」点が特徴です。

例えば重要な画像やフォント、CSSなどをpreloadすると、ブラウザは通常よりも高い優先度で読み込みを行います。

一方でpreconnectはあくまで準備段階の最適化であり、両者を組み合わせることで、接続と取得の両面から表示速度を改善できます。

preconnectの特徴と違い

preconnectとの違いは、「何を先回りするか」にあります。

preconnectはDNSルックアップやTCP接続、TLSハンドシェイクといった通信の準備を事前に行う仕組みで、実際のリソース取得は含みません。

一方、preloadやprefetchはファイル自体の取得を目的とした仕組みです。

つまりpreconnectは“接続の最適化”、preloadは“現在必要なリソースの優先取得”、prefetchは“将来のための先読み”という役割の違いがあります。

それぞれ対象とタイミングが異なるため、適切に使い分けることが重要です。

prefetchの特徴と違い

prefetchは、将来必要になる可能性があるリソースをあらかじめ低優先度で取得しておく仕組みです。

主に次のページで使われるJavaScriptやHTMLなどを先読みする用途で使われます。

一方、preconnectは現在表示しているページの高速化を目的として、接続処理を事前に行う点が異なります。

prefetchはユーザーの次の行動を見越した最適化であり、即時表示の改善には直接寄与しません。

用途やタイミングが異なるため、目的に応じて使い分けることが重要です。

dns-prefetchとの違い

dns-prefetchとは

dns-prefetchとは、外部ドメインにアクセスする際に必要な「DNSルックアップ（ドメイン名からIPアドレスを取得する処理）」を事前に実行しておく仕組みです。

通常、ブラウザはリソースを検知してからDNS解決を行うため、その分の待ち時間が発生しますが、dns-prefetchを使うことでこの処理を先回りして完了させることができます。

通信の最初のステップだけを軽量に最適化する手法であり、複数の外部ドメインを扱うサイトで効果を発揮します。

preconnectとdns-prefetchの違い

preconnectとdns-prefetchの違いは、事前に行う処理の範囲です。

dns-prefetchはDNSルックアップのみを実行するのに対し、preconnectはDNS解決に加えてTCP接続やTLSハンドシェイクまで完了させます。

そのためpreconnectの方が高速化効果は高い一方で、負荷も大きくなります。

軽量に広範囲のドメインを最適化したい場合はdns-prefetch、重要なリソースで確実に高速化したい場合はpreconnectといったように、用途に応じて使い分けることが重要です。

preconnect使用時の注意点と失敗パターン

多用しすぎない（目安：3〜5件）

preconnectは効果が高い反面、設定しすぎると逆効果になります。

接続確立にはコストがかかるため、多数のドメインに対して実行するとブラウザのリソースや通信帯域を圧迫し、本来優先すべきリソースの読み込みが遅れる可能性があります。

重要度の高い外部ドメインに絞り、3〜5件程度に抑えるのが実務上のベストです。

headタグの上部に記述する

preconnectはできるだけ早い段階で実行されることが重要です。

そのため、HTMLのheadタグ内でも上部に記述する必要があります。

下部に配置するとブラウザの実行が遅れ、事前接続の効果が薄れてしまいます。

初期解析時にすぐ処理される位置に書くことで、接続準備を最大限前倒しできます。

対象リソースより前に書く

preconnectは対象となるリソースより前に記述しなければ意味がありません。

例えばCSSやJavaScriptの読み込みタグより後に書くと、既に接続処理が始まってしまい、事前接続として機能しません。

必ず対象のlinkやscriptタグより前に配置し、接続処理を先行させることが重要です。

crossoriginの付け忘れに注意

Webフォントなどのクロスオリジンリソースでは、crossorigin属性を付ける必要があります。

これがないと接続が完全に再利用されず、期待したパフォーマンス改善が得られない場合があります。

特にフォント配信では重要なポイントであり、正しく設定することでpreconnectの効果を最大化できます。

効果測定を必ず行う

preconnectは設定するだけでなく、効果測定が不可欠です。

環境や対象リソースによっては効果が出ない、もしくは逆にパフォーマンスが低下するケースもあります。

Chrome DevToolsやLighthouseなどを活用し、LCPや読み込み時間の変化を確認しながら最適化を進めることが重要です。

preconnectに関するよくある質問（FAQ）

Q. preconnectは何個まで設定すべきですか？

A. 一般的には3〜5件程度が推奨です。多すぎると接続処理の負荷が増え、逆にパフォーマンスが低下する可能性があります。LCPに影響する重要な外部ドメインに絞って設定しましょう。

Q. 同一ドメインにもpreconnectは必要ですか？

A. 不要です。同一ドメインはHTML取得時点で既に接続が確立されているため、preconnectを追加しても効果はほとんどありません。

Q. HTTP/2やHTTP/3でも効果はありますか？

A. 効果はありますが限定的です。これらのプロトコルは接続の再利用や高速化が進んでいるため、同一ドメインでは不要なケースが多いです。ただし外部ドメインとの通信では依然として有効です。

Q. preconnectとdns-prefetchはどちらを使うべきですか？

A. 重要なリソースにはpreconnect、軽量に広く最適化したい場合はdns-prefetchがおすすめです。preconnectは効果が高い分、負荷も大きいため使い分けが重要です。

Q. crossoriginは必ず必要ですか？

A. Webフォントなどクロスオリジンリソースでは必要です。指定しないと接続が再利用されず、効果が十分に発揮されない場合があります。

Q. どのドメインに設定すればいいですか？

A. CDN、Webフォント、外部APIなど「初期表示に影響する外部ドメイン」が対象です。特にLCPに関わるリソースを優先しましょう。

Q. 設定すれば必ず速くなりますか？

A. 必ずではありません。環境や通信状況によっては効果が出ない、または逆効果になる場合もあります。必ずLighthouseやDevToolsで効果測定を行いましょう。

Q. preloadやprefetchと併用できますか？

A. 可能です。preconnectは接続の最適化、preloadはリソース取得の最適化、prefetchは将来の先読みと役割が異なります。組み合わせることでより高い効果が期待できます。

preconnectまとめ

preconnectとは、外部ドメインとの通信に必要な接続処理（DNS解決・TCP接続・TLSハンドシェイク）を事前に完了させ、ページ表示の高速化を実現する仕組みです。

特にCDNやWebフォントなど初期表示に関わるリソースで効果を発揮し、LCP改善にも寄与します。

一方で、多用や不要なドメインへの設定は逆効果になるため、重要な外部ドメインに絞ることが重要です。

適切に使えば、表示速度改善において非常に有効な最適化手法です。