Quand on parle de temps de réponse du serveur, on pense généralement au travail de l’application : PHP qui exécute WordPress, les requêtes à la base de données, la génération du HTML. Mais avant même que le serveur reçoive la requête, le navigateur doit franchir une série d’étapes : découvrir l’adresse du serveur, ouvrir une connexion, négocier le chiffrement. Chacune demande un ou plusieurs allers-retours sur le réseau, et sur une connexion mobile, chaque trajet peut valoir 50, 80, parfois 150 millisecondes.
Ces millisecondes font partie du TTFB que vivent les utilisateurs et que mesure le Chrome UX Report : le Time to First Byte de terrain commence au début de la navigation et inclut les redirections, la résolution DNS, la connexion et la négociation TLS, pas seulement le temps de traitement du serveur. Sur un site doté d’un cache de page efficace, elles peuvent représenter l’essentiel du TTFB. Dans cet article, nous voyons ce qui se passe avant le premier octet, combien coûte chaque phase et ce qu’on peut faire pour la réduire.
Les phases, dans l’ordre
Quand un utilisateur ouvre une adresse, le navigateur exécute dans l’ordre : les éventuelles redirections, chacune avec son propre cycle complet ; la résolution DNS du nom de domaine ; l’ouverture de la connexion TCP, avec un aller-retour ; la négociation TLS, avec un ou deux allers-retours selon la version du protocole ; l’envoi de la requête et l’attente de la réponse, avec un autre aller-retour plus le temps de traitement du serveur. Avec HTTP/3, TCP et TLS fusionnent en une seule phase, comme nous l’avons vu dans l’article sur HTTP/3 et QUIC.
Les redirections : le coût le plus évitable
Le pire cas, encore courant, est celui où l’utilisateur arrive sur une adresse qui est redirigée. Un lien publié sous la forme http://example.com produit une requête en clair, une redirection vers https://example.com, puis peut-être une deuxième vers https://www.example.com, et une troisième pour ajouter la barre oblique finale à l’adresse. Chaque redirection est un cycle complet de requête et de réponse, parfois avec une nouvelle connexion, et le temps s’additionne avant même que la page ne soit demandée.
Les solutions sont simples. Les liens internes, les campagnes, les partages sur les réseaux sociaux et les profils doivent toujours pointer vers l’adresse finale, avec le bon protocole, le bon domaine et le bon format. Les règles de redirection côté serveur doivent mener directement à la destination finale en une seule étape, sans chaîne. Et l’en-tête HSTS, éventuellement avec l’inclusion dans la liste de préchargement des navigateurs, fait aller le navigateur directement en HTTPS sans même tenter la requête en clair.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadUn cas particulier concerne les campagnes publicitaires et les services de suivi de liens, qui passent souvent par un ou plusieurs domaines intermédiaires avant d’arriver sur le site. Ces redirections ne sont pas sous le contrôle du site, mais leur coût apparaît dans les données de terrain des pages de destination, et il vaut la peine de le savoir quand on analyse le TTFB du trafic payant.
DNS
La résolution DNS traduit le nom de domaine en adresse du serveur. Le navigateur interroge d’abord son propre cache, puis le système d’exploitation, puis le résolveur configuré, généralement celui du fournisseur d’accès ou un service public, qui à son tour, s’il ne connaît pas la réponse, interroge la chaîne de serveurs jusqu’à celui qui fait autorité pour le domaine. La réponse s’arrête au premier niveau qui la connaît encore, et chaque niveau la conserve pendant la durée indiquée par le TTL, la durée de vie de l’enregistrement.
Pour le site, il y a quatre leviers. Le premier est le fournisseur DNS : un service doté d’un réseau anycast, c’est-à-dire de serveurs répartis dans de nombreux emplacements qui répondent à la même adresse, répond plus vite qu’un serveur unique dans un seul centre de données, surtout pour les utilisateurs éloignés. De nombreux CDN et bureaux d’enregistrement proposent ce type de DNS sans coût supplémentaire. Le deuxième est le TTL : des valeurs trop basses, quelques secondes, obligent les résolveurs à interroger souvent le serveur faisant autorité ; des valeurs de quelques minutes ou de quelques heures permettent aux caches de répondre dans la plupart des cas. Des TTL très bas n’ont de sens que lorsqu’on prévoit de changer souvent d’adresse, par exemple pendant une migration.
Le troisième, ce sont les chaînes CNAME : un domaine qui est l’alias d’un autre domaine, lui-même alias d’un troisième, exige plusieurs résolutions successives. Les configurations avec des CDN et des services externes en produisent facilement ; de nombreux fournisseurs DNS proposent la résolution directe d’alias à la racine du domaine pour les éviter. Le quatrième est l’enregistrement HTTPS, un type d’enregistrement plus récent qui permet d’indiquer au navigateur, dès la réponse DNS, quels protocoles le serveur prend en charge, comme HTTP/3, et d’autres paramètres de connexion, ce qui évite des tentatives ultérieures.
Pour les domaines tiers utilisés par la page, comme ceux des polices, des outils d’analyse ou des CDN externes, la résolution DNS peut être anticipée avec dns-prefetch ou, pour les domaines critiques, avec preconnect, comme l’explique l’article sur preload, preconnect et fetchpriority. La solution la plus efficace reste cependant de réduire le nombre de domaines différents dont la page dépend.
TCP et la distance
Ouvrir une connexion TCP demande un aller-retour entre l’appareil et le serveur, et la durée de ce trajet dépend surtout de la distance physique et de la qualité du réseau. Un utilisateur à Milan qui se connecte à un serveur à Milan peut avoir quelques millisecondes de latence ; le même utilisateur qui va sur un serveur aux États-Unis en aura plus d’une centaine, et chaque phase qui exige un aller-retour les paiera à nouveau.
C’est pourquoi l’emplacement du serveur compte : un site dont l’audience est en Italie devrait avoir son serveur, ou du moins ses points de contact avec les utilisateurs, en Italie ou dans l’Europe proche. Un CDN résout le problème pour les sites à audience répartie : la connexion est ouverte avec le nœud le plus proche de l’utilisateur, et le tronçon vers le serveur d’origine passe par des connexions déjà ouvertes sur des réseaux de qualité. C’est l’un des avantages concrets des CDN, à distinguer du cache de page, comme nous l’avons vu à propos de Cloudflare.
TLS : version, certificats et reprise de session
La négociation TLS établit le chiffrement de la connexion. Avec TLS 1.2, elle exige deux allers-retours ; avec TLS 1.3, standard depuis 2018 et pris en charge par tous les navigateurs modernes, un seul suffit. Activer TLS 1.3 sur le serveur, ou vérifier qu’il l’est, est donc l’une des modifications les plus simples et au meilleur rapport coût/bénéfice. Presque tous les serveurs web et les CDN modernes le prennent en charge ; il convient de désactiver les versions obsolètes, TLS 1.0 et 1.1, y compris pour des raisons de sécurité.
Avec TLS 1.3, il y a aussi la reprise de session : un navigateur qui s’est connecté récemment au même serveur peut réutiliser les clés négociées auparavant et, en mode 0-RTT, envoyer la requête avec le premier message de la négociation. Comme avec HTTP/3, le mode 0-RTT n’est utilisé que pour les requêtes sans effets de bord, car les données du premier message pourraient être rejouées par un attaquant.
Le certificat lui-même a un poids. Pendant la négociation, le serveur envoie son propre certificat et les certificats intermédiaires de la chaîne : une longue chaîne, ou des certificats avec de grandes clés RSA, augmentent les données à transmettre et, sur les réseaux lents, peuvent exiger des paquets supplémentaires. Les certificats à clés ECDSA sont plus petits et plus rapides à vérifier, et sont désormais pris en charge partout ; de nombreuses configurations servent les deux types, en laissant le choix au client. Il faut aussi vérifier que le serveur envoie la chaîne complète : si un certificat intermédiaire manque, certains clients doivent aller le chercher séparément, avec un retard supplémentaire.
Un dernier point concerne la vérification de la révocation des certificats. Pendant des années, le mécanisme OCSP a permis aux clients de demander à l’autorité de certification si un certificat était encore valide, avec une requête supplémentaire que la technique d’OCSP stapling évitait en incluant la réponse dans la négociation. Ces dernières années, plusieurs autorités de certification ont commencé à abandonner OCSP au profit d’autres mécanismes, et les navigateurs n’effectuent plus cette vérification de façon bloquante : c’est aujourd’hui un aspect moins critique pour la performance qu’autrefois, mais il reste utile de vérifier la configuration recommandée par votre autorité de certification.
# nginx : protocoles modernes et reprise de session
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 1d;
ssl_early_data on; # 0-RTT : à évaluer avec prudence
http2 on;Réutiliser les connexions
La manière la plus efficace de réduire le coût des connexions est d’en ouvrir moins. Avec HTTP/2 et HTTP/3, toutes les ressources d’un domaine passent par une seule connexion, et le coût d’ouverture n’est payé qu’une fois. Chaque domaine supplémentaire, en revanche, exige sa propre chaîne DNS, TCP et TLS. Une page qui charge les polices depuis un service externe, des bibliothèques depuis un CDN public, des images depuis un sous-domaine et des scripts de cinq fournisseurs différents ouvre sept ou huit connexions, chacune avec son coût, et souvent au moment critique du chargement.
Héberger sur son propre domaine les ressources nécessaires au premier affichage, comme les polices, le CSS et les scripts principaux, élimine ces connexions. Les pratiques du passé, comme répartir les ressources sur plusieurs sous-domaines pour augmenter le nombre de téléchargements parallèles, étaient utiles avec HTTP/1.1 et sont contre-productives aujourd’hui. Garder les connexions ouvertes d’une requête à l’autre, avec des délais d’inactivité adaptés, évite aussi de les rouvrir lors de la navigation entre les pages.
Comment mesurer
En ligne de commande, curl permet de mesurer précisément le temps de chaque phase :
curl -so /dev/null https://example.com/ -w '
redirects: %{time_redirect}s
DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
first byte: %{time_starttransfer}s
total: %{time_total}s
'Les valeurs sont cumulatives : le temps TLS inclut ceux du DNS et de TCP, et ainsi de suite. Exécuter la commande depuis différents emplacements, ou depuis un serveur proche des utilisateurs, donne une idée réaliste des temps de connexion. Dans le navigateur, le panneau Network des DevTools montre les mêmes phases dans l’onglet Timing de chaque requête, et le waterfall les rend visibles d’un coup d’œil grâce aux segments colorés au début des barres.
Sur les utilisateurs réels, l’API Navigation Timing expose le début et la fin de chaque phase : domainLookupStart et domainLookupEnd pour le DNS, connectStart et connectEnd pour la connexion, secureConnectionStart pour TLS, redirectStart et redirectEnd pour les redirections. Un système de Real User Monitoring qui enregistre ces phases séparément permet de comprendre quelle part du TTFB dépend du réseau et laquelle du serveur, et de voir comment elle varie selon le pays, le type de connexion ou la source de trafic.
const n = performance.getEntriesByType( 'navigation' )[ 0 ];
const phases = {
redirect: n.redirectEnd - n.redirectStart,
dns: n.domainLookupEnd - n.domainLookupStart,
connection: n.connectEnd - n.connectStart,
tls: n.secureConnectionStart > 0 ? n.connectEnd - n.secureConnectionStart : 0,
server: n.responseStart - n.requestStart,
};Une liste de contrôle
- Aucune redirection pour les adresses les plus utilisées ; chaînes réduites à une seule étape ; HSTS activé.
- Fournisseur DNS avec réseau anycast, TTL de quelques minutes ou heures, peu de chaînes CNAME, enregistrements HTTPS là où c’est pris en charge.
- Serveur ou CDN proche des utilisateurs.
- TLS 1.3 activé, versions obsolètes désactivées, reprise de session configurée, chaîne de certificats complète, de préférence avec des certificats ECDSA.
- HTTP/2 ou HTTP/3, peu de connexions vers des domaines différents, ressources critiques sur son propre domaine, preconnect uniquement pour les domaines essentiels.
En résumé
Avant le premier octet viennent les redirections, le DNS, la connexion et le chiffrement : des phases qui dépendent de la configuration du site plus que de la puissance du serveur, et qui sur un réseau mobile peuvent valoir plusieurs centaines de millisecondes. Elles sont incluses dans le TTFB mesuré sur le terrain et donc, par cascade, dans le LCP. Sur un site doté d’un bon cache de page, elles représentent souvent la plus grande part du temps de réponse.
Les correctifs relèvent presque tous de la configuration et sont rarement coûteux : éliminer les redirections, choisir un fournisseur DNS rapide avec des TTL raisonnables, rapprocher les serveurs des utilisateurs, activer TLS 1.3 et la reprise de session, réduire les domaines à contacter. Aucune de ces modifications n’est spectaculaire isolément, mais ensemble elles peuvent diviser par deux le temps avant le premier octet, pour toutes les pages et tous les utilisateurs.
