Ridurre la sottocomponente DNS Duration del Time to First Byte

La DNS duration misura le ricerche DNS del browser. Scopri come scegliere un provider DNS veloce, ottimizzare le impostazioni TTL, usare dns-prefetch e capire il DNS over HTTPS per ridurre il TTFB.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-05
[include]breadcrumbs.html[\/include]

Ridurre la sottocomponente DNS Duration del Time to First Byte

Questo articolo fa parte della nostra guida sul [url=\/core-web-vitals\/time-to-first-byte]Time to First Byte (TTFB)[\/url]. La DNS duration è la terza sottocomponente del TTFB e rappresenta il tempo che il browser impiega per risolvere il nome del tuo dominio in un indirizzo IP. Per i visitatori che arrivano per la prima volta e non hanno un record DNS in cache, la ricerca DNS può aggiungere da 20 a 200 millisecondi al TTFB, a seconda del provider DNS, della posizione geografica dell'utente e delle impostazioni TTL dei tuoi record DNS.

Il Time to First Byte (TTFB) può essere suddiviso nelle seguenti sottocomponenti:

  • [url=\/core-web-vitals\/time-to-first-byte\/waitingduration]Waiting + Redirect (o waiting duration)[\/url]
  • [url=\/core-web-vitals\/time-to-first-byte\/cacheduration]Worker + Cache (o cache duration)[\/url]
  • DNS (o DNS duration)
  • [url=\/core-web-vitals\/time-to-first-byte\/connectionduration]Connection (o connection duration)[\/url]
  • [url=\/core-web-vitals\/time-to-first-byte\/requestduration]Request (o request duration)[\/url]

    Vuoi ottimizzare il Time to First Byte? Questo articolo tratta la parte relativa alla DNS duration del Time to First Byte. Se vuoi capire o risolvere i problemi del Time to First Byte e non sai cosa significhi DNS duration, leggi [url=\/core-web-vitals\/time-to-first-byte]cos'è il Time to First Byte[\/url] e [url=\/core-web-vitals\/time-to-first-byte\/fix-and-identify]come identificare e risolvere i problemi di Time to First Byte[\/url] prima di iniziare questo articolo.

    Soluzione rapida per il DNS: se riscontri latenza DNS nel Time to First Byte, passa a un provider DNS premium e aggiorna le tue impostazioni TTL!

    La parte DNS Duration del Time to First Byte consiste nel tempo in cui il browser cerca l'indirizzo internet (IP) del tuo sito. Abbiamo bisogno delle ricerche DNS perché per noi umani è più facile ricordare nomi di dominio come "www.example.com", mentre i computer richiedono indirizzi IP numerici per connettersi tra loro.

    [include]toc.html[\/include]

    Come funziona il DNS?

    Le richieste DNS sono incluse nella misurazione del TTFB. Ciò significa che il tempo impiegato per il completamento della richiesta DNS viene calcolato nel punteggio TTFB complessivo.

    Quando viene richiesta una pagina, questi sono i passaggi che il tuo browser compie per convertire il nome del dominio in un indirizzo IP:

    • Viene controllata la cache DNS del browser: prima di effettuare una query DNS, il browser controlla innanzitutto la propria cache DNS per vedere se possiede già l'indirizzo IP per il dominio richiesto. I browser moderni memorizzano i record DNS per un periodo prestabilito per migliorare le prestazioni riducendo la necessità di ricerche DNS ripetute. Se il record viene trovato nella cache del browser, quest'ultimo può utilizzarlo immediatamente senza ulteriori query.
    • Viene controllata la cache del sistema operativo: se la cache del browser non contiene il record DNS necessario, la richiesta viene passata al risolutore DNS del sistema operativo, spesso chiamato "stub resolver". Anche l'OS mantiene una cache DNS e la controllerà prima di inviare qualsiasi richiesta di rete.
    • Query DNS: se il record DNS non viene trovato né nella cache del browser né in quella dell'OS, viene inviata una query DNS ricorsiva a un risolutore DNS, in genere fornito dall'Internet Service Provider (ISP) dell'utente. Questo risolutore funge da intermediario, gestendo il processo di interrogazione di altri server DNS per trovare l'indirizzo IP.
      • Root Name Server: il risolutore contatta innanzitutto un root name server, che lo indirizza al server del dominio di primo livello (TLD) appropriato in base all'estensione del dominio (ad es. ".com", ".org").
      • TLD Name Server: il server TLD indirizza quindi il risolutore al name server autorevole per lo specifico dominio.
      • Name Server autorevole: questo server conserva i record DNS per il dominio e fornisce al risolutore l'indirizzo IP.
      • Ritorno dell'indirizzo IP: una volta che il risolutore DNS ottiene l'indirizzo IP dal server autorevole, restituisce queste informazioni al browser. Il browser può quindi avviare una connessione al server utilizzando l'indirizzo IP per caricare la pagina web richiesta.

        In che modo il DNS influisce sul Time to First Byte?
        La ricerca DNS può rallentare il Time to First Byte a causa della latenza di rete (il tempo necessario per connettersi al Name Server in questo caso), della qualità e della velocità del name server autorevole, o del tempo di cache DNS (poiché le query DNS in cache sono molto più veloci delle query DNS non in cache).

        Per i visitatori ricorrenti, la ricerca DNS è tipicamente memorizzata nella cache del browser o dell'OS, riducendo la durata del DNS a quasi zero. Per i visitatori che arrivano per la prima volta, tuttavia, la ricerca DNS ricorsiva completa deve terminare prima che il browser possa procedere alla fase di connessione TCP. Ecco perché il TTFB è spesso misurabilmente peggiore per i nuovi visitatori rispetto a quelli di ritorno.

        Usare dns-prefetch e preconnect per i domini di terze parti

        Se la tua pagina carica risorse da domini di terze parti (come analytics, font o sottodomini CDN), il browser deve risolvere il DNS per ogni dominio separatamente. Puoi istruire il browser ad avviare la risoluzione DNS in anticipo utilizzando l'hint di risorsa dns-prefetch: 

        <!-- DNS prefetch per domini di terze parti -->
<link rel="dns-prefetch" href="https:\/\/fonts.googleapis.com">
<link rel="dns-prefetch" href="https:\/\/cdn.example.com">
<link rel="dns-prefetch" href="https:\/\/analytics.example.com">
                
        Per le origini di terze parti critiche in cui sai che dovrai anche stabilire una connessione TCP e TLS, usa invece preconnect, che include la risoluzione DNS più l'handshake della connessione:

        <link rel="preconnect" href="https:\/\/fonts.googleapis.com">
<link rel="preconnect" href="https:\/\/fonts.gstatic.com" crossorigin>
                
        Usa dns-prefetch come fallback per i browser che non supportano preconnect:

        <link rel="preconnect" href="https:\/\/fonts.googleapis.com">
<link rel="dns-prefetch" href="https:\/\/fonts.googleapis.com">
                
        Inserisci questi hint nell'<head> del tuo HTML il più presto possibile. Aggiungi hint solo per i domini che la tua pagina utilizza effettivamente; aggiungere hint per domini inutilizzati spreca risorse del browser. Per ulteriori tecniche di ottimizzazione relative al caricamento delle risorse, consulta la nostra guida sui [url=\/pagespeed\/103-early-hints]103 Early Hints[\/url].

                
        Come ridurre al minimo l'impatto del DNS sul TTFB
                

        Usare un provider DNS veloce
                
        Alcuni provider DNS sono più veloci di altri. Scegliere un provider DNS veloce e affidabile è uno dei modi più semplici per ridurre la latenza DNS. I provider DNS premium come Cloudflare, Amazon Route 53 e Google Cloud DNS gestiscono server in centinaia di località in tutto il mondo. Più il server DNS è vicino al tuo utente, più veloce sarà la ricerca.
                
        Ecco un confronto tra i provider DNS più popolari e i loro tempi di risposta tipici:
                
        Provider DNS
                            Tempo di risposta tipico
                            PoP globali
                            Caratteristiche degne di nota
                        
                    
                    
        Cloudflare DNS
                            ~11ms
                            300+
                            Piano gratuito disponibile, DNSSEC, CNAME flattening
                        
                        
        Amazon Route 53
                            ~20ms
                            100+
                            Controlli di integrità, routing basato sulla latenza, geolocalizzazione
                        
                        
        Google Cloud DNS
                            ~15ms
                            Anycast globale
                            SLA di uptime al 100%, DNSSEC
                        
                        
        NS1
                            ~15ms
                            25+
                            Catene di filtri, routing DNS intelligente
                        
                        
        DNS tipico ISP\/registrar
                            da ~50 a 100ms
                            Limitati
                            Solo funzionalità di base
                        
                    
                
                
        La differenza tra un provider DNS premium e un DNS di base di un registrar può essere di 40-90 millisecondi per ricerca (fonte: benchmark [url=https:\/\/www.dnsperf.com\/]DNSPerf[\/url]). Per i visitatori che arrivano per la prima volta, questo si traduce direttamente in un TTFB più veloce. Per scoprire come configurare Cloudflare come provider DNS e CDN, leggi la nostra [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]guida alla configurazione di Cloudflare[\/url].

                
                
        Ottimizzare il Time To Live della cache DNS
                
        La memorizzazione nella cache DNS conserva i risultati delle query DNS a livello locale, riducendo la necessità di ricerche ripetute. Impostando valori "ottimali" di Time-To-Live (TTL) per i record DNS, puoi controllare per quanto tempo questi record vengono memorizzati nella cache.
                
        Valori TTL più bassi significano che i record scadono prima, causando query DNS più frequenti. Valori TTL più alti significano che i record vengono memorizzati nella cache più a lungo, riducendo le query DNS ma rallentando la propagazione delle modifiche DNS. Il TTL corretto dipende dalla frequenza con cui modifichi i record DNS e da quanto apprezzi la velocità di ricerca DNS rispetto alla flessibilità.

                
        Quali sono le impostazioni TTL DNS ottimali?
                
        
                    
        Record A e AAAA (record di indirizzi IP): per la maggior parte dei siti web: da 5 minuti a 1 ora. Per i siti web statici che non cambiano frequentemente: da 1 a 24 ore.
                    
        Record CNAME: tipicamente 24 ore.
                    
        Record TXT e MX: circa 12 ore.
                    
        Record NS: TTL più lunghi, come 1-2 giorni, poiché sono critici e generalmente statici.
                    
        SOA e altri record statici: TTL più lunghi, fino a pochi giorni.
                
                

        Quando pianifichi una migrazione DNS o un cambio di server, abbassa temporaneamente il tuo TTL a 5 minuti (300 secondi) almeno 24 ore prima di apportare la modifica. Ciò garantisce che, dopo il cambiamento, gli utenti acquisiscano rapidamente il nuovo indirizzo IP. Una volta che la migrazione è completata e verificata, aumenta di nuovo il TTL a un valore più alto per ridurre la frequenza delle ricerche DNS.

                
        CONSIGLIO: se stai usando record CNAME, considera l'implementazione del CNAME flattening. Il CNAME flattening è una tecnica che ti consente di utilizzare un record CNAME a livello di dominio radice (apex), risolvendolo efficacemente in un indirizzo IP senza violare gli standard DNS. Ciò elimina una ricerca DNS extra che sarebbe altrimenti necessaria per risolvere il CNAME nel suo target, quindi il target nel suo indirizzo IP.

                
                
        DNS over HTTPS (DoH) e DNS over TLS (DoT)
                
        Le query DNS tradizionali vengono inviate in chiaro su UDP, il che significa che possono essere intercettate, modificate o bloccate dagli intermediari (come ISP o operatori di rete). Il DNS over HTTPS (DoH) e il DNS over TLS (DoT) criptano le query DNS, migliorando sia la privacy che la sicurezza.
                
        Sebbene DoH e DoT affrontino principalmente problemi di sicurezza e privacy, possono anche influire sulle prestazioni della risoluzione DNS:
                
        • Impatto sulla latenza: l'overhead della crittografia aggiunge una piccola quantità di latenza alla connessione DNS iniziale (handshake TLS). Tuttavia, poiché le connessioni DoH\/DoT sono persistenti e riutilizzate, le query successive sulla stessa connessione sono spesso più veloci del DNS tradizionale.
                    
        • Interferenza dell'ISP: alcuni ISP iniettano le proprie risposte DNS o rallentano le query DNS per i non clienti. Il DoH bypassa completamente questa interferenza, il che può effettivamente migliorare il tempo di risoluzione DNS per gli utenti interessati.
                    
        • Supporto dei browser: i browser moderni (Chrome, Firefox, Edge, Safari) supportano tutti il DoH. Nella maggior parte dei casi, il provider DNS predefinito del browser utilizza già il DoH quando disponibile.
                
                
          Per i proprietari di siti web, non puoi controllare se i tuoi visitatori utilizzino DoH o DoT (si tratta di un'impostazione a livello di browser e OS). Tuttavia, puoi assicurarti che il tuo provider DNS autorevole supporti DNSSEC, che fornisce un livello complementare di verifica per le risposte DNS indipendentemente dalla crittografia del trasporto.

                
          Misurare la DNS Duration con JavaScript
                
          Puoi misurare la sottocomponente DNS duration del TTFB direttamente nel browser utilizzando la Navigation Timing API:

          new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;

  console.log('DNS Duration:', dnsDuration.toFixed(0), 'ms');

  if (dnsDuration > 50) {
    console.warn('Rilevata durata DNS elevata. Considera di:');
    console.warn('1. Passare a un provider DNS premium');
    console.warn('2. Aumentare i valori TTL del DNS');
    console.warn('3. Usare dns-prefetch per i domini di terze parti');
  }
}).observe({
  type: 'navigation',
  buffered: true
});
                
          Una durata DNS di 0ms nei tuoi dati RUM indica tipicamente che la ricerca DNS è stata servita dalla cache del browser o dell'OS (scenario di un visitatore ricorrente). Valori superiori a 50ms suggeriscono che l'utente ha dovuto eseguire una ricerca DNS ricorsiva completa, comune per i visitatori che arrivano per la prima volta.

                
          Come misurare i problemi di TTFB causati da ricerche DNS lente
                
          Per trovare l'impatto che gli utenti reali sperimentano a causa della latenza DNS, dovrai utilizzare uno strumento RUM come CoreDash. Il Real User Monitoring ti consentirà di monitorare i Core Web Vitals in modo più dettagliato e senza il ritardo di 28 giorni di Google.
                
          In CoreDash, clicca su "Time to First Byte breakdown" per visualizzare la parte DNS del Time to First Byte.
                
          Ulteriori letture: guide all'ottimizzazione
                
          Guide correlate: