Should You Preconnect to Ad Networks? It Depends on Your LCP

The short answer: it depends on your LCP

Whenever I audit a site I always look at resource hint strategies. Sometimes clients preconnect to ad networks, hoping to speed up ads and increase revenue. Whether this helps or hurts depends entirely on one thing: is your Largest Contentful Paint image already properly optimized?

Last reviewed by Arjen Karel on March 2026

If your LCP image is in the HTML (not injected by JavaScript), not lazy loaded, and has fetchpriority="high", the browser will prioritize it regardless of what else you preconnect to. In that case, preconnecting to your primary ad network origin is safe and can actually make you money by serving ads a few milliseconds faster.

But if your LCP is not optimized, every preconnect you add competes for bandwidth and CPU cycles at the worst possible moment. I have seen this go wrong on sites with 5,000 to 15 million daily pageviews.

What a preconnect actually does

A preconnect hint tells the browser to open a connection (DNS + TCP + TLS) to an external server before it actually needs a file from there. When the file is finally requested, the connection is already warm and the download starts immediately. According to web.dev, this can save 100 to 500ms for critical origins.

The catch: Chrome closes any preconnect that is not used within 10 seconds. If the connection goes unused, you paid the full TCP + TLS cost for nothing.

How modern ad networks work

You include a script, that script runs an auction (often with multiple demand partners via header bidding through something like Prebid.js), and the winning ad loads resources from servers you have never heard of. The chain can be five or more domains deep. This matters because you cannot preconnect to domains you do not know at HTML parse time.

When preconnecting to ad networks hurts performance

If your LCP is not optimized, preconnecting to ad networks will make things worse. Every early connection competes for bandwidth at a time when your most important resources (the LCP image, stylesheets, fonts) have not been downloaded yet.

Take a look at this real life example. The client had an unoptimized LCP and was preconnecting to multiple ad domains. After I removed the ad preconnects, they went from 1.8 million good pages to 6.24 million good pages in just 3 months.

The preconnects were stealing bandwidth from the LCP image. Remove the competition and the browser can spend its early network time on what actually matters.

When preconnecting to ad networks makes sense

If your LCP is already fast, preconnecting to your main ad script origin is fine. Here is the checklist:

1. Your LCP image is in the HTML (not injected by JavaScript or loaded from CSS)
2. Your LCP image is not lazy loaded
3. Your LCP image has fetchpriority="high"
4. Your LCP image is discoverable by the browser's preload scanner

When all four are true, the browser will fetch your LCP image at the highest priority regardless of preconnects. The small bandwidth cost of an extra TCP + TLS handshake will not move your LCP. And faster ads mean more impressions, higher viewability scores, and more revenue.

Across sites monitored by CoreDash, a preconnect to a single ad network origin saves only a few milliseconds of connection time. That is not enough to affect your LCP if the LCP image is already properly prioritized. But those few milliseconds can matter for ad fill rates.

Be extremely careful

This is not a blank check to preconnect to every ad domain you can find. The rules:

1. Preconnect to one origin only: your primary ad script domain. Do not preconnect to 15 demand partner domains from header bidding. You do not know which ones will win the auction.
2. Only preconnect if the script is not already discoverable. If you load your ad script with a normal <script async src="https://adnetwork.ext/script.js"> tag, the browser's preload scanner already finds it. A preconnect on top of that adds nothing.
3. Cached scripts make preconnects pointless. If the ad script is already in the browser cache (common for repeat visitors on ad-heavy sites), the preconnected TCP + TLS handshake goes unused and is pure overhead.
4. Fix your LCP first. If you are not passing the LCP threshold already, do not add ad preconnects. Preload your LCP image, set fetchpriority="high", and make sure it is not lazy loaded. Then revisit ad preconnects.

If you are unsure whether your LCP is properly optimized, check your field data in CoreDash or CrUX before adding preconnects.

If you still want to hint, use dns-prefetch instead

If you want some form of early connection hinting for ad servers but do not want the full bandwidth cost of a preconnect, use dns-prefetch instead. It only resolves DNS (20 to 120ms), skips TCP and TLS entirely, and does not create an idle connection competing for bandwidth.

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

This is a safer middle ground: you shave off the DNS lookup time without the risk of bandwidth contention during the critical rendering window.

What ad networks did I test?

These are all the preconnects that I have tested in the past year. If your ad network is not in the list, that does not mean you should preconnect. It just means I have not tested it for you. Set up an A/B test with Real User Monitoring and test what works best for your site.

<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">

The numbers behind it

According to the 2025 Web Almanac, 22% of pages use preconnect hints and only 62% of mobile origins pass LCP. That means a large chunk of the web is preconnecting to third-party origins while failing the very metric those preconnects can hurt.

The same data shows that 17.3% of mobile pages now use fetchpriority="high" on their LCP image. If you are in that 17.3%, your LCP image wins the priority race and a single ad preconnect is unlikely to cause problems. If you are not, start there.