Le temps de réponse répond à une question simple : une fois que quelque chose demande votre site web, combien de temps faut-il pour que la réponse arrive ? Un outil de surveillance demande comme le fait un navigateur, avec une requête HTTP, et mesure l’attente.
C’est l’un des rares chiffres qui montrent un problème avant qu’il devienne une panne. Un site qui répond en 300 millisecondes le lundi et en 2 500 millisecondes le vendredi est toujours « en ligne », mais quelque chose a changé.
Ce qui se passe pendant une requête
Une requête traverse plusieurs étapes. Chacune prend du temps, et chacune peut être lente pour une raison différente.
- Résolution DNS. Le nom
example.comest transformé en adresse IP. C’est rapide quand la réponse est en cache à proximité, et lent sinon. - Connexion TCP. Le client ouvre une connexion vers cette adresse. Le temps dépend surtout de la distance et de la qualité du chemin réseau.
- Négociation TLS. Pour les adresses
https, les deux parties s’accordent sur le chiffrement et le client vérifie le certificat du serveur. Cela ajoute quelques allers-retours. - Requête et traitement par le serveur. La requête est envoyée. Le serveur peut lire des fichiers, interroger une base de données ou exécuter du code applicatif avant de pouvoir répondre.
- Premier octet. La première partie de la réponse arrive. Le temps écoulé jusqu’à ce moment s’appelle délai avant le premier octet (TTFB).
- Reste de la réponse. Les données restantes sont transférées.
Les redirections s’y ajoutent. Si l’adresse répond par une redirection, le client répète les étapes pour l’adresse suivante. Une chaîne de redirections multiplie le coût.
Délai avant le premier octet et temps total
Deux chiffres sont utilisés le plus souvent :
- Le délai avant le premier octet (TTFB) est l’attente jusqu’à l’arrivée du premier octet de la réponse. Le point de départ dépend de l’outil. Les recommandations de web.dev sur les performances web le comptent depuis le début de la navigation, ce qui inclut les redirections, la résolution DNS, l’établissement de la connexion, la négociation TLS et l’attente du serveur. Certains outils mesurent seulement à partir de l’envoi de la requête, ce qui exclut les étapes de mise en place. Quand vous comparez les chiffres de différents outils, vérifiez quelle définition chacun utilise.
- Le temps de réponse total est le temps jusqu’à la réception complète de la réponse. Pour une simple vérification de page, il ajoute le transfert de la réponse au TTFB.
Un TTFB élevé avec des étapes de connexion rapides désigne le serveur ou l’application qui se trouve derrière. Des étapes DNS ou de connexion lentes désignent le serveur de noms ou le réseau.
Temps de réponse et latence
La latence est le délai qu’ajoute le réseau lui-même, principalement le temps que met un signal à voyager. La distance compte : une requête de Singapour vers un serveur à Francfort prend plus de temps qu’une requête de Berlin, même si le serveur est aussi rapide. Le temps de réponse comprend la latence plus le travail effectué par le serveur.
Le temps de réponse n’est pas le temps de chargement d’une page
Une vérification de surveillance demande une seule adresse et mesure la réponse. Elle ne se comporte pas comme un navigateur qui ouvre une page.
Un navigateur télécharge aussi les images, les feuilles de style, les scripts et les polices, exécute les scripts et dessine la page. Les mesures de cette expérience, comme le largest contentful paint ou les Core Web Vitals, décrivent ce qu’un visiteur voit et à quel moment. Elles nécessitent un vrai navigateur.
Une page peut avoir une réponse rapide du serveur et paraître pourtant lente à cause de scripts lourds ou d’images volumineuses. L’inverse est aussi possible. Pour cette raison, le temps de réponse HTTP se lit mieux comme une mesure du serveur et du chemin qui y mène, pas de tout ce qu’un visiteur vit. UptimeWire mesure le premier. Il n’exécute pas de navigateur et ne rapporte pas les Core Web Vitals.
Pourquoi le temps de réponse change
- Le trafic. Plus de visiteurs simultanés se disputent les mêmes ressources.
- Les gros travaux en arrière-plan. Les sauvegardes, les imports ou les tâches planifiées peuvent prendre de la capacité aux visiteurs.
- Les requêtes de base de données lentes. Une requête rapide sur peu de données peut ralentir quand les données grossissent.
- Le cache. Une page en cache peut être plusieurs fois plus rapide qu’une page construite à la demande.
- Les modifications du site. Une mise en ligne, une extension ou un nouvel appel à un service tiers peuvent ajouter du temps du jour au lendemain.
- Le réseau. La congestion et les changements de routage affectent le temps de connexion et peuvent varier selon l’heure.
- L’endroit d’où la vérification est faite. La distance jusqu’au serveur compte, comme décrit plus haut.
Vérifier depuis plusieurs endroits
Une mesure dit comment le site répond depuis un endroit. Les services qui vérifient depuis plusieurs lieux peuvent montrer si une réponse lente est globale ou régionale. Un serveur qui répond en 200 millisecondes près de son centre de données et en 900 millisecondes depuis l’autre bout du monde se comporte normalement. Un site lent partout désigne le serveur.
Quand vous comparez des chiffres dans le temps, gardez l’endroit et l’intervalle constants. Sinon, une variation du chiffre peut venir de la méthode et non du site.
Un exemple concret
Une vérification sur une adresse https enregistre :
| Étape | Temps |
|---|---|
| Résolution DNS | 18 ms |
| Connexion | 24 ms |
| Négociation TLS | 41 ms |
| Premier octet | 312 ms |
| Total | 335 ms |
En lisant le premier octet compté depuis le début de la vérification, la réponse a commencé à arriver après 312 millisecondes, dont 83 millisecondes sont allées à la mise en place (18 + 24 + 41). Les 229 millisecondes restantes correspondent à peu près à la requête qui voyage jusqu’au serveur, au serveur qui prépare la réponse et au premier octet qui revient. Si la vérification du lendemain montre 1 180 ms pour le premier octet avec des étapes de mise en place inchangées, le temps supplémentaire est dans le serveur, pas dans le DNS ni dans le réseau.
À quoi ressemble un bon chiffre
Il n’existe pas de valeur unique correcte. Les recommandations de web.dev sur le TTFB, destinées aux pages que les visiteurs chargent dans un navigateur, retiennent 0,8 seconde ou moins comme repère approximatif pour « bon » et plus de 1,8 seconde comme « mauvais ». Prenez cela comme une orientation plutôt que comme une cible pour tous les sites. Une API appelée par d’autres systèmes peut devoir répondre bien plus vite. Une page avec un gros travail côté serveur peut raisonnablement prendre plus de temps.
La comparaison la plus utile est celle du site avec sa propre normale : qu’est-ce qui est typique, et en quoi aujourd’hui est-il différent ?
Le temps de réponse dans UptimeWire
UptimeWire envoie une requête HTTP à chaque adresse de site web que vous configurez et enregistre le temps qu’elle prend, avec le résultat. Le premier octet est compté depuis le début de la vérification, il inclut donc les étapes de mise en place et les redirections éventuelles, et le total couvre toute la vérification.
Le détail par étape fait partie du rapport de vérification détaillé, disponible à partir de l’offre Starter. Sur l’offre Free, vous voyez le temps de réponse de chaque vérification, sans la répartition par étape.