Réduire le temps de réponse du serveur : diagnostiquer et améliorer le TTFB

Pour réduire le temps de réponse du serveur, mesurez où la requête attend, puis corrigez cette partie du parcours. Un premier octet tardif peut venir des redirections, de la connexion, d’une origine éloignée, du traitement applicatif, des requêtes de base de données ou d’une absence en cache. Changer d’hébergement sans distinguer ces causes peut simplement déplacer le même problème vers un serveur plus coûteux.

Time to First Byte, ou TTFB, désigne le temps jusqu’à la réception du premier octet de réponse d’une navigation. Il dépasse le temps consacré par l’application à générer le HTML. L’objectif pratique étant de rendre le contenu utile disponible plus tôt, vérifiez toujours l’effet sur l’affichage, pas seulement sur le premier octet.

Définissez la mesure avant de choisir une cible

Les recommandations TTFB de Google présentent 800 millisecondes ou moins comme un bon objectif approximatif. TTFB n’est pas l’une des trois Core Web Vitals. Un dépassement mérite une investigation, mais le jugement final doit aussi tenir compte du moment où apparaît le contenu significatif.

Une page rendue côté serveur peut préparer le HTML plus longtemps tout en affichant du contenu utile avant une page qui renvoie immédiatement une structure vide à remplir côté client. Cela ne rend pas souhaitable un serveur lent. Cela signifie qu’avancer le premier octet en reportant tout le travail utile sur JavaScript peut être un mauvais compromis.

Le périmètre des mesures diffère également. Le TTFB de navigation observé sur le terrain peut inclure des délais qu’un audit du document final exclut. L’ancien audit Lighthouse du temps de réponse ne représentait pas toute la séquence DNS, redirections et connexion. La documentation actuelle de Chrome emploie aussi l’insight Document request latency. Un ancien intitulé peut donc ne pas correspondre au rapport affiché.

Notez la valeur réellement optimisée : TTFB de navigation réel, attente d’une requête navigateur, chronomètre applicatif ou résultat en ligne de commande. Les considérer comme interchangeables produit des conclusions contradictoires même lorsque chaque mesure est correcte.

Suivez la requête jusqu’au HTML utile

Plusieurs étapes peuvent précéder la première réponse documentaire utile. Leur coût dépend du cache DNS, des connexions existantes, des redirections, des protocoles et du parcours dans l’infrastructure.

Toutes les étapes ne se produisent pas à chaque requête. Un visiteur récurrent peut réutiliser une connexion. Un succès du cache peut éviter l’exécution de l’application. Une page de compte privée ne doit pas réutiliser du HTML destiné à une autre personne.

La comparaison la plus révélatrice oppose souvent deux chemins légitimes vers le même contenu. Une page publique déjà en cache et une page non cachée peuvent avoir des temps très différents. Cet écart révèle la couche qui protège actuellement les visiteurs du travail lent de l’origine.

Établissez une référence avec le vrai parcours du visiteur

Ouvrez DevTools avant la navigation et examinez la requête documentaire dans Network. Relevez URL finale, état, protocole, en-têtes et décomposition temporelle. Gardez les redirections visibles. Un test lancé directement à destination n’explique pas le délai d’une redirection de campagne ou d’un ancien lien interne.

Séparez les tests à froid et à chaud. Désactiver le cache du navigateur modifie sa réutilisation, sans forcément contourner le CDN ou le cache de pages du serveur. Une fenêtre privée ne garantit pas non plus un cache périphérique vide. Identifiez précisément la couche contrôlée.

Testez des contenus représentatifs. L’accueil, très fréquenté, peut être presque toujours en cache, alors que d’anciens articles sont générés à la demande. Recherche, compte et paiement peuvent emprunter d’autres chemins. Gardez privés les tests authentifiés et ne placez pas de cookies de session dans les rapports partagés.

Répétez les tests depuis les régions importantes pour votre public lorsque vous disposez d’un service de test ou d’un dispositif de surveillance approprié. Une requête rapide près de l’origine renseigne peu sur les visiteurs éloignés. Décrivez le lieu et les conditions plutôt que d’en faire un résultat mondial.

Utilisez curl pour distinguer les jalons cumulés

Cette commande effectue une requête GET, écarte le corps et affiche des jalons temporels cumulés. Remplacez l’URL d’exemple par une page publique que vous êtes autorisé à tester. Les redirections ne sont volontairement pas suivies : elles restent visibles.

curl --silent --show-error --output /dev/null \
  --write-out 'status=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://example.com/'

Ces valeurs mesurent le temps écoulé depuis le début du transfert. Ne les additionnez pas. Pour une nouvelle connexion HTTPS simple, les différences entre jalons voisins peuvent isoler connexion et TLS. Les proxys, la réutilisation et le protocole peuvent toutefois modifier l’interprétation.

L’intervalle après la connexion et avant le premier octet n’est pas un chronomètre applicatif pur. Il comprend réseau et traitement serveur. Utilisez-le pour situer le retard probable, puis instrumentez le serveur pour distinguer base de données, rendu et file d’attente.

Vérifiez l’état avant d’interpréter les performances. Une redirection, une erreur ou un contrôle antibot rapide n’est pas une page réussie rapide. Ne remplacez pas non plus GET par HEAD par commodité si l’application peut traiter ces méthodes différemment.

Conservez plusieurs résultats comparables avec date et version déployée. Une médiane facilite la comparaison d’un petit ensemble, mais gardez les mesures individuelles et les échecs inhabituels. Une seule valeur centrale peut masquer les lenteurs intermittentes réellement perçues.

Instrumentez l’application sans exposer de données privées

Les traces serveur séparent des traitements que les temps du navigateur ne distinguent pas. Recherchez requêtes de base de données, rendu des modèles, appels externes, lectures du cache, files des workers et accès aux fichiers. Gardez des noms cohérents entre versions pour comparer les changements sans reconstruire l’instrumentation.

L’en-tête Server-Timing expose des durées nommées aux outils du navigateur. Cet exemple PHP complet mesure la génération d’une petite réponse HTML publique. Il utilise hrtime, disponible depuis PHP 7.3. En production, utilisez une version compatible encore prise en charge.

<?php
declare(strict_types=1);

$started = hrtime(true);
$title = htmlspecialchars('Performance example', ENT_QUOTES, 'UTF-8');
$html = '<!doctype html><html lang="en"><meta charset="utf-8">'
      . '<title>' . $title . '</title><h1>' . $title . '</h1></html>';
$durationMs = (hrtime(true) - $started) / 1e6;

header('Content-Type: text/html; charset=utf-8');
header('Cache-Control: no-store');
header('Server-Timing: render;dur=' . number_format($durationMs, 3, '.', ''));
echo $html;

La durée est mesurée à l’exécution ; aucun résultat de benchmark n’est sous-entendu. La directive no-store empêche le stockage de cette réponse de diagnostic dans les caches HTTP. Elle n’est pas recommandée pour toutes les pages publiques.

Placez les chronomètres autour des vraies opérations, sans appeler « temps de base de données » l’ensemble de la requête. Des opérations parallèles peuvent se chevaucher : leurs durées ne s’additionnent pas forcément au total. L’attente d’un worker disponible peut aussi précéder le chronomètre applicatif.

Utilisez des noms généraux comme render ou database. N’exposez pas de SQL, jetons d’accès, identifiants clients, noms d’hôtes internes ou données commerciales sensibles dans des en-têtes publics. Les traces détaillées appartiennent à un système de surveillance correctement protégé.

Choisissez le cache qui supprime le traitement coûteux

Caches de pages, d’objets et d’opcodes répondent à des problèmes différents. Ils peuvent coexister, mais activer l’un ne prouve pas que les autres existent ou fonctionnent.

Pour une publication servant le même article aux visiteurs anonymes, le cache de page complète est souvent un bon départ. Vérifiez son invalidation après modification éditoriale. Un article périmé après correction reste un échec de publication, même si son rapport de performance est excellent.

Sur une page dynamique, un cache d’objets peut réduire les lectures répétées tandis que l’application produit toujours une réponse personnalisée. Dans WordPress, le cache d’objets par défaut n’est pas automatiquement persistant entre les requêtes. Un stockage persistant demande une implémentation appropriée ; son intérêt dépend des données réellement mises en cache.

PHP OPcache réduit la compilation répétée, pas les requêtes lentes ni les appels réseau éloignés. Vérifiez configuration et compatibilité sans attendre qu’il répare une architecture inefficace. Sur une plateforme gérée, demandez quelles couches sont déjà contrôlées par le fournisseur.

Le cache du navigateur sert surtout après réception initiale des ressources. Il ne garantit pas une première visite rapide. Le guide du cache navigateur distingue fraîcheur, validation et interdiction de stockage.

Protégez sessions, paniers et contenu personnalisé

Commencez le cache HTML partagé avec une liste limitée de pages publiques autorisées. Excluez compte, panier, paiement et autres routes personnalisées, sauf stratégie délibérément conçue et testée. Les cookies de session et l’autorisation exigent un traitement explicite dans les règles.

Un cookie ne garantit pas à lui seul que chaque intermédiaire considère la réponse comme privée. Lisez puis vérifiez le comportement du CDN et du cache applicatif. Méfiez-vous des règles qui imposent le stockage malgré les en-têtes ou ignorent des paramètres dont la signification n’est pas comprise.

Testez avec deux sessions distinctes et un navigateur déconnecté. Aucun ne doit recevoir le nom, le panier, les prix ou l’état de compte d’un autre visiteur. Un bon taux de succès n’a aucun intérêt si la réponse appartient à quelqu’un d’autre.

Gardez les clés de cache compréhensibles. Les paramètres purement publicitaires peuvent fragmenter inutilement le contenu public. Les sélecteurs de produit, devise, langue et état d’accès peuvent en revanche changer la réponse. Normalisez seulement ce qui n’affecte ni contenu ni autorisation, après l’avoir établi.

Corrigez l’origine lente même lorsque le cache fonctionne

Les absences en cache restent possibles : nouveau contenu, URL peu consultées, invalidations ou arrivée sur un autre nœud. Un cache qui masque une origine lente pendant le test habituel ne dispense pas de comprendre cette origine.

Utilisez le profilage des requêtes pour repérer les traitements coûteux ou répétés. Examinez les plans d’exécution avant d’ajouter des index. Un index utile en lecture consomme de l’espace et peut affecter les écritures. Reliez donc chaque modification à une requête mesurée, sans supposer que davantage d’index améliore tout.

Cherchez les appels répétés dans des boucles, données inutiles et traitements coûteux exécutés à chaque visite. Sortez les tâches secondaires du parcours critique lorsque la correction fonctionnelle le permet. La page ne doit pas attendre une comptabilité interne sans rapport avec sa tâche parce que le code partage le même gestionnaire.

Les API externes nécessitent délais limites, cache adapté et comportement en cas d’échec. Déterminez les données indispensables à la première réponse et celles qui peuvent suivre. Reporter du contenu important peut dégrader rendu et utilisabilité : évaluez la tâche entière, pas uniquement TTFB.

Comparez les versions de l’environnement et des dépendances en préproduction avant de mettre à jour. Une version PHP ou Node prise en charge fait partie de la maintenance, mais compatibilité et performances doivent être vérifiées avec votre application. Ne promettez aucun pourcentage universel lié à un changement de version.

Utilisez un CDN lorsque distance et réutilisation le justifient

Un CDN peut livrer du contenu admissible depuis un point proche du visiteur, ce qui réduit les voyages vers une origine éloignée, surtout en cas de succès du cache. Mais un CDN qui ne stocke que les ressources statiques peut laisser toutes les requêtes HTML dépendre de la même origine lente.

Examinez la réponse et les en-têtes de cache documentés par le fournisseur. Noms et significations varient. Identifiez succès, absence, contournement, revalidation ou réponse périmée selon une règle. La présence d’un nom de domaine CDN ne prouve pas un succès du cache.

Mesurez séparément HTML et ressources statiques. Une excellente réutilisation des images peut coexister avec un mauvais cache HTML. Incluez volumes et types de requêtes lorsque possible : un pourcentage global peut masquer la classe de trafic visée.

Planifiez l’invalidation avant d’allonger les durées. Publication, correction, modification d’accès et déploiement doivent avoir un comportement prévisible. Notre guide du CDN et du cache périphérique explique ces compromis sans supposer des réglages identiques partout.

Considérez les protocoles comme une composante de la livraison

Le multiplexage HTTP/2 et le transport QUIC de HTTP/3 peuvent améliorer le partage des connexions. Leur effet dépend de la connexion, du réseau et de l’implémentation serveur. Aucun ne supprime les requêtes de base de données lentes ni ne garantit toujours un premier octet plus rapide.

La réutilisation des connexions et la reprise de session TLS peuvent réduire les étapes répétées dans des conditions adaptées. Vérifiez ce que proposent déjà hébergement et CDN. Le lien navigateur-CDN peut employer un autre protocole que le lien CDN-origine.

HTTP 103 Early Hints permet à un client compatible de commencer les ressources importantes avant la réponse finale. Il ne rend pas instantanée la génération du HTML, et sa prise en charge dépend du navigateur et des intermédiaires. Réservez-le à un retard de découverte démontré, avec un parcours fonctionnel sans indication.

Early Hints peut également changer le sens de la mesure du premier octet. Chrome compte actuellement la réponse intermédiaire dans responseStart. Lorsque disponible, finalResponseHeadersStart identifie le début des en-têtes définitifs. Notez navigateur et champ temporel lors des comparaisons : une réponse provisoire plus précoce ne prouve pas que le HTML final est arrivé plus tôt.

La compression réduit surtout les octets transmis. Réalisée à la volée, elle consomme aussi du CPU. Mesurez son effet au lieu d’assimiler automatiquement une réponse plus petite à une latence initiale réduite. L’explication de HTTP/2 et HTTP/3 distingue transport et traitement applicatif.

Déterminez si l’hébergement constitue le blocage

Examinez l’infrastructure lorsque les réponses lentes coïncident avec des workers épuisés, un CPU saturé, une pression mémoire, un stockage lent ou une contention de base de données. Le lien avec les heures chargées est une piste, mais identifiez la ressource limitée avant de choisir une offre supérieure.

Comparez une réponse statique simple à une réponse applicative représentative sans cache, avec des parcours comparables. Si seule l’application ralentit, inspectez dépendances et exécution. Si les deux se dégradent sous charge, examinez les ressources partagées et l’hébergement.

En hébergement mutualisé, toutes les métriques ne sont pas forcément accessibles. Fournissez des preuves concrètes : heures, URL, état du cache, en-têtes et mesures répétées. Demandez quelles limites ont été atteintes et si l’offre permet la configuration nécessaire.

Vérifiez le progrès sur le parcours initialement défaillant

Rejouez le scénario lent d’origine après avoir modifié une partie pertinente du système. Contrôlez codes d’état, contenu, séparation des sessions, invalidation et gestion des erreurs en plus des temps. Vérifiez ensuite que le progrès atteint l’affichage au lieu de simplement déplacer du travail plus tard.

Utilisez l’analyseur PageSpeed lorsqu’il est activé pour une URL publique, en conservant conditions de laboratoire et données de terrain disponibles. Poursuivez avec les guides de performance serveur lorsque le prochain blocage est clair. Le résultat recherché est une réponse plus rapide et reproductible pour le bon visiteur, avec le bon contenu.