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

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 d'une page Web concerne une ressource HTML. L'un des principaux objectifs de performances est de vous assurer que le code HTML arrive rapidement avec un délai minimal de latence.

Cette requête initiale de code HTML passe par plusieurs étapes, chacune d'entre elles prenant un certain temps. Réduire le temps passé à chaque étape vous permet d'accélérer le temps de latence du premier octet (TTFB). 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é fait difficile d'atteindre les seuils désignés comme "bons" 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 avec une redirection permanente (réponse 301 Moved Permanently), soit avec une redirection temporaire (réponse 302 Found).

Les redirections ralentissent le chargement des pages, car elles nécessitent que le navigateur effectue 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. Vous contrôlez entièrement ces types de redirections, car la logique de gestion repose 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 d'origines multiples sont souvent utilisées par les annonces, les services de raccourcissement d'URL et d'autres services tiers. Bien que vous ne puissiez pas contrôler les redirections multi-origines, vous pouvez toujours vérifier que vous évitez plusieurs redirections. Par exemple, vous pouvez avoir une annonce qui renvoie vers une page HTTP qui redirige à son tour vers son équivalent HTTPS, ou une redirection multi-origine qui arrive à votre origine, mais déclenche ensuite une redirection de même origine.

Mettre en cache les réponses HTML

Il est difficile de mettre en cache des réponses HTML, car celles-ci peuvent 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 unique dans leurs noms de fichier respectifs, qui changent 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 courte durée de vie du cache (plutôt que l'absence de mise en cache) peut présenter des avantages, tels que la possibilité de mettre une ressource en cache sur un CDN (réduction du nombre de requêtes diffusées à partir du serveur d'origine) et, dans le navigateur, la revalidation des ressources au lieu de leur téléchargement à nouveau. Cette approche fonctionne mieux pour le contenu statique qui ne change en aucun cas. En outre, vous pouvez définir un délai approprié pour mettre en cache les ressources en minutes, selon vos besoins. Un maximum de cinq minutes pour les ressources HTML statiques est un choix sûr. Cela garantit 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 (pour un utilisateur authentifié, par exemple), vous ne souhaiterez probablement pas mettre en cache le contenu pour plusieurs 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 ce cas.

Une approche prudente de la mise en cache du code HTML consiste à 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 est modifiée, une nouvelle valeur ETag doit être générée. Dans les requêtes suivantes, le navigateur envoie la valeur ETag via l'en-tête de requête If-None-Match. Si la valeur ETag sur le serveur correspond à celle envoyée par le navigateur, le serveur répond par 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.

Cependant, la latence réseau liée à la réévaluation de l'actualisation d'une ressource reste un inconvénient en soi. 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 de mise en cache HTML en vaut la peine, ou s'il est préférable de ne pas prendre la peine de mettre du contenu HTML en cache.

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 diffuse une réponse générée dynamiquement (telle que l'extraction de données d'une base de données, par exemple) peut 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. L'affichage d'une icône de chargement, puis la récupération de toutes les données côté client déplacent l'effort d'un environnement côté serveur plus prévisible vers un environnement côté client potentiellement imprévisible. Cela permet généralement d'améliorer les métriques centrées sur l'utilisateur.

Si les utilisateurs rencontrent un TTFB lent dans le champ, vous pouvez afficher des informations sur le temps passé sur le serveur à l'aide de 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 dans le champ à l'aide de l'API Navigation Timing et analysées pour voir si les utilisateurs subissent des retards. Dans l'extrait de code précédent, l'en-tête de réponse inclut deux codes temporels:

• Durée d'authentification d'un utilisateur (auth), qui a pris 55,5 millisecondes.
• Temps d'accès à la base de données (db), qui a pris 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 reçu par votre site Web. Les fournisseurs d'hébergement partagé sont souvent susceptibles d'avoir un TTFB élevé, et les solutions dédiées qui fournissent des temps de réponse plus rapides peuvent s'avérer plus coûteuses.

Compression

Les réponses textuelles telles que les images HTML, JavaScript, CSS et SVG doivent être compressées pour réduire la taille de leur transfert sur le réseau et leur téléchargement plus rapidement. Les algorithmes de compression les plus utilisés sont gzip et Brotli. Brotli se traduit par une amélioration d'environ 15 à 20 % par rapport à gzip.

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

1. Utilisez des Brotli dans la mesure du possible. Comme indiqué précédemment, Brotli offre une amélioration assez visible par rapport à gzip, et Brotli est compatible avec tous les principaux navigateurs. Si possible, optez pour Brotli. Toutefois, si un grand nombre d'utilisateurs utilisent votre site Web dans d'anciens navigateurs, veillez à utiliser gzip en remplacement, car une compression est préférable à une utilisation sans compression.
2. La taille du fichier est importante. Les très petites ressources (moins de 1 Kio) ne sont pas très compressées, voire, parfois, ne sont pas compressées du tout. L'efficacité de tout type de compression de données dépend de la quantité de données qu'un algorithme de compression peut traiter afin de trouver plus de bits de données compressibles. Plus un fichier est volumineux, meilleure est la compression. Toutefois, n'expédiez pas de très grandes ressources simplement parce qu'elles peuvent être compressées plus efficacement. Les ressources volumineuses, telles que JavaScript et CSS par exemple, prennent beaucoup plus de temps à analyser et évaluer une fois qu'elles ont été décompressées par le navigateur. Elles peuvent changer plus fréquemment même si elles n'ont changé que très peu, car toute modification génère un hachage de fichier différent.
3. Comprenez la compression dynamique et la compression statique. La compression dynamique et statique sont des approches différentes pour savoir 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, ne nécessitant aucune compression au moment de la requête. La compression statique élimine la latence liée à la compression elle-même, ce qui peut augmenter les temps de réponse du serveur dans le cas de la compression dynamique. Les ressources statiques, telles que les images JavaScript, CSS et SVG, doivent être compressées de manière statique, tandis que les ressources HTML, en particulier si elles sont générées dynamiquement pour les utilisateurs authentifiés, doivent l'être de manière dynamique.

Il est souvent difficile d'effectuer la compression par soi-même. Il est souvent préférable de laisser un réseau de diffusion de contenu (CDN, Content Delivery Network) s'en charger pour vous, comme abordé dans la section suivante. Toutefois, connaître ces concepts peut vous aider à déterminer si votre fournisseur d'hébergement utilise correctement la compression. Ces informations peuvent vous aider à améliorer vos paramètres de compression afin d'optimiser les bénéfices 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, puis les diffusent à partir de serveurs périphériques physiquement plus proches de vos utilisateurs. La proximité physique de vos utilisateurs réduit le délai aller-retour (DAR), tandis que les optimisations telles que HTTP/2 ou HTTP/3, la mise en cache et la compression permettent au CDN de diffuser du contenu plus rapidement que si celui-ci était extrait du serveur d'origine. Dans certains cas, l'utilisation d'un CDN peut améliorer considérablement le TTFB de votre site Web.

Tester vos connaissances

Prochaine étape: Comprendre le chemin critique

Maintenant que vous connaissez certains des aspects à prendre en compte concernant les performances du code HTML de votre site Web, vous êtes mieux placé pour vous assurer qu'il peut se charger le plus rapidement possible. Mais ce n'est que le début de l'apprentissage des performances Web. Nous allons ensuite étudier la théorie sous-jacente du chemin critique du rendu. Ce module décrit des concepts clés tels que les ressources qui bloquent l'affichage et l'analyse, ainsi que le rôle qu'elles jouent pour afficher l'affichage initial d'une page dans le navigateur le plus rapidement possible.