Minimizzare la Sottoparte della Durata del DNS del Time to First Byte

Minimizzare la Sottoparte della Durata del DNS del Time to First Byte

Questo articolo fa parte della nostra guida sul Time to First Byte (TTFB). La durata del DNS è la terza sottoparte del TTFB e rappresenta il tempo che il browser impiega per risolvere il tuo nome a dominio in un indirizzo IP. Per i visitatori al primo accesso che 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 sottoparti:

• Attesa + Redirect (o durata dell'attesa)
• Worker + Cache (o durata della cache)
• DNS (o durata del DNS)
• Connessione (o durata della connessione)
• Richiesta (o durata della richiesta)

Vuoi ottimizzare il Time to First Byte? Questo articolo fornisce un'analisi approfondita della parte del Time to First Byte relativa alla durata del DNS. Se stai cercando di comprendere o correggere il Time to First Byte e non sai cosa significa la durata del DNS, ti preghiamo di leggere cos'è il Time to First Byte e correggere e identificare i problemi del Time to First Byte prima di iniziare con questo articolo.

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

La parte della Durata del DNS 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é noi umani troviamo più facile ricordare nomi a dominio come "www.example.com", mentre i computer richiedono indirizzi IP numerici per connettersi tra loro.

Come Funziona il DNS?

Le richieste DNS sono incluse nella misurazione del TTFB. Questo significa che il tempo necessario per il completamento della richiesta DNS è fattorizzato nel punteggio complessivo del TTFB.

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

• Viene controllata la cache DNS del browser: Prima di effettuare una query DNS, il browser controlla prima la propria cache DNS per vedere se possiede già l'indirizzo IP del dominio richiesto. I browser moderni memorizzano in cache i record DNS per un determinato periodo per migliorare le prestazioni riducendo la necessità di ricerche DNS ripetute. Se il record viene trovato nella cache del browser, il browser può usarlo immediatamente senza ulteriori query.
• Viene controllata la cache di Sistema dell'OS: Se la cache del browser non contiene il record DNS necessario, la richiesta viene passata al resolver 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 resolver DNS, tipicamente fornito dall'Internet Service Provider (ISP) dell'utente. Questo resolver funge da intermediario, gestendo il processo di interrogazione di altri server DNS per trovare l'indirizzo IP.
  • Root Name Server: Il resolver contatta prima un root name server, che lo indirizza al server di dominio di primo livello (TLD) appropriato in base all'estensione del dominio (es. ".com", ".org").
  • TLD Name Server: Il server TLD indirizza poi il resolver all'authoritative name server per il dominio specifico.
  • Authoritative Name Server: Questo server detiene i record DNS per il dominio e fornisce al resolver l'indirizzo IP.
• Restituzione dell'Indirizzo IP: Una volta che il resolver DNS ottiene l'indirizzo IP dal server autoritativo, restituisce queste informazioni al browser. Il browser può quindi iniziare una connessione al server utilizzando l'indirizzo IP per caricare la pagina web richiesta.

Come Impatta il DNS sul Time to First Byte?

Per i visitatori abituali, la ricerca DNS è tipicamente memorizzata in cache nel browser o nell'OS, riducendo la durata del DNS quasi a zero. Per i visitatori al primo accesso, tuttavia, la ricerca DNS ricorsiva completa deve terminare prima che il browser possa procedere alla fase di connessione TCP. Questo è il motivo per cui il TTFB è spesso misurabilmente peggiore per i nuovi visitatori rispetto a quelli di ritorno.

Usa 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 il resource hint dns-prefetch:

<!-- DNS prefetch for third-party domains -->
<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 origini di terze parti critiche in cui sai che avrai anche bisogno di stabilire una connessione TCP e TLS, usa invece preconnect, che include la risoluzione DNS più l'handshake di 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">

Posiziona questi hint nell'<head> del tuo HTML il prima possibile. Aggiungi hint solo per i domini che la tua pagina utilizza effettivamente; aggiungere hint per domini non utilizzati spreca risorse del browser. Per ulteriori tecniche di ottimizzazione relative al caricamento delle risorse, consulta la nostra guida su 103 Early Hints.

Come Minimizzare l'Impatto del DNS sul TTFB

Usa 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 hanno estese infrastrutture globali. Tali infrastrutture riducono la distanza fisica tra gli utenti e i server DNS, rimuovendo una parte importante della latenza coinvolta nelle richieste DNS.

Ecco un confronto tra i provider DNS popolari e i loro tempi di risposta tipici:

La differenza tra un provider DNS premium e un DNS di base del registrar può essere da 40 a 90 millisecondi per ricerca. Per i visitatori al primo accesso, questo si traduce direttamente in un TTFB più veloce. Per imparare a configurare Cloudflare come tuo provider DNS e CDN, leggi la nostra guida alla configurazione di Cloudflare.

Ottimizza il Time to Live della Cache DNS

La cache DNS memorizza i risultati delle query DNS localmente, riducendo la necessità di ricerche ripetute. Impostando valori di Time-To-Live (TTL) "ottimali" 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 ricerche DNS più frequenti. Valori TTL più alti significano che i record vengono memorizzati nella cache più a lungo, riducendo le ricerche DNS ma rendendo le modifiche DNS più lente nella propagazione. Il giusto TTL dipende da quanto frequentemente modifichi i tuoi record DNS e da quanto apprezzi la velocità di ricerca DNS rispetto alla flessibilità.

Quali Sono le Impostazioni TTL DNS Ottimali?

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. Questo assicura che dopo la modifica, gli utenti rileveranno rapidamente il nuovo indirizzo IP. Una volta completata e verificata la migrazione, aumenta nuovamente il TTL a un valore più alto per ridurre la frequenza delle ricerche DNS.

SUGGERIMENTO: se stai utilizzando i 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 (apice), risolvendolo di fatto in un indirizzo IP senza violare gli standard DNS. Ciò elimina una ricerca DNS aggiuntiva che altrimenti sarebbe necessaria per risolvere il CNAME nel suo target, e poi il target nel suo indirizzo IP.

DNS over HTTPS (DoH) e DNS over TLS (DoT)

Le tradizionali query DNS vengono inviate in chiaro tramite UDP, il che significa che possono essere intercettate, modificate o bloccate da intermediari (come ISP o operatori di rete). Il DNS over HTTPS (DoH) e il DNS over TLS (DoT) crittografano le query DNS, migliorando sia la privacy che la sicurezza.

Mentre DoH e DoT affrontano principalmente le preoccupazioni 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 (TLS handshake). 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 aggira 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 è possibile controllare se i visitatori utilizzano DoH o DoT (è un'impostazione a livello di browser e di sistema operativo). Tuttavia, puoi assicurarti che il tuo provider DNS autoritativo supporti DNSSEC, che fornisce un livello complementare di verifica per le risposte DNS indipendentemente dalla crittografia del trasporto.

Misurare la Durata del DNS con JavaScript

Puoi misurare la sottoparte della durata del DNS 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('High DNS duration detected. Consider:');
    console.warn('1. Switching to a premium DNS provider');
    console.warn('2. Increasing DNS TTL values');
    console.warn('3. Using dns-prefetch for third-party domains');
  }
}).observe({
  type: 'navigation',
  buffered: true
});

Una durata del DNS di 0ms nei tuoi dati RUM indica in genere che la ricerca DNS è stata servita dalla cache del browser o dell'OS (uno scenario di visitatore di ritorno). Valori superiori a 50ms suggeriscono che l'utente ha dovuto eseguire una ricerca DNS ricorsiva completa, il che è comune per i visitatori al primo accesso.

Come Misurare i Problemi di TTFB Causati da Ricerche DNS Lente

Per scoprire l'impatto che gli utenti reali sperimentano causato dalla latenza DNS, dovrai utilizzare uno strumento RUM come CoreDash. Il Real User Monitoring ti permetterà di tracciare i Core Web Vitals in maggiore dettaglio 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

Per le tecniche di ottimizzazione correlate che completano l'ottimizzazione DNS, esplora queste guide:

• 103 Early Hints: invia resource hints prima che la risposta completa sia pronta, consentendo al browser di iniziare la risoluzione DNS e le connessioni per le risorse critiche ancora prima.
• Configurare Cloudflare per le Prestazioni: usa Cloudflare sia come tuo provider DNS che come CDN, combinando una rapida risoluzione DNS con edge caching e supporto HTTP/3.

Sottoparti del TTFB: Articoli di Approfondimento

La durata del DNS è una delle cinque sottoparti del TTFB. Esplora le altre sottoparti per comprendere il quadro completo:

• Correggere e Identificare i Problemi di TTFB: il punto di partenza diagnostico per tutte le ottimizzazioni del TTFB.
• Durata dell'Attesa (Waiting Duration): redirect, accodamento del browser e ottimizzazione HSTS.
• Durata della Cache (Cache Duration): prestazioni dei service worker, ricerche nella cache del browser e bfcache.
• Durata della Connessione (Connection Duration): handshake TCP, ottimizzazione TLS, HTTP/3 e preconnect.