Un bon temps de réponse pour un site web, mesuré en temps jusqu’au premier octet pour une page HTML, se situe grosso modo sous 200 millisecondes pour une page en cache et sous 600 millisecondes pour une page dynamique. Les recommandations web.dev de Google considèrent comme bon un temps jusqu’au premier octet de 0,8 seconde ou moins. Au-delà d’environ une seconde, les visiteurs commencent à sentir l’attente avant que quoi que ce soit n’apparaisse à l’écran. Ces chiffres sont des ordres de grandeur, pas des limites strictes : ce qui compte davantage, c’est que votre temps de réponse soit stable, et que vous remarquiez quand il dérive.
Ce guide explique ce que mesure le temps de réponse, en quoi il diffère du temps de chargement de la page, pourquoi votre moniteur et votre navigateur affichent des chiffres différents, et comment le suivre pour corriger les ralentissements avant qu’ils ne deviennent des pannes.
Le temps de réponse n’est pas le temps de chargement
Les deux termes sont souvent confondus, mais ils mesurent des choses différentes.
Le temps de réponse est le temps que met le serveur à répondre à une seule requête. Pour un moniteur, il désigne généralement le temps entre l’envoi de la requête et l’arrivée de la réponse.
Le temps de chargement de la page est le temps que met le navigateur à afficher une page utilisable. Il comprend le temps de réponse du document HTML, plus le téléchargement et l’exécution des CSS, du JavaScript, des polices et des images, soit souvent des dizaines de requêtes supplémentaires.
Une page peut avoir un temps de réponse rapide et un chargement lent, par exemple quand le serveur répond en 150 millisecondes mais que la page charge ensuite trois mégaoctets de JavaScript. Nos conseils pour un site qui se charge plus vite traitent de ce côté front-end. L’inverse arrive aussi : un front-end bien optimisé ne peut pas masquer un serveur qui met quatre secondes à produire le HTML. Le temps de réponse dépend de votre serveur et de votre hébergement. Le chargement de la page dépend de votre front-end. Les deux comptent, et ils ne se corrigent pas de la même façon. Pour le chargement des pages, la surveillance de la vitesse des pages d’Uptimecheck lance Google Lighthouse chaque jour sur mobile et sur ordinateur, et vous alerte quand le score mobile d’une page passe sous votre seuil.
Ce que comprend le temps jusqu’au premier octet
Le temps jusqu’au premier octet, ou TTFB (time to first byte), est le temps entre le début de la requête et l’arrivée du premier octet de la réponse. Il se décompose en plusieurs étapes :
Résolution DNS : la traduction du nom d’hôte en adresse IP.
Connexion TCP : l’aller-retour nécessaire pour ouvrir une connexion.
Négociation TLS : l’accord sur le chiffrement pour HTTPS.
Traitement côté serveur : l’application s’exécute, interroge la base de données et construit la réponse.
Premier octet sur le réseau : le début de la réponse qui fait le chemin retour.
Vous pouvez voir chaque étape pour votre propre site avec curl :
curl -o /dev/null -s -w « dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n » https://northwind.shop/
Les valeurs sont cumulées. Si tls vaut 0,12 seconde et ttfb 0,95 seconde, le serveur a passé environ 0,8 seconde à produire la page. C’est ce chiffre qu’il faut travailler. Si les étapes DNS ou de connexion sont longues, le problème vient de la distance, du réseau ou du DNS plutôt que de votre application. Uptimecheck découpe le temps de réponse de chaque vérification selon les mêmes phases : DNS, connexion, TLS, serveur et téléchargement.
Pourquoi moniteurs et navigateurs n’affichent pas les mêmes chiffres
Il est normal que votre moniteur de disponibilité, les outils de développement de votre navigateur et un outil de test de performances affichent des temps de réponse différents pour la même page. Les raisons habituelles :
L’emplacement. Une vérification depuis un autre continent ajoute des allers-retours à chacune des étapes ci-dessus. Un serveur à Stockholm répond plus vite à un visiteur à Stockholm qu’à une vérification lancée depuis la côte Est des États-Unis.
La réutilisation des connexions. Votre navigateur garde les connexions ouvertes et les réutilise. Une vérification de surveillance ouvre souvent une nouvelle connexion à chaque fois, et paie donc le DNS, le TCP et le TLS à chaque requête.
Le cache. Votre navigateur peut avoir mis en cache tout ou partie de la page, et un CDN peut servir une copie en cache à certaines régions et pas à d’autres.
Ce qui est mesuré. Un outil indique le TTFB, un autre le temps total de téléchargement de la réponse complète, un troisième le chargement de toute la page.
Les cookies et les connexions. Les utilisateurs connectés contournent souvent le cache de page, si bien que leurs réponses sont plus lentes que celles d’une vérification anonyme.
Aucune de ces raisons ne rend un chiffre faux. L’important est de comparer ce qui est comparable : la même vérification, depuis le même emplacement, dans le temps. Un moniteur qui mesure la même requête chaque minute vous donne une référence cohérente, et ce sont les écarts par rapport à cette référence qui doivent vous faire agir.
Des objectifs raisonnables, à titre indicatif
Les fourchettes ci-dessous sont des ordres de grandeur pour la réponse serveur d’une page HTML ou d’un appel d’API, mesurée depuis un emplacement raisonnablement proche de votre serveur. Elles servent de point de départ pour votre propre référence, pas de norme.
Type de réponseConfortableÀ examinerPage en cache ou fichier statique via CDNsous 100–200 msau-delà de 400 msPage dynamique (CMS, boutique, application)sous 300–600 msau-delà de 1 sEndpoint d’API simple en lecturesous 100–300 msau-delà de 800 msRecherche, rapports, requêtes lourdessous 1–2 sau-delà de 3 s
Deux remarques pour lire ce tableau. D’abord, ajoutez la distance réseau : une vérification depuis un autre continent peut ajouter quelques centaines de millisecondes, et votre application n’y peut rien. Ensuite, la colonne qui compte le plus est celle que vous définissez vous-même. Si votre tunnel de paiement répond normalement en 350 ms et qu’il répond aujourd’hui en 900 ms, quelque chose a changé, même si 900 ms paraît encore acceptable sur le papier.
Ce qui ralentit les temps de réponse
Quand le temps de réponse augmente, la cause est presque toujours l’une de celles-ci :
Des requêtes de base de données lentes : un index manquant, une requête qui s’alourdit avec la taille d’une table, ou une extension qui lance des dizaines de requêtes par page.
Aucun cache de page ou d’objets : chaque requête reconstruit la même page de zéro.
Des appels externes pendant la requête : des API de paiement, de livraison, de recherche ou d’analytics appelées de façon synchrone pendant que le visiteur attend.
Trop peu de workers : les requêtes font la queue quand tous les workers PHP-FPM, Node ou du serveur d’applications sont occupés.
Des ressources sous tension : CPU au maximum, mémoire qui swappe ou E/S disque saturées par les sauvegardes ou l’écriture des journaux.
Les démarrages à froid : les fonctions serverless et les conteneurs réduits à zéro mettent du temps à traiter la première requête.
La distance : des visiteurs loin du serveur, sans CDN entre les deux.
Les files d’attente expliquent pourquoi le temps de réponse compte pour la disponibilité. Quand les réponses ralentissent, chaque requête occupe un worker plus longtemps, le pool se remplit, et les nouvelles requêtes attendent ou sont rejetées. Un ralentissement qui commence par une demi-seconde de plus peut se terminer en erreur 503 Service Unavailable au prochain pic de trafic.
Suivez la tendance, pas une vérification isolée
Une seule vérification lente ne veut pas dire grand-chose. Un incident réseau, une pause du ramasse-miettes ou un défaut de cache peuvent ralentir une requête. Ce qui révèle un problème, c’est un schéma :
Un saut brutal : le temps de réponse bondit après un déploiement, une mise à jour d’extension ou un changement d’hébergement, et reste à ce niveau.
Une lente montée : le temps de réponse augmente un peu chaque semaine à mesure qu’une table ou un journal grossit.
Un schéma quotidien : le temps de réponse grimpe à la même heure chaque jour, souvent à cause d’une sauvegarde, d’un import ou d’une tâche cron qui se disputent les ressources.
Une différence régionale : une région est lente alors qu’une autre va bien, ce qui désigne un CDN, le routage ou le DNS plutôt que le serveur.
Uptimecheck enregistre le temps de réponse de chaque vérification pour chaque moniteur de disponibilité et chaque moniteur d’API, l’affiche sous forme de graphiques avec la médiane et le 95e centile, et les rapports hebdomadaires et mensuels par e-mail indiquent le temps de réponse moyen à côté de la disponibilité. C’est cet historique qui vous permet de voir un saut brutal le jour même, et non des semaines plus tard.
Alertez sur une lenteur qui dure
Alerter à chaque vérification lente crée du bruit, et les alertes bruyantes finissent ignorées. Alertez sur une lenteur qui dure. Une approche pratique :
Mesurez votre référence pour chaque endpoint important sur une ou deux semaines.
Placez le seuil d’avertissement nettement au-dessus de la variation normale, par exemple deux à trois fois le temps de réponse habituel.
N’alertez que si la lenteur persiste sur plusieurs vérifications ou minutes consécutives.
Envoyez les avertissements de lenteur sur un canal d’équipe, et réservez les notifications push sur téléphone aux vraies pannes.
Définissez un délai d’expiration sur chaque vérification. Une réponse qui prend 30 secondes est un échec pour un visiteur, quel que soit le code de statut.
Dans Uptimecheck, vous définissez un seuil de réponse lente par moniteur. Quand trois vérifications d’affilée dépassent ce seuil, vous recevez une alerte de lenteur, puis une autre quand le moniteur redevient rapide. Le temps passé en lenteur ne compte pas comme une indisponibilité.
Les mêmes principes s’appliquent à toutes les alertes que vous configurez. Notre guide pour réduire les fausses alertes en surveillance de disponibilité détaille la confirmation et les seuils, et choisir les seuils d’alerte serveur explique comment fixer des limites pour le CPU, la mémoire et le disque. Quand les temps de réponse grimpent, la surveillance des serveurs à côté de vos vérifications de disponibilité montre si le serveur est en cause : vous n’avez plus à deviner entre la base de données, le réseau et le code.
Checklist du temps de réponse
Mesurez le TTFB de vos pages et endpoints clés avec curl, depuis un point proche de votre serveur.
Surveillez ces mêmes pages chaque minute et conservez l’historique.
Notez une référence par endpoint et comparez-vous à elle, pas à un chiffre générique.
Examinez les sauts brutaux après les déploiements et les lentes montées sur plusieurs semaines.
Mettez en cache ce qui peut l’être, corrigez les requêtes lentes et sortez les appels externes de la requête.
Alertez sur une lenteur qui dure et sur les délais dépassés, pas sur des vérifications lentes isolées.
En résumé
Un bon temps de réponse est faible pour le type de page concerné, proche de votre propre référence et stable dans le temps. À titre indicatif, visez quelques centaines de millisecondes pour les pages dynamiques et nettement moins pour les pages en cache. Mesurez-le toujours de la même manière, suivez la tendance et considérez une hausse durable comme un signal d’alerte précoce, car la page lente d’aujourd’hui est souvent la panne de demain.
Uptimecheck enregistre les temps de réponse à chaque vérification : vous voyez les ralentissements autant que les pannes. Essayez-le gratuitement pendant 14 jours, sans carte bancaire.