Moet je preconnecten naar advertentienetwerken? Het hangt af van je LCP

Het korte antwoord: het hangt af van je LCP

Wanneer ik een site audit, kijk ik altijd naar resource hint-strategieën. Soms gebruiken klanten preconnect voor advertentienetwerken, in de hoop advertenties te versnellen en de omzet te verhogen. Of dit helpt of schaadt, hangt volledig af van één ding: is je Largest Contentful Paint-afbeelding al goed geoptimaliseerd?

Laatst beoordeeld door Arjen Karel in maart 2026

Als je LCP-afbeelding in de HTML staat (niet geïnjecteerd door JavaScript), niet lazy loaded is, en fetchpriority="high" heeft, zal de browser deze prioriteit geven, ongeacht waarnaar je verder preconnect. In dat geval is preconnecten naar je primaire advertentienetwerk-origin veilig en kan het je daadwerkelijk geld opleveren door advertenties een paar milliseconden sneller te serveren.

Wat een preconnect eigenlijk doet

Een preconnect hint vertelt de browser om een verbinding (DNS + TCP + TLS) naar een externe server te openen voordat deze daar daadwerkelijk een bestand van nodig heeft. Wanneer het bestand uiteindelijk wordt opgevraagd, is de verbinding al warm en begint de download onmiddellijk. Volgens web.dev kan dit 100 tot 500 ms besparen voor kritieke origins.

De valkuil: Chrome sluit elke preconnect die niet binnen 10 seconden wordt gebruikt. Als de verbinding ongebruikt blijft, heb je de volledige TCP + TLS-kosten voor niets betaald.

Hoe moderne advertentienetwerken werken

Je voegt een script toe, dat script voert een veiling uit (vaak met meerdere demand partners via header bidding via iets als Prebid.js), en de winnende advertentie laadt resources van servers waar je nog nooit van hebt gehoord. De keten kan vijf of meer domeinen diep zijn. Dit is belangrijk omdat je niet kunt preconnecten naar domeinen die je niet kent tijdens de HTML parse-tijd.

Wanneer preconnecten naar advertentienetwerken de prestaties schaadt

Als je LCP niet geoptimaliseerd is, zal preconnecten naar advertentienetwerken de zaken verergeren. Elke vroege verbinding concurreert om bandbreedte op een moment dat je belangrijkste resources (de LCP-afbeelding, stylesheets, fonts) nog niet zijn gedownload.

Kijk eens naar dit praktijkvoorbeeld. De klant had een ongeoptimaliseerde LCP en preconnectte naar meerdere advertentiedomeinen. Nadat ik de advertentie-preconnects had verwijderd, gingen ze in slechts 3 maanden tijd van 1,8 miljoen goede pagina's naar 6,24 miljoen goede pagina's.

De preconnects stalen bandbreedte van de LCP-afbeelding. Verwijder de concurrentie en de browser kan zijn vroege netwerktijd besteden aan wat er echt toe doet.

Wanneer preconnecten naar advertentienetwerken zinvol is

Als je LCP al snel is, is preconnecten naar de origin van je hoofd-advertentiescript prima. Hier is de checklist:

1. Je LCP-afbeelding staat in de HTML (niet geïnjecteerd door JavaScript of geladen vanuit CSS)
2. Je LCP-afbeelding is niet lazy loaded
3. Je LCP-afbeelding heeft fetchpriority="high"
4. Je LCP-afbeelding is ontdekbaar door de preload scanner van de browser

Wanneer alle vier waar zijn, zal de browser je LCP-afbeelding ophalen met de hoogste prioriteit, ongeacht preconnects. De kleine bandbreedtekosten van een extra TCP + TLS-handshake zullen je LCP niet beïnvloeden. En snellere advertenties betekenen meer impressies, hogere viewability scores en meer omzet.

Op sites die worden gemonitord door CoreDash, bespaart een preconnect naar een enkele advertentienetwerk-origin slechts een paar milliseconden aan verbindingstijd. Dat is niet genoeg om je LCP te beïnvloeden als de LCP-afbeelding al de juiste prioriteit heeft. Maar die paar milliseconden kunnen wel degelijk uitmaken voor ad fill rates.

Wees uiterst voorzichtig

Dit is geen vrijbrief om te preconnecten naar elk advertentiedomein dat je kunt vinden. De regels:

1. Preconnect slechts naar één origin: je primaire advertentiescript-domein. Preconnect niet naar 15 demand partner-domeinen vanuit header bidding. Je weet niet welke de veiling zullen winnen.
2. Preconnect alleen als het script niet al ontdekbaar is. Als je je advertentiescript laadt met een normale <script async src="https://adnetwork.ext/script.js"> tag, vindt de preload scanner van de browser deze al. Een preconnect daarbovenop voegt niets toe.
3. Gecachte scripts maken preconnects zinloos. Als het advertentiescript al in de browsercache zit (vaak het geval voor terugkerende bezoekers op sites met veel advertenties), blijft de gepreconnecte TCP + TLS-handshake ongebruikt en is het pure overhead.
4. Repareer eerst je LCP. Als je de LCP-drempelwaarde nog niet haalt, voeg dan geen advertentie-preconnects toe. Preload je LCP-afbeelding, stel fetchpriority="high" in, en zorg ervoor dat deze niet lazy loaded is. Kijk daarna pas weer naar advertentie-preconnects.

Als je toch een hint wilt geven, gebruik dan in plaats daarvan dns-prefetch

Als je een vorm van vroege verbinding-hinting voor advertentieservers wilt, maar niet de volledige bandbreedtekosten van een preconnect, gebruik dan in plaats daarvan dns-prefetch. Dit lost alleen DNS op (20 tot 120 ms), slaat TCP en TLS volledig over, en creëert geen inactieve verbinding die concurreert om bandbreedte.

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

Dit is een veiligere middenweg: je schaaft de DNS lookup-tijd eraf zonder het risico van bandbreedteconcurrentie tijdens het kritieke rendering window.

Welke advertentienetwerken heb ik getest?

Dit zijn alle preconnects die ik het afgelopen jaar heb getest. Als jouw advertentienetwerk niet in de lijst staat, betekent dit niet dat je moet preconnecten. Het betekent alleen dat ik het niet voor je heb getest. Zet een A/B-test op met Real User Monitoring en test wat het beste werkt voor jouw 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">

De cijfers erachter

Volgens de 2025 Web Almanac gebruikt 22% van de pagina's preconnect hints en slaagt slechts 62% van de mobiele origins voor LCP. Dat betekent dat een groot deel van het web preconnect naar third-party origins, terwijl ze falen voor precies die metric die door die preconnects kan worden geschaad.

De zelfde data toont aan dat 17,3% van de mobiele pagina's nu fetchpriority="high" gebruikt op hun LCP-afbeelding. Als je in die 17,3% zit, wint jouw LCP-afbeelding de prioriteitsrace en is het onwaarschijnlijk dat een enkele advertentie-preconnect problemen veroorzaakt. Als dat niet zo is, begin dan daar.