広告ネットワークに事前接続（Preconnect）すべきか？ LCPに依存します

手短な答え：それはLCPに依存します

サイトを監査する際、私は常にリソースヒントの戦略を確認します。広告の表示を早めて収益を増やすことを期待して、クライアントが広告ネットワークに事前接続（preconnect）することがあります。これが役立つか悪影響を与えるかは、ある1つのことに完全に依存しています。それは、あなたのLargest Contentful Paint画像がすでに適切に最適化されているかどうかです。

最終レビュー：Arjen Karel（2026年3月）

LCP画像がHTML内にあり（JavaScriptによって挿入されたものではなく）、遅延読み込み（lazy load）されておらず、fetchpriority="high"が設定されている場合、ブラウザは他に事前接続しているものに関係なく、それを優先します。その場合、主要な広告ネットワークのオリジンへの事前接続は安全であり、広告の配信を数ミリ秒早めることで実際に収益を増やすことができます。

しかし、LCPが最適化されていない場合、追加したすべての事前接続は、最悪のタイミングで帯域幅とCPUサイクルを奪い合います。私は、1日あたり5,000から1,500万ページビューのサイトでこれが失敗するのを見てきました。

事前接続（preconnect）が実際に機能する仕組み

事前接続のヒントは、ファイルが実際に必要になる前に、外部サーバーへの接続（DNS + TCP + TLS）を開くようにブラウザに指示します。ファイルが最終的に要求されたとき、接続はすでに準備されており、ダウンロードがすぐに開始されます。web.devによると、これにより重要なオリジンの時間を100〜500ミリ秒節約できます。

注意点として、Chromeは10秒以内に使用されなかった事前接続を閉じます。接続が使用されなかった場合、無駄にTCP + TLSの完全なコストを支払ったことになります。

最新の広告ネットワークの仕組み

スクリプトを含めると、そのスクリプトがオークションを実行し（多くの場合、Prebid.jsのようなものを介したヘッダー入札によって複数のデマンドパートナーが参加します）、落札した広告は、あなたが聞いたこともないサーバーからリソースを読み込みます。この連鎖は5つ以上のドメインに深くなることがあります。HTMLの解析時には分からないドメインに事前接続することはできないため、これは重要です。

広告ネットワークへの事前接続がパフォーマンスに悪影響を与える場合

LCPが最適化されていない場合、広告ネットワークへの事前接続は状況を悪化させます。 すべての初期接続は、最も重要なリソース（LCP画像、スタイルシート、フォント）がまだダウンロードされていない時期に帯域幅を奪い合います。

この実際の例を見てください。クライアントは最適化されていないLCPを持ち、複数の広告ドメインに事前接続していました。私が広告の事前接続を削除した後、わずか3ヶ月で、良好なページ数は180万ページから624万ページに増加しました。

事前接続はLCP画像から帯域幅を奪っていました。競合をなくすことで、ブラウザは初期のネットワーク時間を本当に重要なことに費やすことができます。

広告ネットワークへの事前接続が理にかなっている場合

LCPがすでに高速である場合、メインの広告スクリプトのオリジンへの事前接続は問題ありません。 チェックリストは以下の通りです。

1. LCP画像がHTML内にある（JavaScriptによって挿入されたり、CSSから読み込まれたりしていない）
2. LCP画像が遅延読み込み（lazy load）されていない
3. LCP画像にfetchpriority="high"が設定されている
4. LCP画像がブラウザのプリロードスキャナによって検出可能である

これら4つすべてに当てはまる場合、ブラウザは事前接続に関係なく、最優先でLCP画像をフェッチします。追加のTCP + TLSハンドシェイクによるわずかな帯域幅のコストは、LCPに影響を与えません。そして、広告が速くなることは、より多くのインプレッション、より高いビューアビリティスコア、そしてより多くの収益を意味します。

CoreDashで監視されているサイト全体で見ると、単一の広告ネットワークオリジンへの事前接続は、接続時間を数ミリ秒節約するだけです。LCP画像がすでに適切に優先順位付けされている場合、それはLCPに影響を与えるほどではありません。しかし、その数ミリ秒が広告のフィルレートにとって重要な場合があります。

細心の注意を払う

これは、見つかったすべての広告ドメインに事前接続するための白紙委任状ではありません。ルールは以下の通りです。

1. 1つのオリジンのみに事前接続する： メインの広告スクリプトのドメインです。ヘッダー入札による15のデマンドパートナーのドメインに事前接続しないでください。どれがオークションに勝つかは分かりません。
2. スクリプトがまだ検出可能でない場合のみ事前接続する。 通常の<script async src="https://adnetwork.ext/script.js">タグで広告スクリプトを読み込む場合、ブラウザのプリロードスキャナはすでにそれを見つけています。その上に事前接続を行っても何も追加されません。
3. キャッシュされたスクリプトは事前接続を無意味にする。 広告スクリプトがすでにブラウザのキャッシュにある場合（広告が多いサイトのリピーターに共通）、事前接続されたTCP + TLSハンドシェイクは使用されず、純粋なオーバーヘッドになります。
4. まずLCPを修正する。 LCPのしきい値をまだクリアしていない場合は、広告の事前接続を追加しないでください。LCP画像をプリロードし、fetchpriority="high"を設定し、遅延読み込みされていないことを確認してください。その後、広告の事前接続を再検討します。

LCPが適切に最適化されているかどうかわからない場合は、事前接続を追加する前に、CoreDashまたはCrUXでフィールドデータを確認してください。

それでもヒントを使用したい場合は、代わりにdns-prefetchを使用する

広告サーバーへの何らかの早期接続のヒントが必要だが、事前接続の完全な帯域幅コストをかけたくない場合は、代わりにdns-prefetchを使用してください。これはDNSのみを解決し（20〜120ミリ秒）、TCPとTLSを完全にスキップし、帯域幅を奪い合うアイドル接続を作成しません。

<link rel="dns-prefetch" href="//securepubads.g.doubleclick.net">
<link rel="dns-prefetch" href="//pagead2.googlesyndication.com">

これはより安全な妥協案です。クリティカルなレンダリングウィンドウ中に帯域幅が競合するリスクなしに、DNSルックアップ時間を削ることができます。

どの広告ネットワークをテストしたか？

これらはすべて、私が過去1年間にテストした事前接続です。使用している広告ネットワークがリストにないからといって、事前接続すべきというわけではありません。単に私がテストしていないというだけです。Real User MonitoringでA/Bテストを設定し、あなたのサイトに最適なものをテストしてください。

<link rel="preconnect" href="//securepubads.g.doubleclick.net">
<link rel="preconnect" href="//www.google.com">
<link rel="preconnect" href="//adservice.google.com">
<link rel="preconnect" href="//tpc.googlesyndication.com">
<link rel="preconnect" href="//pagead2.googlesyndication.com">
<link rel="preconnect" href="//www.gstatic.com">
<link rel="preconnect" href="https://s0.2mdn.net">
<link rel="preconnect" href="https://googleads.g.doubleclick.net">
<link rel="preconnect" href="https://www.googleadservices.com">
<link rel="preconnect" href="https://dis.criteo.com">
<link rel="preconnect" href="https://c1.adform.net">
<link rel="preconnect" href="https://snap.licdn.com">
<link rel="preconnect" href="https://visitor.omnitagjs.com">
<link rel="preconnect" href="https://secure.adnxs.com">
<link rel="preconnect" href="https://cdn.brandmetrics.com">
<link rel="preconnect" href="https://p.adsymptotic.com">
<link rel="preconnect" href="https://bidder.criteo.com">
<link rel="preconnect" href="https://gum.criteo.com">
<link rel="preconnect" href="https://sslwidget.criteo.com">
<link rel="preconnect" href="https://static.criteo.net">

その背後にある数字

2025 Web Almanacによると、22%のページが事前接続のヒントを使用しており、LCPをパスしているモバイルオリジンはわずか62%です。つまり、ウェブの大部分はサードパーティのオリジンに事前接続している一方で、その事前接続が悪影響を与える可能性のあるまさにその指標（LCP）で失敗していることを意味します。

同じデータによると、現在17.3%のモバイルページがLCP画像にfetchpriority="high"を使用しています。もしあなたがこの17.3%に含まれているなら、あなたのLCP画像は優先順位の競争に勝ち、単一の広告の事前接続が問題を引き起こす可能性は低いです。そうでない場合は、そこから始めてください。