Considérations générales sur les performances HTML

bookmark_border Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

La première étape pour créer un site Web qui se charge rapidement consiste à recevoir une réponse rapide du serveur pour le code HTML d'une page. Lorsque vous saisissez une URL dans la barre d'adresse du navigateur, celui-ci envoie une requête GET au serveur pour la récupérer. La première requête pour une page Web concerne une ressource HTML. S'assurer que le code HTML arrive rapidement avec un minimum de retard est un objectif clé en termes de performances.

Cette requête initiale pour le code HTML passe par plusieurs étapes, chacune prenant un certain temps. En réduisant le temps passé à chaque étape, vous obtenez un temps de latence du premier octet (TTFB) plus rapide. Bien que le TTFB ne soit pas la seule métrique sur laquelle vous devez vous concentrer pour déterminer la vitesse de chargement des pages, un TTFB élevé rend difficile l'atteinte des seuils "bons" désignés pour des métriques telles que Largest Contentful Paint (LCP) et First Contentful Paint (FCP).

Limiter le nombre de redirections

Lorsqu'une ressource est demandée, le serveur peut répondre par une redirection, soit permanente (réponse 301 Moved Permanently), soit temporaire (réponse 302 Found).

Les redirections ralentissent la vitesse de chargement des pages, car elles obligent le navigateur à effectuer une requête HTTP supplémentaire au nouvel emplacement pour récupérer la ressource. Il existe deux types de redirections :

1. Les redirections de même origine qui se produisent entièrement dans votre origine. Ces types de redirections sont entièrement sous votre contrôle, car la logique de leur gestion réside entièrement sur votre serveur Web.
2. Redirections multi-origines initiées par une autre origine. Ces types de redirections sont généralement hors de votre contrôle.

Les redirections cross-origin sont souvent utilisées par les annonces, les services de raccourcissement d'URL et d'autres services tiers. Bien que les redirections cross-origin ne dépendent pas de vous, vous pouvez tout de même vérifier que vous évitez les redirections multiples. Par exemple, une annonce qui redirige vers une page HTTP, qui à son tour redirige vers son équivalent HTTPS, ou une redirection cross-origin qui arrive à votre origine, mais qui déclenche ensuite une redirection same-origin.

Mettre en cache les réponses HTML

La mise en cache des réponses HTML est difficile, car la réponse peut inclure des liens vers d'autres ressources critiques telles que CSS, JavaScript, des images et d'autres types de ressources. Ces ressources peuvent inclure une empreinte digitale unique dans leurs noms de fichiers respectifs, qui change en fonction du contenu d'un fichier. Cela signifie que votre document HTML mis en cache peut devenir obsolète après un déploiement, car il contient des références à des sous-ressources obsolètes.

Néanmoins, une durée de vie du cache courte (plutôt que pas de mise en cache) peut présenter des avantages, par exemple en permettant à une ressource d'être mise en cache dans un CDN (ce qui réduit le nombre de requêtes traitées par le serveur d'origine) et dans le navigateur (ce qui permet de revalider les ressources plutôt que de les télécharger à nouveau). Cette approche fonctionne mieux pour le contenu statique qui ne change dans aucun contexte. Vous pouvez définir une durée de mise en cache des ressources sur un nombre de minutes que vous jugez approprié. Cinq minutes pour les ressources HTML statiques est une valeur sûre et permet de s'assurer que les mises à jour périodiques ne passent pas inaperçues.

Si le contenu HTML d'une page est personnalisé d'une manière ou d'une autre (par exemple, pour un utilisateur authentifié), vous ne souhaitez probablement pas mettre en cache le contenu du tout pour diverses raisons, y compris la sécurité et la fraîcheur. Si une réponse HTML est mise en cache par le navigateur de l'utilisateur, vous ne pouvez pas invalider le cache. Il est donc préférable d'éviter complètement la mise en cache du code HTML dans de tels cas.

Une approche prudente de la mise en cache du code HTML pourrait consister à utiliser les en-têtes de réponse ETag ou Last-Modified. Un en-tête ETag (également appelé tag d'entité) est un identifiant qui représente de manière unique la ressource demandée, souvent en utilisant un hachage du contenu de la ressource :

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Chaque fois que la ressource change, une nouvelle valeur ETag doit être générée. Lors des requêtes suivantes, le navigateur envoie la valeur ETag via l'en-tête de requête If-None-Match. Si le ETag sur le serveur correspond à celui envoyé par le navigateur, le serveur répond avec une réponse 304 Not Modified et le navigateur utilise la ressource du cache. Bien que cela entraîne toujours une latence réseau, une réponse 304 Not Modified est beaucoup plus petite qu'une ressource HTML entière.

Toutefois, la latence réseau impliquée dans la revalidation de la fraîcheur d'une ressource constitue en soi un inconvénient. Comme pour de nombreux autres aspects du développement Web, les compromis sont inévitables. C'est à vous de déterminer si l'effort supplémentaire nécessaire pour mettre en cache le code HTML de cette manière en vaut la peine, ou s'il est préférable de ne pas mettre en cache le contenu HTML du tout pour plus de sécurité.

Mesurer les temps de réponse du serveur

Si une réponse n'est pas mise en cache, le temps de réponse du serveur dépend fortement de votre fournisseur d'hébergement et de la pile d'applications backend. Une page Web qui fournit une réponse générée de manière dynamique (par exemple, en récupérant des données à partir d'une base de données) peut très bien avoir un TTFB plus élevé qu'une page Web statique qui peut être diffusée immédiatement sans temps de calcul important sur le backend. Afficher un indicateur de chargement, puis récupérer toutes les données côté client transfère l'effort d'un environnement côté serveur plus prévisible vers un environnement côté client potentiellement imprévisible. La réduction de l'effort côté client se traduit généralement par une amélioration des métriques axées sur l'utilisateur.

Si les utilisateurs constatent un TTFB lent sur le terrain, vous pouvez fournir des informations sur le temps passé sur le serveur en utilisant l'en-tête de réponse Server-Timing :

Server-Timing: auth;dur=55.5, db;dur=220

La valeur d'un en-tête Server-Timing peut inclure plusieurs métriques, ainsi qu'une durée pour chacune d'elles. Ces données peuvent ensuite être collectées auprès des utilisateurs sur le terrain à l'aide de l'API Navigation Timing et analysées pour déterminer si les utilisateurs rencontrent des problèmes de latence. Dans l'extrait de code précédent, l'en-tête de réponse inclut deux durées :

• Temps nécessaire pour authentifier un utilisateur (auth), soit 55,5 millisecondes.
• Le temps d'accès à la base de données (db), qui a duré 220 millisecondes.

Vous pouvez également examiner votre infrastructure d'hébergement et vérifier que vous disposez de ressources suffisantes pour gérer le trafic que reçoit votre site Web. Les fournisseurs d'hébergement partagé sont souvent sujets à un TTFB élevé, et les solutions dédiées qui offrent des temps de réponse plus rapides peuvent être plus coûteuses.

Compression

Les réponses textuelles telles que les images HTML, JavaScript, CSS et SVG doivent être compressées pour réduire leur taille de transfert sur le réseau afin qu'elles puissent être téléchargées plus rapidement. Les algorithmes de compression les plus utilisés sont gzip et Brotli. Brotli permet d'améliorer les performances d'environ 15 à 20 % par rapport à gzip.

La compression est souvent configurée automatiquement par la plupart des fournisseurs d'hébergement Web. Toutefois, si vous êtes en mesure de configurer ou de modifier vous-même les paramètres de compression, vous devez tenir compte de certains points importants :

1. Utilisez Brotli dans la mesure du possible. Comme indiqué précédemment, Brotli offre une amélioration assez notable par rapport à gzip, et Brotli est compatible avec tous les principaux navigateurs. Utilisez Brotli si possible, mais si votre site Web est utilisé par un grand nombre d'utilisateurs sur des navigateurs anciens, assurez-vous que gzip est utilisé comme solution de secours, car toute compression est préférable à l'absence de compression.
2. La taille du fichier est importante. Les très petites ressources (moins de 1 Kio) ne se compressent pas très bien, voire pas du tout. L'efficacité de tout type de compression de données dépend de la présence d'une grande quantité de données avec lesquelles un algorithme de compression peut travailler afin de trouver des bits de données plus compressibles. Plus un fichier est volumineux, plus la compression est efficace. Toutefois, n'envoyez pas de ressources très volumineuses simplement parce qu'elles peuvent être compressées plus efficacement. Les ressources volumineuses (JavaScript et CSS, par exemple) prennent beaucoup plus de temps à analyser et à évaluer une fois que le navigateur les a décompressées. Elles peuvent également changer plus fréquemment, même si elles n'ont été que légèrement modifiées, car toute modification entraîne un hachage de fichier différent.
3. Comprendre la différence entre la compression dynamique et la compression statique La compression dynamique et statique sont deux approches différentes pour déterminer quand une ressource doit être compressée. La compression dynamique compresse une ressource au moment où elle est demandée, et parfois à chaque fois qu'elle est demandée. En revanche, la compression statique compresse les fichiers à l'avance, ce qui signifie qu'aucune compression n'est nécessaire au moment de la requête. La compression statique élimine la latence liée à la compression elle-même, qui peut s'ajouter aux temps de réponse du serveur en cas de compression dynamique. Les ressources statiques (JavaScript, CSS et images SVG, par exemple) doivent être compressées de manière statique, tandis que les ressources HTML (surtout si elles sont générées de manière dynamique pour les utilisateurs authentifiés) doivent être compressées de manière dynamique.

Il est difficile de compresser correctement les fichiers soi-même. Il est souvent préférable de laisser un réseau de diffusion de contenu (CDN, Content Delivery Network), dont nous parlerons dans la section suivante, s'en charger pour vous. Toutefois, connaître ces concepts peut vous aider à déterminer si votre hébergeur utilise correctement la compression. Ces connaissances peuvent vous aider à identifier des opportunités d'amélioration de vos paramètres de compression afin qu'ils offrent un maximum d'avantages pour votre site Web.

Réseaux de diffusion de contenu (CDN)

Un réseau de diffusion de contenu (CDN) est un réseau distribué de serveurs qui mettent en cache les ressources de votre serveur d'origine et les diffusent à partir de serveurs périphériques physiquement plus proches de vos utilisateurs. La proximité physique avec vos utilisateurs réduit le temps d'aller-retour (RTT), tandis que les optimisations telles que HTTP/2 ou HTTP/3, la mise en cache et la compression permettent au CDN de diffuser le contenu plus rapidement que s'il était récupéré depuis votre serveur d'origine. L'utilisation d'un CDN peut améliorer considérablement le TTFB de votre site Web dans certains cas.

Tester vos connaissances

À suivre : comprendre le chemin critique

Maintenant que vous connaissez certains aspects liés aux performances de l'HTML de votre site Web, vous êtes mieux à même de vous assurer qu'il peut se charger le plus rapidement possible. Toutefois, ce n'est que le début de votre apprentissage des performances Web. Ensuite, la théorie derrière le chemin de rendu critique est abordée. Ce module décrit des concepts clés tels que les ressources bloquant le rendu et l'analyse, ainsi que le rôle qu'ils jouent pour que le rendu initial d'une page dans le navigateur soit le plus rapide possible.