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

La durée DNS consiste en les recherches DNS du navigateur. Comprenez la sous-partie du TTFB pour réduire le temps total jusqu'au premier octet.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-08

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

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

  • Waiting + Redirect (ou durée d'attente)
  • Worker + Cache (ou durée de cache)
  • DNS (ou durée DNS)
  • Connection  (ou durée de connexion)
  • Request (ou durée de requête)

Vous cherchez à optimiser le Time to First Byte ? Cet article propose une analyse approfondie de la partie durée DNS 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 la durée d'attente, veuillez consulter [url=/core-web-vitals/time-to-first-byte]qu'est-ce que le time to first byte[/url] et [url=/core-web-vitals/time-to-first-byte/fix-and-identify]corriger et identifier les problèmes de time to first byte[/url] 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 Durée DNS du time to first byte consiste en un temps pendant lequel le navigateur recherche l'adresse internet (IP) de votre site.  Nous avons besoin de recherches DNS car nous, les humains, trouvons plus facile de mémoriser des noms de domaine comme "www.example.com", tandis que les ordinateurs nécessitent des adresses IP numériques pour se connecter les uns aux autres.


Comment fonctionne le DNS ?

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

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

  • Le cache DNS du navigateur est vérifié : Avant de faire 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éfinie 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é "stub resolver". 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 (ISP) de l'utilisateur. Ce résolveur agit comme un intermédiaire, gérant le processus de requête d'autres serveurs DNS pour trouver l'adresse IP. 
    • Serveurs de noms racine : Le résolveur contacte d'abord un serveur de noms racine, qui 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 le 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.
  • Retour de l'adresse IP : Une fois que le résolveur DNS obtient 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.

Comment le DNS impacte-t-il le Time to First Byte ?

La recherche DNS peut ralentir le Time to First Byte soit à cause de la latence du réseau (le temps nécessaire pour se connecter au serveur de noms dans ce cas), de la qualité/vitesse du serveur de noms faisant autorité et du temps de cache DNS (puisque les requêtes DNS mises en cache sont beaucoup plus rapides que les requêtes DNS non mises en cache).

Comment minimiser l'impact du DNS sur le TTFB


  • Utilisez un fournisseur DNS rapide. Certains fournisseurs DNS de haute qualité sont plus rapides que d'autres. C'est pourquoi 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 Dyn disposent d'infrastructures mondiales étendues. Ces infrastructures réduisent la distance physique entre les utilisateurs et les serveurs DNS et éliminent une partie importante de la latence impliquée dans les requêtes DNS.
  • Optimisez le Time-To-Live (TTL) du cache DNS : La mise en cache DNS stocke localement les résultats des requêtes DNS, réduisant ainsi le besoin de recherches répétées. En définissant des valeurs TTL « optimales » pour les enregistrements DNS, vous pouvez contrôler la durée pendant laquelle ces enregistrements sont mis en cache.  

Quels sont les paramètres TTL DNS optimaux ?

Enregistrements A et AAAA (enregistrements d'adresse IP) : Pour la plupart des sites web : 5 minutes à 1 heure. Pour les sites web statiques qui ne changent pas fréquemment : 1 à 24 heures.
Enregistrements CNAME : Généralement 24 heures
Enregistrements TXT et MX :Environ 12 heures
Enregistrements NS : TTL plus longs, tels que 1 à 2 jours, car ils sont critiques et généralement statiques
SOA et autres enregistrements statiques : TTL plus longs, jusqu'à quelques jours

ASTUCE : si vous utilisez des enregistrements CNAME, envisagez de mettre en œuvre le CNAME flattening. Le CNAME flattening est une technique qui vous permet d'utiliser un enregistrement CNAME au niveau du domaine racine (apex), le résolvant efficacement en une adresse IP sans violer les normes DNS. 

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 des redirections, vous devrez utiliser un outil 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 simplement sur « Time to First Byte breakdown » pour visualiser la partie DNS du Time to First Byte.  

Make decisions with Data.

You cannot optimize what you do not measure. Install the CoreDash pixel and capture 100% of user experiences.

Create Free Account >>

  • 100% Capture
  • Data Driven
  • Easy Install
Minimiser la sous-partie durée DNS du Time to First Byte Core Web Vitals Minimiser la sous-partie durée DNS du Time to First Byte