Dovresti usare preconnect per gli ad network? Dipende dal tuo LCP

La risposta breve: dipende dal tuo LCP

Ogni volta che faccio l'audit di un sito, controllo sempre le strategie dei resource hint. A volte i clienti usano preconnect per gli ad network, sperando di velocizzare gli annunci e aumentare le entrate. Che questo aiuti o danneggi dipende interamente da una cosa: la tua immagine Largest Contentful Paint è già adeguatamente ottimizzata?

Ultima revisione di Arjen Karel a marzo 2026

Se la tua immagine LCP si trova nell'HTML (non iniettata tramite JavaScript), non usa il lazy loading e ha fetchpriority="high", il browser le darà la priorità indipendentemente da cos'altro tu abbia in preconnect. In quel caso, usare il preconnect per l'origine principale del tuo ad network è sicuro e può effettivamente farti guadagnare servendo gli annunci qualche millisecondo più velocemente.

Ma se il tuo LCP non è ottimizzato, ogni preconnect che aggiungi compete per la larghezza di banda e i cicli della CPU nel peggior momento possibile. Ho visto questo approccio fallire su siti da 5.000 a 15 milioni di visualizzazioni di pagina giornaliere.

Cosa fa effettivamente un preconnect

Un hint preconnect dice al browser di aprire una connessione (DNS + TCP + TLS) verso un server esterno prima che abbia effettivamente bisogno di un file da lì. Quando il file viene finalmente richiesto, la connessione è già attiva e il download inizia immediatamente. Secondo web.dev, questo può far risparmiare da 100 a 500 ms per le origini critiche.

L'inghippo: Chrome chiude qualsiasi preconnect che non viene utilizzato entro 10 secondi. Se la connessione rimane inutilizzata, hai pagato l'intero costo di TCP + TLS per niente.

Come funzionano i moderni ad network

Includi uno script, quello script esegue un'asta (spesso con più partner di domanda tramite header bidding attraverso strumenti come Prebid.js) e l'annuncio vincente carica risorse da server di cui non hai mai sentito parlare. La catena può essere profonda cinque o più domini. Questo è importante perché non puoi usare preconnect verso domini che non conosci al momento del parsing dell'HTML.

Quando usare preconnect per gli ad network danneggia le prestazioni

Se il tuo LCP non è ottimizzato, usare preconnect per gli ad network peggiorerà le cose. Ogni connessione anticipata compete per la larghezza di banda in un momento in cui le tue risorse più importanti (l'immagine LCP, i fogli di stile, i font) non sono ancora state scaricate.

Dai un'occhiata a questo esempio reale. Il cliente aveva un LCP non ottimizzato e usava preconnect per più domini pubblicitari. Dopo aver rimosso i preconnect degli annunci, sono passati da 1,8 milioni di pagine buone a 6,24 milioni di pagine buone in soli 3 mesi.

I preconnect stavano rubando larghezza di banda all'immagine LCP. Rimuovi la competizione e il browser potrà dedicare il suo tempo di rete iniziale a ciò che conta davvero.

Quando usare preconnect per gli ad network ha senso

Se il tuo LCP è già veloce, usare preconnect per l'origine principale dello script dei tuoi annunci va bene. Ecco la checklist:

1. La tua immagine LCP si trova nell'HTML (non iniettata tramite JavaScript o caricata dal CSS)
2. La tua immagine LCP non usa il lazy loading
3. La tua immagine LCP ha fetchpriority="high"
4. La tua immagine LCP è rilevabile dal preload scanner del browser

Quando tutte e quattro le condizioni sono vere, il browser recupererà la tua immagine LCP con la massima priorità indipendentemente dai preconnect. Il piccolo costo in larghezza di banda di un handshake TCP + TLS aggiuntivo non sposterà il tuo LCP. Inoltre, annunci più veloci significano più impression, punteggi di viewability più alti e maggiori entrate.

Tra i siti monitorati da CoreDash, un preconnect verso l'origine di un singolo ad network fa risparmiare solo pochi millisecondi di tempo di connessione. Non è sufficiente a influenzare il tuo LCP se l'immagine LCP ha già la priorità corretta. Ma quei pochi millisecondi possono fare la differenza per gli ad fill rate.

Fai molta attenzione

Questo non è un assegno in bianco per usare preconnect su ogni dominio pubblicitario che riesci a trovare. Le regole:

1. Usa preconnect verso una sola origine: il dominio principale dello script dei tuoi annunci. Non usare preconnect verso 15 domini di demand partner dall'header bidding. Non sai quali vinceranno l'asta.
2. Usa preconnect solo se lo script non è già rilevabile. Se carichi lo script dei tuoi annunci con un normale tag <script async src="https://adnetwork.ext/script.js">, il preload scanner del browser lo trova già. Un preconnect in aggiunta a questo non aggiunge nulla.
3. Gli script in cache rendono i preconnect inutili. Se lo script degli annunci è già nella cache del browser (comune per i visitatori di ritorno su siti ricchi di annunci), l'handshake TCP + TLS pre-connesso rimane inutilizzato ed è puro overhead.
4. Prima sistema il tuo LCP. Se non stai già superando la soglia LCP, non aggiungere preconnect per gli annunci. Fai il preload della tua immagine LCP, imposta fetchpriority="high" e assicurati che non usi il lazy loading. Dopodiché, riconsidera i preconnect per gli annunci.

Se non sei sicuro che il tuo LCP sia adeguatamente ottimizzato, controlla i tuoi dati sul campo in CoreDash o CrUX prima di aggiungere i preconnect.

Se vuoi comunque usare un hint, usa invece dns-prefetch

Se desideri una qualche forma di hint di connessione anticipata per gli ad server ma non vuoi sostenere l'intero costo in larghezza di banda di un preconnect, usa invece dns-prefetch. Risolve solo il DNS (da 20 a 120 ms), salta completamente TCP e TLS e non crea una connessione inattiva in competizione per la larghezza di banda.

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

Questa è una via di mezzo più sicura: riduci il tempo di lookup DNS senza il rischio di contesa della larghezza di banda durante la finestra di rendering critica.

Quali ad network ho testato?

Questi sono tutti i preconnect che ho testato nell'ultimo anno. Se il tuo ad network non è nella lista, non significa che dovresti usare preconnect. Significa solo che non l'ho testato per te. Imposta un A/B test con il Real User Monitoring e verifica cosa funziona meglio per il tuo sito.

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

I numeri alla base

Secondo il Web Almanac 2025, il 22% delle pagine utilizza hint di preconnect e solo il 62% delle origini mobile supera l'LCP. Ciò significa che una grande fetta del web utilizza preconnect verso origini di terze parti fallendo al contempo proprio la metrica che quei preconnect possono danneggiare.

Gli stessi dati mostrano che il 17,3% delle pagine mobile ora utilizza fetchpriority="high" sulla propria immagine LCP. Se fai parte di quel 17,3%, la tua immagine LCP vince la gara di priorità e un singolo preconnect per un annuncio difficilmente causerà problemi. Se non ne fai parte, inizia da lì.