Come ridurre le ricerche DNS e velocizzare le pagine

Ridurre le ricerche DNS è una di quelle ottimizzazioni che compaiono in ogni checklist sulle prestazioni e che quasi nessuno sa dimensionare. Ogni volta che il browser incontra un hostname nuovo (il tuo dominio, un CDN, un font, uno script di tracciamento) deve scoprire a quale indirizzo IP corrisponde, e fino a quel momento non scarica nulla da quel dominio. Secondo web.dev una ricerca DNS dura di solito circa 20-120 millisecondi: poco se è una sola, molto se si moltiplica per tutti i domini di una pagina.

Il tema è attuale perché le pagine non sono più fatte di un solo dominio. Il Web Almanac 2024 rileva che il 92% delle pagine usa almeno una terza parte, con una mediana di 27 terze parti nel primo milione di siti e di 66 nei primi mille (sono dati del 2024). Ogni terza parte si appoggia di solito a un hostname diverso dal tuo, e a cache vuota ogni hostname unico richiede la sua ricerca DNS.

Il consiglio classico (pochi hostname, ma non troppo pochi per non perdere download paralleli) nasce nell'epoca di HTTP/1.1 e oggi va aggiornato: con HTTP/2 e HTTP/3 quel limite non c'è più. Una premessa onesta, prima di cominciare: il guadagno si misura in decine o poche centinaia di millisecondi e di solito non è il primo problema di un sito lento, perché immagini e script pesano di più. Vale la pena intervenire, ma nell'ordine giusto e dopo aver misurato.

In questa guida vediamo cosa succede durante una ricerca DNS, quante ne puoi permetterti (una soglia ufficiale non esiste), come contarle con Chrome DevTools, quando usare dns-prefetch e preconnect e quali TTL scegliere. Troverai un metodo per decidere hostname per hostname, con un esempio su PrestaShop.

Risoluzione DNS e DNS lookup: cosa succede e quanto costa

Digitare un indirizzo, o caricare un'immagine da un dominio nuovo, avvia la risoluzione DNS: il browser chiede a un resolver (di solito quello del provider o del sistema operativo) quale IP corrisponde all'hostname, e solo dopo può aprire la connessione. Chi usa i tool di analisi chiama questo passaggio DNS lookup, e in Chrome lo vedi nella scheda Timing di ogni richiesta, alla voce "DNS Lookup".

Il costo va letto con precisione. Il TTFB (time to first byte) comprende redirect, service worker, DNS lookup, connessione e TLS, richiesta: per web.dev un valore di 0,8 secondi o meno è buono, sopra 1,8 secondi è scarso. Nel TTFB del documento entra però solo la ricerca DNS del dominio principale. Quelle dei domini terzi non rientrano in quel valore, ma ritardano le risorse che servono alla pagina, quindi possono pesare sulle metriche di caricamento. Non confondere le due cose quando leggi un report. Sui Core Web Vitals di un negozio online abbiamo approfondito come template e moduli rallentano il tuo sito.

Quante ricerche DNS sono troppe per una pagina web

Una soglia ufficiale non esiste: nessuno standard fissa un numero di ricerche DNS oltre il quale una pagina diventa lenta, e chi te ne propone uno sta presentando un'opinione. Il metodo che usiamo in Enthous è un criterio di lavoro: parti dalla visita a cache vuota, quando le ricerche DNS sono pari agli hostname unici della pagina, elenca gli hostname e per ognuno decidi se tenerlo, spostare la risorsa sul tuo dominio o toglierlo. Un font servito da un dominio esterno si può spesso ospitare in casa, mentre lo script di tracciamento che nessuno guarda da un anno si toglie.

Come contare hostname e tempi in Chrome DevTools

Apri DevTools, vai nel pannello Network e ricarica la pagina. Con un clic destro sull'intestazione delle colonne attiva Domain: ordinando per quella colonna vedi e conti gli hostname. Nel filtro puoi usare domain: seguito dal dominio per isolare le richieste di un hostname; selezionata una richiesta, la scheda Timing mostra "DNS Lookup", il tempo in cui il browser risolve l'IP. Per simulare un primo accesso non basta svuotare la cache con "Clear host cache" in about://net-internals/#dns: le connessioni keep-alive già aperte riusano il risultato, quindi chiudile anche con "Flush socket pools" in about://net-internals/#sockets, poi ricarica. Segna gli hostname con i tempi più alti e quelli che servono risorse importanti: sono i primi candidati.

Come ridurre le ricerche DNS senza penalizzare il download parallelo

Ridurre gli hostname ha un prezzo storico. Con HTTP/1.1 Chrome accoda le richieste oltre sei connessioni TCP per origine, quindi distribuire i file su più hostname permetteva più download in parallelo. La regola Yahoo/YSlow, che suggeriva di distribuire i componenti su 2-4 hostname, era il compromesso tra ricerche DNS e parallelismo: va letta come regola dell'era HTTP/1.1, non come soglia attuale. Il compromesso vale ancora sui siti serviti in HTTP/1.1, ma altrove non c'è più nulla da bilanciare.

HTTP/2 e HTTP/3: dividere i file su più hostname non serve

Con HTTP/2 il domain sharding (la distribuzione dei file su più domini) è per MDN un requisito obsoleto, e usare più domini è un anti-pattern perché le ricerche DNS rallentano il caricamento iniziale. Su questi protocolli le richieste viaggiano sulla stessa connessione, quindi un hostname creato solo per scaricare più file in parallelo aggiunge una ricerca DNS e nessun vantaggio.

Per capire dove sei, nel pannello Network attiva la colonna Protocol, sempre con il clic destro: h2 indica HTTP/2, h3 indica HTTP/3, http/1.1 significa che il compromesso con il download parallelo ti riguarda ancora.

Server media di PrestaShop: sottodomini images1, images2, images3

Nella pagina Prestazioni del back office di PrestaShop puoi configurare fino a 3 server media (_MEDIA_SERVER_1_, _2_ e _3_). La documentazione propone sottodomini come images1, images2 e images3 per aprire più connessioni, oppure un CDN. Ogni sottodominio però è un hostname in più, quindi una ricerca DNS in più. Se il tuo store è servito in HTTP/2 o HTTP/3, quei sottodomini non hanno senso: non serve compilarli; un CDN su un solo hostname resta invece una scelta valida. Se stai progettando o rifacendo un negozio, l'architettura degli hostname si decide insieme al resto, ed è parte del nostro lavoro sui progetti di sviluppo e-commerce per PMI.

Come implementare il DNS prefetch in HTML

Quando un hostname terzo serve davvero, puoi chiedere al browser di risolverlo in anticipo. Secondo la documentazione MDN su dns-prefetch funziona solo sui domini cross-origin, perché l'IP del tuo dominio è già risolto quando il browser legge il suggerimento, e se il browser non lo supporta il sito non si rompe. Nel tag head della pagina scrivi:

<link rel="dns-prefetch" href="https://fonts.e10f949fcaacdb195442bfb5062d59de-gdprlock/">

Lo stesso suggerimento può essere inviato come header HTTP:

Link: <https://fonts.e10f949fcaacdb195442bfb5062d59de-gdprlock/>; rel=dns-prefetch

Usalo per le terze parti che la pagina userà davvero e che non sono critiche, mai per il tuo dominio.

DNS prefetch o preconnect: quale scegliere

Il dns-prefetch risolve solo il dominio ed è adatto ai molti domini terzi non critici; il preconnect esegue DNS, connessione e cifratura ed è riservato ai più critici. Per web.dev anticipare le connessioni verso origini di terze parti importanti può velocizzare il caricamento di 100-500 ms, ma troppi preconnect consumano banda e possono ritardare altre risorse, e il browser chiude entro 10 secondi la connessione non usata.

Per le risorse in modalità anonima, come i font, serve l'attributo crossorigin, altrimenti il browser fa solo la ricerca DNS. Usa due tag separati, come in questo esempio per un font servito da un dominio di prova: scrivere rel="preconnect dns-prefetch" in un solo tag causa un bug su Safari che annulla il preconnect.

<link rel="preconnect" href="https://fonts.example.com/" crossorigin>
<link rel="dns-prefetch" href="https://fonts.example.com/">

DNS caching: tempi di TTL consigliati

La cache DNS lavora su più livelli: browser, sistema operativo e resolver. Chromium con il resolver di sistema tiene fresca la voce per 60 secondi, e con il resolver interno rispetta il TTL con un minimo di 60 secondi; Firefox usa 60 secondi di default (network.dnsCacheExpiration). Il TTL (time to live) è invece il valore del record DNS: per Cloudflare controlla per quanto il record resta in cache, e valori più lunghi migliorano la velocità di lookup ma rallentano la diffusione delle modifiche. Secondo AWS Route 53 un TTL più lungo, per esempio 172800 secondi (due giorni), riduce query e latenza; se cambi un dominio in uso, imposta prima 300 secondi e rialza il valore dopo la verifica.

Non esiste un TTL universale: la tabella è un criterio di lavoro Enthous, non uno standard. Un TTL basso, inoltre, non rende più veloce il sito: serve solo a far arrivare prima le modifiche, e sotto i 60 secondi nemmeno quello, perché Chromium trattiene comunque la voce per quel tempo. E il TTL non cambia il numero di hostname della pagina: per quello serve il lavoro descritto sopra.

Metti in pratica

Ridurre le ricerche DNS non è un intervento miracoloso: è un lavoro di pulizia che vale decine o poche centinaia di millisecondi e viene dopo immagini e script. Il percorso è lineare: conti gli hostname a cache vuota, decidi per ciascuno se tenerlo, spostarlo o toglierlo, verifichi il protocollo per capire se il download parallelo ti serve ancora, aggiungi dns-prefetch o preconnect solo dove la terza parte è necessaria e imposti i TTL con la regola dei 300 secondi prima di ogni modifica.

Se il sito è in Joomla, dopo gli hostname puoi leggere la nostra guida su come velocizzare un sito Joomla con il plugin JCH Optimize. Se stai rifacendo il sito, decidere gli hostname in fase di progetto è più semplice che correggerli dopo: è un tema da affrontare nella creazione del sito web. Se vuoi che qualcuno guardi il tuo caso, parlane con noi oppure richiedi una verifica tecnica degli hostname del tuo sito.