Optimiser la réponse HTML du serveur (TTFB)

Toute page web commence par une requête vers le serveur pour récupérer son document HTML. La vitesse à laquelle ce document arrive conditionne tout le reste du chargement. On mesure cette rapidité avec le TTFB (Time To First Byte), c’est-à-dire le temps écoulé avant que le navigateur reçoive le premier octet de la réponse.

Un TTFB élevé n’est pas la seule métrique à surveiller, mais il rend nettement plus difficile l’atteinte des bons seuils pour le LCP et le FCP. Optimiser la réponse HTML du serveur est donc un levier SEO majeur, à replacer dans les fondamentaux de la performance : c’est la première étape qui détermine si votre page part sur de bonnes bases.

Les redirections ralentissent le chargement car elles obligent le navigateur à effectuer une requête supplémentaire vers le nouvel emplacement. On distingue les redirections de même origine, entièrement sous votre contrôle puisque la logique réside sur votre serveur, et les redirections multi-origines, souvent initiées par des services tiers comme les annonces ou les raccourcisseurs d’URL.

Veillez à éviter les chaînes de redirections, par exemple une page HTTP qui redirige vers son équivalent HTTPS, lui-même soumis à une nouvelle redirection. Dans vos liens internes, pointez toujours directement vers l’URL finale plutôt que vers une page qui répond par une redirection.

Mettre en cache le HTML est délicat car la réponse référence souvent des ressources critiques (CSS, JavaScript, images) dont le nom de fichier change à chaque déploiement. Un HTML mis en cache trop longtemps risque donc de pointer vers des sous-ressources obsolètes.

Une durée de cache courte reste néanmoins préférable à l’absence totale de cache : cinq minutes pour du HTML statique constituent une valeur sûre. Pour un contenu personnalisé (utilisateur authentifié), mieux vaut ne pas mettre en cache du tout. Une approche prudente consiste à s’appuyer sur le cache HTTP et à utiliser les en-têtes ETag ou Last-Modified pour permettre une revalidation économique.

L’en-tête ETag est un identifiant unique de la ressource, souvent basé sur un hachage de son contenu. Lors des requêtes suivantes, le navigateur renvoie cette valeur via l’en-tête If-None-Match. Si elle correspond, le serveur répond par un 304 Not Modified, bien plus léger qu’une page HTML complète.

Le temps de réponse dépend fortement de votre hébergeur et de votre pile applicative. Une page générée dynamiquement (requêtes en base de données) aura souvent un TTFB plus élevé qu’une page statique. L’en-tête Server-Timing aide à identifier les étapes lentes, par exemple l’authentification ou l’accès aux données.

Les réponses textuelles (HTML, CSS, JavaScript, SVG) doivent être compressées pour réduire leur taille de transfert : voyez comment compresser les ressources texte en pratique. Les deux algorithmes les plus utilisés sont gzip et Brotli, ce dernier offrant un gain d’environ 15 à 20 % par rapport à gzip. Voici un exemple d’activation côté serveur.