dns-prefetch non è preconnect

Il 1° novembre 2026 le due pagine MDN non descrivono lo stesso anticipo. dns-prefetch fa risolvere il nome. preconnect avvia la connessione: DNS e TCP, e su HTTPS anche il TLS. La prima è baseline da settembre 2025. La seconda da gennaio 2020. Non ho misurato un caricamento.

In breve: ho letto rel=dns-prefetch e rel=preconnect. Gli anchor in specifica sono # link-type-dns-prefetch e # link-type-preconnect. fetchpriority è un altro attributo, nel pezzo sul preload. Questa pagina è nel cluster Performance.

Solo il DNS

La pagina di dns-prefetch lo presenta come valore di rel sull’elemento link. È un suggerimento: l’utente probabilmente avrà bisogno di risorse da quell’origine, e il browser può migliorare l’esperienza risolvendo in anticipo il DNS di quell’origine. Il rinvio, «See Using dns-prefetch», sta nella stessa frase. Un tag di esempio, nel testo principale che ho letto, non c’è.

Il riquadro Baseline dice «2025 Newly available». Sotto: dal settembre 2025 la funzione opera sui dispositivi e sui browser più recenti, e potrebbe non funzionare su quelli più vecchi. La specifica indicata è HTML, anchor link-type-dns-prefetch.

DNS, TCP e TLS

La pagina di preconnect usa quasi la stessa premessa, poi cambia il verbo. Il suggerimento è di avviare in anticipo una connessione verso quell’origine. Il preconnect accelera i carichi futuri da quell’origine eseguendo in anticipo una parte o tutto l’handshake: DNS e TCP per HTTP, DNS, TCP e TLS per le origini HTTPS.

Il riquadro qui è un altro. «Baseline Widely available». La frase dice che è disponibile sui browser da gennaio 2020. Non da settembre 2025.

La stessa pagina scrive che il beneficio riguarda una richiesta HTTP cross-origin futura, una navigazione o una sottorisorsa. Sulla stessa origine non c’è beneficio, perché la connessione è già aperta. Un header equivalente all’esempio del tag è Link: <https://example.com>; rel="preconnect". Il tag mostrato è <link rel="preconnect" href="https://example.com" />.

Quando la pagina dice di non preconnectare tutto

Se la pagina deve collegarsi a molti domini di terze parti, preconnectarli tutti può essere controproducente. Il suggerimento, scrive MDN, va tenuto per le connessioni più critiche. Per le altre basta <link rel="dns-prefetch">, per risparmiare tempo sul primo passo, la risoluzione DNS.

È la pagina del preconnect a mettere i due valori uno accanto all’altro. La pagina del dns-prefetch, nel tratto che ho letto, non dice «non aprire il TCP». Lo si ricava perché descrive solo la risoluzione del nome, mentre l’altra elenca DNS, TCP e TLS. Non ho eseguito un confronto in DevTools.

Errori da evitare

• Trattare i due rel come sinonimi perché la premessa, «l’utente avrà bisogno di risorse da quell’origine», è quasi la stessa.

• Aspettarsi il TLS da un dns-prefetch. Il TLS sta nella frase del preconnect, e solo per le origini HTTPS.

• Mettere preconnect sulla stessa origine della pagina. La pagina dice che la connessione è già aperta.

• Preconnectare ogni dominio di terze parti. La pagina lo chiama controproducente e sposta gli altri su dns-prefetch.

• Leggere settembre 2025 anche sul preconnect. Quella data sta sul dns-prefetch. Il preconnect stampa gennaio 2020.

• Confonderli con fetchpriority o con loading=lazy. Sono altri pezzi, nello stesso cluster.

In sintesi

Il 1° novembre 2026 MDN tiene il DNS da una parte e la connessione dall’altra. Il primo suggerimento è il più giovane dei due, baseline 2025. Il secondo, più vecchio di cinque anni nel riquadro, fa anche TCP e, se l’origine è HTTPS, TLS. Non ho cronometrato niente.

Foto di copertina: Kim Scarborough, «Server Rack with Spaghetti-Like Mass of Network Cables», Wikimedia Commons, CC BY-SA 2.0. La descrizione del file è un rack di cavi. Non è un tag link e non è una risoluzione DNS.