Minimisez la composante durée DNS du Time to First Byte

Minimisez la sous-partie durée DNS du Time to First Byte

Cet article fait partie de notre guide sur le Time to First Byte (TTFB). La durée DNS est la troisième sous-partie du TTFB. Elle représente le temps passé par le navigateur à résoudre votre nom de domaine en adresse IP. Pour les nouveaux visiteurs sans enregistrement DNS en cache, la recherche DNS peut ajouter 20 à 200 millisecondes au TTFB. Cela dépend du fournisseur DNS, de la position géographique de l'utilisateur et des paramètres TTL de vos enregistrements DNS.

Le Time to First Byte (TTFB) se divise en plusieurs sous-parties :

• Attente + Redirection (ou durée d'attente)
• Worker + Cache (ou durée du cache)
• DNS (ou durée DNS)
• Connexion (ou durée de connexion)
• Requête (ou durée de requête)

Vous cherchez à optimiser le Time to First Byte ? Cet article couvre la partie durée DNS du Time to First Byte. Si vous cherchez à comprendre ou corriger le Time to First Byte sans savoir ce que signifie la durée DNS, lisez ce qu'est le Time to First Byte et comment identifier et corriger les problèmes de Time to First Byte avant de commencer cet article.

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

La partie durée DNS du Time to First Byte correspond au temps de recherche de l'adresse internet (IP) de votre site par le navigateur. Nous avons besoin des recherches DNS car nous, les humains, mémorisons plus facilement des noms de domaine comme « www.example.com », tandis que les ordinateurs exigent des adresses IP numériques pour se connecter entre eux.

Comment fonctionne le DNS ?

Les requêtes DNS sont incluses dans la mesure du TTFB. Le temps nécessaire pour terminer la requête DNS est donc pris en compte dans le score TTFB global.

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

• Vérification du cache DNS du navigateur : Avant de lancer une requête DNS, le navigateur vérifie son propre cache DNS. Il cherche s'il possède déjà l'adresse IP du domaine demandé. Les navigateurs modernes mettent en cache les enregistrements DNS pendant une durée définie. Cela améliore les performances en réduisant les recherches DNS répétées. Si l'enregistrement se trouve dans le cache du navigateur, ce dernier l'utilise immédiatement, sans autre requête.
• Vérification du cache du système d'exploitation : Si le cache du navigateur ne contient pas l'enregistrement DNS requis, la requête passe au résolveur DNS du système d'exploitation, souvent appelé « résolveur stub ». Le système d'exploitation gère également un cache DNS et le vérifie avant d'envoyer la moindre requête réseau.
• Requête DNS : Si l'enregistrement DNS est absent du cache du navigateur et de celui du système d'exploitation, une requête DNS récursive part vers un résolveur DNS. Celui-ci est généralement fourni par le fournisseur d'accès internet (FAI) de l'utilisateur. Ce résolveur sert d'intermédiaire. Il interroge d'autres serveurs DNS pour trouver l'adresse IP.
  • Serveurs de noms racines : Le résolveur contacte d'abord un serveur de noms racine. Celui-ci le dirige vers le serveur de domaine de premier niveau (TLD) approprié en fonction de l'extension du domaine (par exemple, « .com », « .org »).
  • Serveurs de noms TLD : Le serveur TLD dirige ensuite le résolveur vers le serveur de noms faisant autorité pour ce domaine spécifique.
  • Serveur de noms faisant autorité : Ce serveur détient les enregistrements DNS du domaine et fournit l'adresse IP au résolveur.
• Renvoi de l'adresse IP : Une fois l'adresse IP obtenue auprès du serveur faisant autorité, le résolveur DNS renvoie cette information au navigateur. Le navigateur peut alors lancer une connexion au serveur via cette 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éguliers, la recherche DNS est généralement mise en cache dans le navigateur ou le système d'exploitation. La durée DNS est alors proche de zéro. Pour les nouveaux visiteurs, en revanche, la recherche DNS récursive complète doit s'achever avant que le navigateur ne passe à l'étape de connexion TCP. C'est pourquoi le TTFB est souvent nettement moins bon pour les nouveaux visiteurs que pour les visiteurs connus.

Utilisez dns-prefetch et preconnect pour les domaines tiers

Si votre page charge des ressources depuis des domaines tiers (comme des outils d'analyse, des polices ou des sous-domaines de CDN), le navigateur doit résoudre le DNS de chaque domaine séparément. Vous pouvez demander au navigateur de lancer la résolution DNS plus tôt avec l'indication de ressource dns-prefetch :

<!-- Pré-résolution DNS 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 devoir également établir une connexion TCP et TLS, utilisez plutôt preconnect. Cela inclut la résolution DNS et l'établissement de la connexion :

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

Utilisez dns-prefetch comme fallback pour les navigateurs ne supportant pas preconnect :

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

Placez ces indications dans le <head> de votre HTML le plus tôt possible. N'ajoutez des indications que pour les domaines réellement utilisés par votre page. L'ajout d'indications pour des domaines non utilisé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

Utilisez 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 de sites à travers le monde. Plus le serveur DNS est proche de votre utilisateur, plus la recherche est rapide.

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

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

Optimisez le Time to Live du cache DNS

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

Des valeurs TTL plus basses signifient que les enregistrements expirent plus tôt, ce qui entraîne des recherches DNS plus fréquentes. Des valeurs TTL plus élevées signifient que les enregistrements sont mis en cache plus longtemps. Cela réduit les recherches DNS, mais ralentit la propagation des modifications DNS. Le bon TTL dépend de la fréquence de modification de 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 le changement. Cela garantit qu'après la modification, les utilisateurs récupèreront rapidement la nouvelle adresse IP. Une fois la migration terminée et vérifiée, ramenez le TTL à une valeur plus élevée pour réduire la fréquence des recherches DNS.

ASTUCE : si vous utilisez des enregistrements CNAME, envisagez d'implémenter le CNAME flattening. Le CNAME flattening est une technique vous permettant d'utiliser un enregistrement CNAME au niveau du domaine racine (apex). Elle le résout effectivement en adresse IP sans violer les normes 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 via UDP. Elles peuvent donc être interceptées, modifiées ou bloquées par des intermédiaires (comme les FAI ou les opérateurs réseau). Le DNS over HTTPS (DoH) et le DNS over TLS (DoT) chiffrent les requêtes DNS, améliorant la confidentialité et la sécurité.

Bien que DoH et DoT répondent principalement à des problèmes 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 légère latence à la connexion DNS initiale (handshake TLS). Cependant, les connexions DoH/DoT étant 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. Cela peut réellement améliorer le temps de résolution DNS pour les utilisateurs concernés.
• Support par les 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 DoH ou DoT (il s'agit d'un paramètre du navigateur et du système d'exploitation). Cependant, vous pouvez vous assurer que votre fournisseur DNS faisant autorité supporte DNSSEC. Cela fournit une couche complémentaire de vérification pour les réponses DNS, indépendamment du chiffrement du transport.

Mesurez la durée DNS avec JavaScript

Vous pouvez mesurer la sous-partie durée DNS du TTFB directement dans le navigateur en utilisant l'API Navigation Timing :

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

  console.log('Durée DNS :', dnsDuration.toFixed(0), 'ms');

  if (dnsDuration > 50) {
    console.warn('Durée DNS élevée détectée. Envisagez de :');
    console.warn('1. Passer à un fournisseur DNS premium');
    console.warn('2. Augmenter les valeurs TTL DNS');
    console.warn('3. Utiliser dns-prefetch pour les domaines tiers');
  }
}).observe({
  type: 'navigation',
  buffered: true
});

Une durée DNS de 0 ms dans vos données RUM indique généralement que la recherche DNS provient du cache du navigateur ou du système d'exploitation (scénario d'un visiteur régulier). 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 découvrir l'impact de la latence DNS sur vos utilisateurs réels, vous devez utiliser un outil RUM comme CoreDash. Le Real User Monitoring vous permet de suivre les Core Web Vitals plus en détail et sans le délai de 28 jours de Google.

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

Lectures complémentaires : guides d'optimisation

Guides associés :

• 103 Early Hints : envoyez des indications de ressource avant que la réponse complète ne soit prête. Le navigateur peut ainsi lancer la résolution DNS et les connexions pour les ressources critiques encore plus tôt.
• Configurez Cloudflare pour la performance : utilisez Cloudflare comme fournisseur DNS et CDN. Vous combinerez une résolution DNS rapide avec une mise en cache périphérique et le support de HTTP/3.

Sous-parties du TTFB : guides complets

La durée DNS est l'une des cinq sous-parties du TTFB. Explorez les autres sous-parties pour avoir une vue d'ensemble :

• Identifiez et corrigez les problèmes de TTFB : le point de départ diagnostique pour toute optimisation du TTFB.
• Durée d'attente : redirections, mise en file d'attente du navigateur et optimisation HSTS.
• Durée du cache : performances des service workers, recherches dans le cache du navigateur et bfcache.
• Durée de connexion : handshake TCP, optimisation TLS, HTTP/3 et preconnect.
• Durée de requête : temps de traitement du serveur, requêtes de base de données et optimisation backend.