Minimiser la DNS Duration du Time to First Byte

Minimiser la DNS Duration du Time to First Byte

Cet article fait partie de notre guide sur le Time to First Byte (TTFB). La DNS duration est la troisième sous-partie du TTFB et représente le temps que le navigateur passe à résoudre votre nom de domaine en une adresse IP. Pour les nouveaux visiteurs qui n'ont pas d'enregistrement DNS en cache, la recherche DNS peut ajouter 20 à 200 millisecondes au TTFB selon le fournisseur DNS, la situation géographique de l'utilisateur et les paramètres TTL de vos enregistrements DNS.

Le Time to First Byte (TTFB) peut être décomposé en les sous-parties suivantes :

• Waiting + Redirect (ou waiting duration)
• Worker + Cache (ou cache duration)
• DNS (ou DNS duration)
• Connection (ou connection duration)
• Request (ou request duration)

Vous cherchez à optimiser le Time to First Byte ? Cet article couvre la partie DNS duration du Time to First Byte. Si vous cherchez à comprendre ou à corriger le Time to First Byte et que vous ne savez pas ce que signifie DNS duration, veuillez lire qu'est-ce que le Time to First Byte et identifier et corriger les problèmes de Time to First Byte avant de commencer cet article.

Correctif rapide DNS : si vous rencontrez une latence DNS dans le Time to First Byte, passez à un fournisseur DNS premium et mettez à jour vos paramètres TTL !

La partie DNS Duration du Time to First Byte correspond au temps pendant lequel le navigateur recherche l'adresse Internet (IP) de votre site. Nous avons besoin des recherches DNS car nous, les humains, trouvons plus facile de mémoriser des noms de domaine comme « www.example.com » alors que les ordinateurs ont besoin d'adresses IP numériques pour se connecter entre eux.

Comment fonctionne le DNS ?

Les requêtes DNS sont incluses dans la mesure du TTFB. Cela signifie que le temps nécessaire pour que la requête DNS aboutisse est pris en compte dans le score global du TTFB.

Lorsqu'une page est demandée, voici les étapes suivies par votre navigateur pour convertir le nom de domaine en adresse IP :

• Le cache DNS du navigateur est vérifié : Avant d'effectuer une requête DNS, le navigateur vérifie d'abord son propre cache DNS pour voir s'il possède déjà l'adresse IP du domaine demandé. Les navigateurs modernes mettent en cache les enregistrements DNS pendant une période déterminée pour améliorer les performances en réduisant le besoin de recherches DNS répétées. Si l'enregistrement est trouvé dans le cache du navigateur, celui-ci peut l'utiliser immédiatement sans autres requêtes.
• Le cache système de l'OS est vérifié : Si le cache du navigateur ne contient pas l'enregistrement DNS nécessaire, la requête est transmise au résolveur DNS du système d'exploitation, souvent appelé « résolveur stub ». L'OS maintient également un cache DNS et le vérifiera avant d'envoyer toute requête réseau.
• Requête DNS : Si l'enregistrement DNS n'est trouvé ni dans le cache du navigateur ni dans celui de l'OS, une requête DNS récursive est envoyée à un résolveur DNS, généralement fourni par le fournisseur d'accès Internet (FAI) de l'utilisateur. Ce résolveur agit comme un intermédiaire, gérant le processus de requête auprès d'autres serveurs DNS pour trouver l'adresse IP.
  • Serveurs racines (Root Name Servers) : Le résolveur contacte d'abord un serveur racine, qui le dirige vers le serveur de domaine de premier niveau (TLD) approprié en fonction de l'extension du domaine (ex : « .com », « .org »).
  • Serveurs de noms TLD (TLD Name Servers) : Le serveur TLD dirige ensuite le résolveur vers le serveur de noms faisant autorité pour le domaine spécifique.
  • Serveur de noms faisant autorité (Authoritative Name Server) : Ce serveur détient les enregistrements DNS du domaine et fournit l'adresse IP au résolveur.
• Renvoi de l'adresse IP : Une fois que le résolveur DNS a obtenu l'adresse IP du serveur faisant autorité, il renvoie cette information au navigateur. Le navigateur peut alors initier une connexion au serveur en utilisant l'adresse IP pour charger la page web demandée.

Quel est l'impact du DNS sur le Time to First Byte ?

Pour les visiteurs récurrents, la recherche DNS est généralement mise en cache dans le navigateur ou l'OS, ce qui réduit la DNS duration à presque zéro. Pour les nouveaux visiteurs, cependant, la recherche DNS récursive complète doit se terminer avant que le navigateur ne puisse passer à l'étape de connexion TCP. C'est pourquoi le TTFB est souvent nettement moins bon pour les nouveaux visiteurs par rapport aux visiteurs récurrents.

Utiliser dns-prefetch et preconnect pour les domaines tiers

Si votre page charge des ressources provenant de domaines tiers (tels que des analyses, des polices ou des sous-domaines de CDN), le navigateur doit résoudre le DNS pour chaque domaine séparément. Vous pouvez demander au navigateur de commencer la résolution DNS tôt en utilisant l'indice de ressource dns-prefetch :

<!-- DNS prefetch pour les domaines tiers -->
<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">

Pour les origines tierces critiques où vous savez que vous devrez également établir une connexion TCP et TLS, utilisez preconnect à la place, qui inclut la résolution DNS plus le handshake de connexion :

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Utilisez dns-prefetch comme repli pour les navigateurs qui ne supportent pas preconnect :

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

Placez ces indices dans le <head> de votre HTML le plus tôt possible. N'ajoutez des indices que pour les domaines que votre page utilise réellement ; l'ajout d'indices pour des domaines inutilisés gaspille les ressources du navigateur. Pour plus de techniques d'optimisation liées au chargement des ressources, consultez notre guide sur les 103 Early Hints.

Comment minimiser l'impact du DNS sur le TTFB

Utiliser un fournisseur DNS rapide

Certains fournisseurs DNS sont plus rapides que d'autres. Choisir un fournisseur DNS rapide et fiable est l'un des moyens les plus simples de réduire la latence DNS. Les fournisseurs DNS premium comme Cloudflare, Amazon Route 53 et Google Cloud DNS exploitent des serveurs dans des centaines d'emplacements à travers le monde. Plus le serveur DNS est proche de votre utilisateur, plus la recherche est rapide.

Voici une comparaison de fournisseurs DNS populaires et de leurs temps de réponse types :

La différence entre un fournisseur DNS premium et un DNS de registraire de base peut être de 40 à 90 millisecondes par recherche (source : benchmarks DNSPerf). Pour les nouveaux visiteurs, cela se traduit directement par un TTFB plus rapide. Pour savoir comment configurer Cloudflare comme fournisseur DNS et CDN, lisez notre guide de configuration de Cloudflare.

Optimiser le Time-To-Live (TTL) du cache DNS

La mise en cache DNS stocke les résultats des requêtes DNS localement, réduisant ainsi le besoin de recherches répétées. En définissant des valeurs « optimales » de Time-To-Live (TTL) pour les enregistrements DNS, vous pouvez contrôler la durée pendant laquelle ces enregistrements sont mis en cache.

Des valeurs TTL plus basses signifient que les enregistrements expirent plus tôt, provoquant des recherches DNS plus fréquentes. Des valeurs TTL plus élevées signifient que les enregistrements sont mis en cache plus longtemps, réduisant les recherches DNS mais ralentissant la propagation des modifications DNS. Le bon TTL dépend de la fréquence à laquelle vous modifiez vos enregistrements DNS et de l'importance que vous accordez à la vitesse de recherche DNS par rapport à la flexibilité.

Quels sont les paramètres TTL DNS optimaux ?

Lors de la planification d'une migration DNS ou d'un changement de serveur, abaissez temporairement votre TTL à 5 minutes (300 secondes) au moins 24 heures avant d'effectuer le changement. Cela garantit qu'après le changement, les utilisateurs récupéreront rapidement la nouvelle adresse IP. Une fois la migration terminée et vérifiée, augmentez à nouveau le TTL pour réduire la fréquence des recherches DNS.

CONSEIL : si vous utilisez des enregistrements CNAME, envisagez d'implémenter le CNAME flattening. Le CNAME flattening est une technique qui vous permet d'utiliser un enregistrement CNAME au niveau du domaine racine (apex), en le résolvant efficacement en une adresse IP sans violer les standards DNS. Cela élimine une recherche DNS supplémentaire qui serait autrement nécessaire pour résoudre le CNAME vers sa cible, puis la cible vers son adresse IP.

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

Les requêtes DNS traditionnelles sont envoyées en texte clair sur UDP, ce qui signifie qu'elles peuvent être interceptées, modifiées ou bloquées par des intermédiaires (tels que des FAI ou des opérateurs réseau). Le DNS over HTTPS (DoH) et le DNS over TLS (DoT) chiffrent les requêtes DNS, améliorant à la fois la confidentialité et la sécurité.

Bien que le DoH et le DoT répondent principalement à des préoccupations de sécurité et de confidentialité, ils peuvent également affecter les performances de résolution DNS :

• Impact sur la latence : la charge de chiffrement ajoute une petite quantité de latence à la connexion DNS initiale (handshake TLS). Cependant, comme les connexions DoH/DoT sont persistantes et réutilisées, les requêtes suivantes sur la même connexion sont souvent plus rapides que le DNS traditionnel ;
• Interférence des FAI : certains FAI injectent leurs propres réponses DNS ou ralentissent les requêtes DNS pour les non-clients. Le DoH contourne entièrement cette interférence, ce qui peut réellement améliorer le temps de résolution DNS pour les utilisateurs concernés ;
• Support des navigateurs : les navigateurs modernes (Chrome, Firefox, Edge, Safari) supportent tous le DoH. Dans la plupart des cas, le fournisseur DNS par défaut du navigateur utilise déjà le DoH lorsqu'il est disponible.

Pour les propriétaires de sites web, vous ne pouvez pas contrôler si vos visiteurs utilisent le DoH ou le DoT (il s'agit d'un paramètre au niveau du navigateur et de l'OS). Cependant, vous pouvez vous assurer que votre fournisseur DNS faisant autorité supporte DNSSEC, qui fournit une couche supplémentaire de vérification pour les réponses DNS indépendamment du chiffrement du transport.

Mesurer la DNS Duration avec JavaScript

Vous pouvez mesurer la sous-partie DNS duration du TTFB directement dans le navigateur à l'aide de l'API Navigation Timing :

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
});

Une DNS duration de 0 ms dans vos données de RUM indique généralement que la recherche DNS a été servie depuis le cache du navigateur ou de l'OS (scénario de visiteur récurrent). Des valeurs supérieures à 50 ms suggèrent que l'utilisateur a dû effectuer une recherche DNS récursive complète, ce qui est courant pour les nouveaux visiteurs.

Comment mesurer les problèmes de TTFB causés par des recherches DNS lentes

Pour trouver l'impact que les utilisateurs réels subissent à cause de la latence DNS, vous devrez utiliser un outil de RUM comme CoreDash. Le Real User Monitoring vous permettra de suivre les Core Web Vitals plus en détail et sans le délai de 28 jours de Google.

Dans CoreDash, cliquez sur « Décomposition du Time to First Byte » pour visualiser la partie DNS du Time to First Byte.

Lectures complémentaires : Guides d'optimisation

Guides connexes :

• 103 Early Hints : envoyez des indices de ressources avant que la réponse complète ne soit prête, permettant au navigateur de commencer la résolution DNS et les connexions pour les ressources critiques encore plus tôt ;
• Configurer Cloudflare pour la performance : utilisez Cloudflare à la fois comme fournisseur DNS et CDN, combinant une résolution DNS rapide avec la mise en cache edge et le support HTTP/3.

Sous-parties du TTFB : Guides complets

La DNS duration est l'une des cinq sous-parties du TTFB. Explorez les autres sous-parties pour comprendre l'image complète :

• Fix and Identify TTFB Issues : le point de départ du diagnostic pour toute l'optimisation du TTFB ;
• Waiting Duration : redirections, mise en file d'attente du navigateur et optimisation HSTS ;
• Cache Duration : performance du service worker, recherches dans le cache du navigateur et bfcache ;
• Connection Duration : handshake TCP, optimisation TLS, HTTP/3 et preconnect ;
• Request Duration : temps de traitement du serveur, requêtes de base de données et optimisation du backend.